sub messagebox(msg as string)
shell ("msg * "+ msg)
end sub
messagebox "HELLO"
sleep
If you use fbide a lot, code completion becomes a burden when you switch ides.
Some ides close brackets, churn out an end if after an if, and other silly stuff.
Who needs that?
But then again, if you are used to code completion, fbide could seem quite basic.
Type ztype As atype
Type atype
x As Integer
b As Integer
Private:
f As Integer
End Type
Type btype
t As atype
End Type
Dim n As atype
'n.f = 10 ' f should not show as it is private, but it does
'Dim r As z ' here it should autocomplete to show 'ztype' but it shows only zstring
Dim r As ztype
'r. 'here it should give me x and b but it shows nothing
Dim b As btype
With b
With .t
'. here it should give me x and b but it shows .t again
End With
End With
As you code large classes or classes with UDT's you find more and more places where autocomplete is broken and shows incorrect options. This then becomes intrusive. I would call that broken.
sancho2 wrote:
Start with the keyword "this". See if it autocompletes anywhere.
......
As you code large classes or classes with UDT's you find more and more places where autocomplete is broken and shows incorrect options. This then becomes intrusive. I would call that broken.
I wouldnt call that broken, just not fully implemented. I also would like to see THIS autocomplete but it would require from the IDE part to recognize what THIS is the alias for. And sometimes it's alias for nothing if you haven't yet written a correct block.
To avoid incorrect options, I start one FBEDIT per familly of code so the function of ones won't add to the functions of the others.
Is there a way to define which compiler each project will use? I want to create some DOS apps, and then move onto Windows apps. Currently FBIDE only points to the one existence of FBC.EXE - do I have to point it to the one I require every time?
muguk wrote:Is there a way to define which compiler each project will use? I want to create some DOS apps, and then move onto Windows apps. Currently FBIDE only points to the one existence of FBC.EXE - do I have to point it to the one I require every time?
muguk wrote:Is there a way to define which compiler each project will use? I want to create some DOS apps, and then move onto Windows apps. Currently FBIDE only points to the one existence of FBC.EXE - do I have to point it to the one I require every time?
You can duplicate your FBIDE directory to have many installations (it's possible because it's a really small program). Then you can change the settings once for each installation. You would then have an installation dedicated to such or such target and its command lines.
Otherwise changing the settings each time for one unique FBIDE is not very fast.
muguk wrote:Is there a way to define which compiler each project will use? I want to create some DOS apps, and then move onto Windows apps. Currently FBIDE only points to the one existence of FBC.EXE - do I have to point it to the one I require every time?
You can duplicate your FBIDE directory to have many installations (it's possible because it's a really small program). Then you can change the settings once for each installation. You would then have an installation dedicated to such or such target and its command lines.
Otherwise changing the settings each time for one unique FBIDE is not very fast.
Ah right. Probably need to scrap my current FB set up and start all over. And have three copies of the FB IDE as you've suggested.
My HELP file opens in the expected Help Window, displaying a full index including a number of tutorials ... but the content is completely blank. Anybody know why this should be? The file is there (FB-manual-0.23.0.chm), and I get the same (blank) result whether I open it from within the IDE app (using the pull-down menu, OR the F1 key) ... or whether I open the .chm file directly from Windows Explorer. Have downloaded IDE more than once, with the same result.
Have you unblock this CHM file after downloading?
(by right clicking the file in your file explorer, selecting 'properties', and clicking the 'unblock' button at the bottom)
Note: The last official FB version is here: Version 1.06.0 released
(see FB-manual-1.06.0-chm in 'Documentation' paragraph, and fbc in 'Windows Binaries' paragraph)
I confirm (seen today with Win 10) that the execution attempt of FBIde can abort (rarely) due to the old mingwm10.dll file included in the FBIde download.
The fix is to replace this old file with a newer one, as described below by Sebastian:
Sebastian wrote:Hello,
I saw the issue on a Windows 7 x64 PC recently.
In that case the problem was related to the obviously very old "mingwm10.dll" included with the FBIDE download. I downloaded a newer version of the DLL from the MingW sourceforge site and replaced FBIDE's "mingwm10.dll" with the file of the same name contained in the download ("bin" subfolder):
fxm wrote:I am with Win7 on my professional PC.
Often, I get a similar error message (error 0xc0000005), at any FBIde execution attempt (versions 0.4, 0.4.3, 0.4.6) after a PC boot.
Generally, closing then opening a new Windows session is sufficient to solve the problem, but sometimes a full reboot is required.
Remark: by cons, the oldest version "FBIde v0.3.3a" is always working!
Now with Win 10, I very rarely have such an error message when launching FBIde with Win10.
The next time I get it, I will exchange the 2 mingwm10.dll files without restarting the computer, to test your solution.
fxm wrote:I confirm (seen today with Win 10) that the execution attempt of FBIde can abort (rarely) due to the old mingwm10.dll file included in the FBIde download.
The fix is to replace this old file with a newer one, as described below by Sebastian:
Sebastian wrote:Hello,
I saw the issue on a Windows 7 x64 PC recently.
In that case the problem was related to the obviously very old "mingwm10.dll" included with the FBIDE download. I downloaded a newer version of the DLL from the MingW sourceforge site and replaced FBIDE's "mingwm10.dll" with the file of the same name contained in the download ("bin" subfolder):
fxm wrote:I am with Win7 on my professional PC.
Often, I get a similar error message (error 0xc0000005), at any FBIde execution attempt (versions 0.4, 0.4.3, 0.4.6) after a PC boot.
Generally, closing then opening a new Windows session is sufficient to solve the problem, but sometimes a full reboot is required.
Remark: by cons, the oldest version "FBIde v0.3.3a" is always working!
Now with Win 10, I very rarely have such an error message when launching FBIde with Win10.
The next time I get it, I will exchange the 2 mingwm10.dll files without restarting the computer, to test your solution.
@Admins:
It would be nice if at least the link to FBIde in the 'readme.txt' file pointed to a download of FBIde updated with a recent 'mingwm10.dll' file.
This link is: https://fbide.freebasic.net/ (Download FBIde 0.4.6r4)
which points to: http://sourceforge.net/projects/fbide/f ... p/download (.../FBIde0.4.6r4.zip/download)
(by vongodric)
fxm wrote:WARNING!
FBIde always forces the lower case in the command line to compiler:
Even if we edit for example '-R', '-r' is always sent in the command line to compiler (check with menu View/Show log).
This behavior of FBIde is embarrassing for the following command line compiler options in red:
-C : Do not delete the object file(s)
-c : Compile only, do not link
-O < level > : Set the optimization level (-gen gcc)
-o < name > : Set object file path/name (must be passed after the .bas file)
-R : Do not delete the intermediate file(s)
-r : Write intermediate file(s) only, do not compile or link
-RR : Do not delete the asm file(s)
-rr : Write asm file(s) only, do not compile or link
Since fbc varsion 1.09.0, the '#CMDLINE' preprocessor directive allows to specify compiler options from inside the first specified fb source file.
This can be used as a workaround to the above behavior.
fxm wrote:I confirm (seen today with Win 10) that the execution attempt of FBIde can abort (rarely) due to the old mingwm10.dll file included in the FBIde download.
The fix is to replace this old file with a newer one, as described below by Sebastian:
Sebastian wrote:Hello,
I saw the issue on a Windows 7 x64 PC recently.
In that case the problem was related to the obviously very old "mingwm10.dll" included with the FBIDE download. I downloaded a newer version of the DLL from the MingW sourceforge site and replaced FBIDE's "mingwm10.dll" with the file of the same name contained in the download ("bin" subfolder):
fxm wrote:
Now with Win 10, I very rarely have such an error message when launching FBIde with Win10.
The next time I get it, I will exchange the 2 mingwm10.dll files without restarting the computer, to test your solution.
@Admins:
It would be nice if at least the link to FBIde in the 'readme.txt' file pointed to a download of FBIde updated with a recent 'mingwm10.dll' file.
This link is: https://fbide.freebasic.net/ (Download FBIde 0.4.6r4)
which points to: http://sourceforge.net/projects/fbide/f ... p/download (.../FBIde0.4.6r4.zip/download)
(by vongodric)