WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.7 May 31, 2020)

User projects written in or related to FreeBASIC.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 27, 2020 23:35

Thanks Paul - issues noted. (I already have the case autocompletion on my to look at and fix list). I'll work on trying to negate the triggering of autocomplete and autoinsert within a valid comment block. If you notice anything else that's out of sorts then please let me know. Thanks
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 28, 2020 1:25

paul doe wrote:

Code: Select all

/'
  while true <-- If you press enter here, the editor auto-completes the block, unless you encase the predicate in parens
 
  I like bunnies <-- If you write a dot here, it triggers code completion suggestions
'/

[*]While the above behavior is correct outside of a comment block, it does not work:


I was able to easily fix the above problem by testing the style for a character on the line that activates the AuotInsert of a control structure. So, when ENTER is pressed after you write "while true", the code checks the current scintilla style at the cursor position and if it is a single or block commnent style then the autoinsert is cancelled. Likewise, autocomplete popups can be disabled in comment blocks using the same code logic.

Code: Select all

   ' Get the styling of the current line to determine if we are in a
   ' multiline or single line comment block then abort the autoinsert.
   select case SciExec(hEdit, SCI_GETSTYLEAT, curPos, 0)
      case SCE_B_MULTILINECOMMENT, SCE_B_COMMENT
         exit function
   end select
deltarho[1859]
Posts: 2611
Joined: Jan 02, 2017 0:34
Location: UK

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby deltarho[1859] » Apr 28, 2020 1:28

Paul wrote:Sure would be good if WinFBE had an extensive help manual that covered things like User Tools, wouldn't it? Lol :) someday...someday...

I find writing Help files quite daunting. It is so easy to miss something out which is important.

I have lost count on the number of times a Help file displays a form and does an excellent job on explaining how to fill the form in but neglects to tell me where that form is costing me a lot of time going through all the menus and items trying to find it. All it took was one line at the head of that section telling me where the form was. So, why wasn't I told? The Help file author assumed I knew where the form was but why should I, I may have only had the software a short while.

The same thing goes for files. In drWinFBETools.chm the first time that I mention WinFBE.ini I don't just write 'WinFBE.ini' but write 'WinFBE.ini in the Settings folder'. That was part of '[UserTools] section of WinFBE.ini in the Settings folder' spelling out where [UserTools] is.

If we omit something in code then a compiler will often tell us but when we compile a Help file we are not told when we have omitted to tell the reader something that we should have mentioned.

When I wrote drWinFBETools.chm I went to great pains to make sure that the reader was not left wanting to know something. However, I did omit something. I talk about "simply adding a single line to the [UserTools] ...". If anyone unzipped WinFBE_Suit.rar and then went to the Settings folder they would not find WinFBE.ini. I should have mentioned that WinFBE needs to be run first to get WinFBE.ini built, and then we can add to the {UserTools] section. So, why didn't I mention it? I didn't know. Chances are that folk will run WinFBE before considering User Tools and that would get me off the hook, so to speak. Image

drWinFBETools.chm is a little Help file (165KB). Writing "an extensive help manual" for WinFBE that does not leave the reader wanting to know something will be a formidable task. Some Help files on my system are enormous in comparison and I will put money on it that they were not written by one author. The corresponding software was probably not written by one author either.

If you ever do write a Help file ask some WinFBE users to 'beta' test it. However, your beta testers should not be seasoned WinFBE users because they may make assumptions of readers that you do - ask users who have just started to use WinFBE - they are the best Help file beta testers.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 28, 2020 21:08

Thanks David, I appreciate you sharing your Help file experience. I (probably like many others) shy away from writing documentation because it lacks the sexiness of the actual programming. Also, whenever I start writing help I get bogged down in the help authoring tool that I am using....and I've used a lot of them. Over the past year I've now switched to GitHub markdown for creating the help files. Very simple to use and maintain. Certainly different than what most Windows users are used to with .CHM help files.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 28, 2020 21:12

paul doe wrote:

Code: Select all

type _
  Bunny
 
  as integer _
    age
end type

dim as Bunny _
  b

b. <-- Does not trigger suggestions

with b
  . <-- Neither does this
end with



