WinFBX include path

[Paul Squires]

> The best place to install Jose's WinFBX library is in a "Afx" subfolder off of your "\inc" folder for your FB installation.

I don't agree. Doing this, you have to copy the Afx folder in the \inc folder of both the 32 and 64 bit compilers.

> Note that in the latest WinFBE Editor the "WinFBX Library Path" is/will be removed from the "Compiler Options".

This is very bad news for me. I suggested the addition of this field because this way I only need to have the includes in one place. Before it, each time that I changed something in the include files I had to copy the changes to two folders to be able to test them with both 32 and 64 bit.

I hear what you are saying. I removed it because of potential confusion for new users to understand in general how include files should be set up in the system. In the WinFBE Suite everything is preconfigured. I do see your point about the double changes... I have the exact same problem with the WinFormsX library that I am building to handle the visual designer code output. As a simple solution, whenever I make a change to the source library, I run a small batch file that copies the contents to the include file folders for the 32 bit install and the 64 bit install. This is the pretty simple batch file I've been using: (_copyWinFormsX.bat)

copy ..\WinFormsX\src\*.* .\FreeBASIC-1.06.0-win32\inc\WinFormsX\*.*
copy ..\WinFormsX\src\*.* .\FreeBASIC-1.06.0-win64\inc\WinFormsX\*.*

Do you feel super strong about the elimination of the dedicated WinFBX path in the Compiler Setup? If you do, then I will certainly add back the code. Your happiness is a priority

[José Roca]

Currently I have my includes in C:\Programs\WinFBX\Afx. When I change something and I want to test if it works with 32 and 64 bit I only have to choose the appropriate compiling option. Before you added this overriding option, I had the files as a subfolder of the compiler \inc path and if I changed the includes on the 32-bit folder I had to copy them to the 64 bit folder, and viceversa, wasting time, doing mistakes and sometimes forgetting to test it with the two compilers. Recently i had to modify the AfxOpenFileDialog, AfxSaveFileDialog, AfxStrLSet, AfxStrRset and AfxStrCSet functions because they GPFed when compiled with 64 bit (probably I forgot to copy the changes to the 64 bit folder or forgot to test it). This overriding option was a godsend for me. Automate whatever you wish to please beginners, but please let me (and other advanced users) to override it. About beginners being confussed, it is their natural state...

[Paul Squires]

   I hear you Jose.... leave it with me - I'll get a solution that works for you.

[Paul Squires]

Turned out to be a very simple fix and it should keep your programming life exactly the same as it is now. The config file already contains an entry "WinFBXPath=" that stores the path to the WinFBX files. I have modified the editor to continue to read that configuration option and to add it to the list of include paths if it is a valid path.

Code Select Expand


   ' If the path to the WinFBX (Afx) library is valid then add that path
   ' as a -i switch to the compiler.
   if AfxIsFolder(gConfig.WinFBXPath) THEN
      gCompile.CompileFlags = gCompile.CompileFlags + " -i " + chr(34) + gConfig.WinFBXPath + chr(34)
   end if


Code Select Expand


[Compiler]
FBWINCompiler32=.\FreeBASIC-1.06.0-win32\fbc.exe
FBWINCompiler64=.\FreeBASIC-1.06.0-win64\fbc.exe
CompilerSwitches=-gen gcc -Wc -O3
CompilerHelpfile=.\Help\freebasic_manual.chm
Win32APIHelpfile=.\Help\win32_fb.chm
RunViaCommandWindow= 0
WinFBXPath=X:\FB\WinFBE_Suite-Editor\Afx


The only thing that is different is that the path can not be set from inside the editor's Compiler Setup options. If you ever need to change the path then you will need to manually modify the "WinFBE.ini" file.

[José Roca]

Well, you will know what you're doing. If choosing a path for the include files will confusse them, let's see what will happen when they have to update the include files twice in two separate folders. Guess most will end using outdated files until you release a new version of the editor.

[Paul Squires]

Well, you will know what you're doing. If choosing a path for the include files will confusse them, let's see what will happen when they have to update the include files twice in two separate folders. Guess most will end using outdated files until you release a new version of the editor.

That's exactly what I expect to happen... people will wait until a new version of the editor package becomes available. Well, most users, not all of course. No different then those programmers that refuse to update their compiler to the latest 1.06 build because it is not an "official" release