I copied/pasted the above code into a new blank code document. The popup autocomplete suggestions did work for me so I am not sure of where the problem lies that you are experiencing. Maybe the above code is part of a much larger code base in your application. Sometimes WinFBE may not parse the large surrounding code accurately causing the above code to possibly fail(?) Not sure at this point.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 28, 2020 21:50

deltarho[1859] wrote:Thanks, Paul.

If anyone downloads WinFBE for the first time then they will find that no User Tools have been installed and won't even know where they are. If you find them then you may think that you have to use 'Tools>User Tools...' in WinFBE's menu to install them - you don't. If you navigate to WinFBE's Tools folder you will find drWinFBE_Tools.chm. Work through that Help file and 'install' whatever tools you want. The Help file mentions that ini files exist in the Tools folder but that is no longer true - don't worry about that because the Help file covers everything that you need to know.


Hi David,

I have added code to create default User Tools entries when a new winfbe.ini config file is being created. My only problem is that when your two tools startup they both generate warning messageboxes "I need more than one compiler switch" and "I need more than one set of compiler paths". It kind of ruins the new user experience who fires up WinFBE for the first time and encounters these messages. They will most certainly think that they are WinFBE errors and question whether they installed the editor correctly.

Any suggestions on how you'd like to handle this because I am not comfortable with the tools starting up showing these warnings. :-)
deltarho[1859]
Posts: 2611
Joined: Jan 02, 2017 0:34
Location: UK

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby deltarho[1859] » Apr 29, 2020 6:10

Hi Paul

Those messages occur when either no associated ini file exists or, if they do, they have less than two entries. In either case it is pointless to install my two 'main' User Tools.

We can avoid the issue with SetCompilerSwitchesII by including this simple ini file with your distribution:

Code: Select all

"-gen gas"
"-gen gcc"

Alternatively, I could change the message to advise that SetCompilerSwitchesII has been installed but it needs an ini file with at least two entries and to see drWinFBE_Tools.chm in the Tools folder for details.

I don't like that, the simple ini file is much better.

We don't get a message if the action 'Invoke only when selected by user' is chosen. I don't like that either, the simple ini file is still much better.

If ever we manually add a switch to 'Additional compiler options switches (optional)' then the next time SetCompilerSwitchesII opens it will not be able to match the entry in WinFBE.ini with a pre-set. What it does tell us is what was actually found in WinFBE.ini. In that case none of the radio buttons will be selected. We can compile with whatever was found or choose a pre-set and click 'Apply'. Of course, if we intend to use what was found regularly then we should add that to the pre-sets.

When WinFBE.ini is built 'Additional compiler options switches (optional)' is empty and, here to, we will not get a match. This is what we get.

Image

We are, of course, being told that nothing was found. This is not intentional, it is simply a consequence of nothing being found. On clicking OK we get

Image

so, we make a choice. If we click on 'Apply' without making a choice then we get told 'No radio button has been selected', SetCompilerSwitchesII will not take any nonsense. Of course, if we choose '-gen gas' this is the same as nothing being found.

Now, we have a problem with SetCompilerPathsII. We cannot include a simple ini file if a WinFBE user does not choose to have more than one gcc toolchain.

From my Help file: "SetCompilerPathsII requires a choice of at least two gcc compilers so will probably be of little interest to many FreeBASIC users. It is expected that a future release of FreeBASIC will include at least two gcc compilers and SetCompilerPathsII will come into its own then."

So, if a WinFBE user decides not to add to the default gcc 5.2 then SetCompilerPathsII should not be 'installed'. We don't get a message if the action 'Invoke only when selected by user' is chosen but why 'install' it if only gcc 5.2 is wanted.

Of course, there is a simple solution to this but it requires you to bite the bullet: Include gcc 8.3 with your distribution and then you could use this ini file.

Code: Select all

"5.2", "..\FreeBASIC-1.07.1-gcc-5.2\fbc32.exe", "..\FreeBASIC-1.07.1-gcc-5.2\fbc64.exe"
"8.3", "..\FreeBASIC-1.07.1-gcc-8.3\fbc32.exe", "..\FreeBASIC-1.07.1-gcc-8.3\fbc64.exe"

Once WinFBE users were given gcc 8.1 whether they liked it or not. I was happy with that but I suspect some forum members were not. If gcc 8.1 ever played up we could not fall back on gcc 5.2. I never had to and gcc 8.3 seems well-behaved - it is my default.

One of these days FB will get it's 'finger out' in a future release and provide more than one gcc toolchain. You can do that now.

So, my recommendation is to include gcc 8.3 with your distribution.

With the two sets of two line ini files the messages you referred to will no longer be seen and I have no coding to do. What we get, in my opinion, is a better WinFBE with a choice of toolchains.

Some 5.2 diehards will say: "I am not going to use 8.3.", but who says they have to. I will put money on it that they will try 8.3 when no one is looking. Sometimes 8.3 will be faster but should always produce smaller binaries and some 5.2 diehards may think: "Hmmm, I think that I will stay with 8.3". Of course, the likelihood is that they won't tell anyone. Image

We are getting close to my drWinFBE_Tools becoming redundant but there is information worth keeping, such as the description of 'Arch Settings' and the 'Tips and Tricks' section, so a rewrite will be in order.
robert
Posts: 122
Joined: Aug 06, 2019 18:45

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby robert » Apr 30, 2020 10:36

Hi Paul;

I have started using the V2.1.4 WinFBE editor (great work!) and built the project found in WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res.

A "Successful Compile (Errors 0 Warnings 0)" was reported, however, in the Compiler Results the Line column and the File column were blank but in the Description there was this

Code: Select all

C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.c:1055:8: warning: conflicting types for built-in function 'strstr'; expected 'char *(const char *, const char *)' [-Wbuiltin-declaration-mismatch]
 1055 | uint8* strstr( uint8*, u


and in the Compiler Log File there was this

Code: Select all

Successful Compile (Errors 0 Warnings 0)

Primary Source: C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.bas
Target Compilation: C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.exe (112 KB, 114176 bytes)
Compile Time: 3.4 seconds (2020-04-30 09:33:47)

Command Line:
C:\dev\FBEQ\fbc.exe -m "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.bas" "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\resource.rc" -v -s gui  -x "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.exe"

FreeBASIC Compiler - Version 1.08.0 (2020-04-30), built for win64 (64bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
standalone
target:       win64, x86-64, 64bit
backend:      gcc
compiling:    C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.bas -o C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.c (main module)
compiling C:  C:\dev\FBEQ\bin\win64\gcc.exe -m64 -march=x86-64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-format -masm=intel "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.c" -o "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.asm"
C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.c:1055:8: warning: conflicting types for built-in function 'strstr'; expected 'char *(const char *, const char *)' [-Wbuiltin-declaration-mismatch]
 1055 | uint8* strstr( uint8*, uint8* );
      |        ^~~~~~
C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.c:1:1: note: 'strstr' is declared in header '<string.h>'
  +++ |+#include <string.h>
    1 | typedef   signed char       int8;
assembling:   C:\dev\FBEQ\bin\win64\as.exe --64 --strip-local-absolute "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.asm" -o "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.o"
compiling rc:               C:\dev\FBEQ\bin\win64\GoRC.exe /ni /nw /o /machine X64 /fo "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\resource.obj" "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\resource.rc"
linking:      C:\dev\FBEQ\bin\win64\ld.exe -m i386pep -o "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.exe" -subsystem windows "C:\dev\FBEQ\lib\win64\fbextra.x" --stack 1048576,1048576 -s -L "C:\dev\FBEQ\lib\win64" -L "." "C:\dev\FBEQ\lib\win64\crt2.o" "C:\dev\FBEQ\lib\win64\crtbegin.o" "C:\dev\FBEQ\lib\win64\fbrt0.o" "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\Toolbar_HDPI_Res.o" "C:\dev\WinFBE_Suite\Examples\Sample_Projects\ToolBar_HDPI_Res\resource.obj" "-(" -lkernel32 -lgdi32 -lmsimg32 -luser32 -lversion -ladvapi32 -limm32 -lcomctl32 -luuid -lole32 -loleaut32 -luxtheme -lpsapi -lshell32 -lcomdlg32 -lshlwapi -lgdiplus -lddraw -ldxguid -lwinspool -lfb -lgcc -lmsvcrt -lmingw32 -lmingwex -lmoldname -lgcc_eh "-)" "C:\dev\FBEQ\lib\win64\crtend.o"


Is that uint8* strstr( uint8*, uint8* ); really there somewhere in José's code or is the gcc-10 compiler I'm using really not ready for prime time and making up fake warnings?
paul doe
Posts: 1269
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby paul doe » Apr 30, 2020 13:44

deltarho[1859] wrote:...
Some 5.2 diehards will say: "I am not going to use 8.3.", but who says they have to. I will put money on it that they will try 8.3 when no one is looking.
...

It's not that. I had troubles getting dynamic libraries to work well (if at all) for any version >5.3. They compile correctly but when trying to use the symbols the program just crashes. I don't know why yet, and I don't currently have the time (nor the desire, frankly) to go hunting for the problem. Or perhaps it's just me...
deltarho[1859]
Posts: 2611
Joined: Jan 02, 2017 0:34
Location: UK

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby deltarho[1859] » Apr 30, 2020 16:02

paul doe wrote:They compile correctly but when trying to use the symbols the program just crashes.

Paul, I have all the latest gcc compilers, except 7.5 with 7.4, and do not have any issues with dynamic libraries. Would you post a small example which crashes?
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 30, 2020 16:46

deltarho[1859] wrote:
We can avoid the issue with SetCompilerSwitchesII by including this simple ini file with your distribution:

Code: Select all

"-gen gas"
"-gen gcc"



Sounds good to me. I'll go with this solution for now and revisit it again in the future should I eventually package another GCC distribution.

(Edit: sorry I spoke too soon. I read your post again and need to figure out SetCompilerPathsII as well).
Last edited by PaulSquires on Apr 30, 2020 16:58, edited 1 time in total.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » Apr 30, 2020 16:51

robert wrote:I have started using the V2.1.4 WinFBE editor (great work!)


Awesome - Thanks!

Is that uint8* strstr( uint8*, uint8* ); really there somewhere in José's code or is the gcc-10 compiler I'm using really not ready for prime time and making up fake warnings?


I'm thinking it must be gcc-10 not playing nice with the code. I don't get any errors here with 5.3.
deltarho[1859]
Posts: 2611
Joined: Jan 02, 2017 0:34
Location: UK

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby deltarho[1859] » Apr 30, 2020 17:14

Paul wrote:Sounds good to me.

OK, in that case forget it and include

Code: Select all

"-gen gas"
"-gen gcc"
"-gen gcc -Wc -O1"
"-gen gcc -Wc -O2"
"-gen gcc -Wc -O3"
"-gen gcc -Wc -Os"
"-gen gcc -Wc -Ofast"

That may be enough for most especially with the inclusion of the '-exx' checkbox where we can prepend any chosen preset with '-exx'.
(Edit: sorry I spoke too soon. I read your post again and need to figure out SetCompilerPathsII as well).

Nothing to figure out. If you only package one gcc compiler then SetCompilerPathsII should not be 'installed'. It should remain in the Tools folder so that those who want to add further gcc toolchains can do so easily by following my advice in drWinFBE_Tools.chm.

Alternatively, if you think that SetCompilerPathsII should be 'installed' then change the action to 'Invoke only when selected by user'. That way we do not get "I need more than one set of compiler paths" each time WinFBE opens and only when the user selects that User Tool.

Added: I noticed Paul Doe and yourself mention gcc 5.3. I have just checked your distribution for 32-bit and 64-bit using 'gcc -v' and got 5.2.0. Version 5 got to 5.5 but I haven't seen anybody using greater than 5.2.
robert
Posts: 122
Joined: Aug 06, 2019 18:45

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby robert » Apr 30, 2020 21:58

PaulSquires wrote:
robert wrote:I have started using the V2.1.4 WinFBE editor (great work!)


Awesome - Thanks!

Is that uint8* strstr( uint8*, uint8* ); really there somewhere in José's code or is the gcc-10 compiler I'm using really not ready for prime time and making up fake warnings?


I'm thinking it must be gcc-10 not playing nice with the code. I don't get any errors here with 5.3.


Hi Paul:

I found the source of the warning in WinFBX includes. The AfxWin.inc and CSafeArray.inc code both contain a call to strstr with an "ANY PTR" and a ZSTRING argument instead of the expected const char *.
PaulSquires
Posts: 882
Joined: Jul 14, 2005 23:41

Re: WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V2.1.4 April 26, 2020)

Postby PaulSquires » May 01, 2020 0:00

Thanks I will post a message on my forum for Jose in case he doesn't see it here.

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 3 guests