FreeBASIC Integrated Development Editors (IDEs)

Started by Donald Darden, June 19, 2007, 10:42:36 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Donald Darden

Many programmers are now accustomed to using an IDE as their primary interface to a development language.  The hands-on method of using Command Line prompts may strike them as needlessly cumbersome and slow.

Well, fear not.  There are a large number of editors that can be used with FreeBasic, just as they can be used with PowerBasic or other compilers.  But rather than focus on ones that cost you, here is a short list of some free ones that might
be worth trying:

FBIDE  http://fbide.freebasic.net/

RQ Debugger IDE b455 http://www.freedownloadscenter.com/Search/search.php3?q=freebasic%20ide
http://mira.xeno.ru/downloads.htm

QBLIDE  http://opencollabnet.ohloh.net/projects/4243

FBEdit Pro 99 1.0 http://www.freedownloadscenter.com/Games/Gaming_Utilities/FBEdit_Pro_99_Download.html

Far from just being a lazy man's way of editing and compiling programs, a good IDE also let's you check syntax, supports selective coloration and use of  character cases, handles indentation and line-wrap issues, cut-and-paste between different sections of the same source file or multiple files, and supports a debugging capability.  For everything beyond the most trivial efforts, it is common to need to set breakpoints, watch variables and registers, and either step though a slow execution of the code, or monitor for runtime errors that indicate an execution error of some kind.  A good IDE and Debugger combination can do more to help you understand what is going on, and assist you in learning to properly code a computer, then virtually any other resource.

Paul Squires

Paul Squires
FireFly Visual Designer SQLitening Database System JellyFish Pro Editor
http://www.planetsquires.com

Greg Lyon


Donald Darden

#3
I've been using FBIDE for about a week now.  It's okay, but it lacks some features that would make it even more valuable.  I am sure it will continue to evolve and get better with time.

First limitation is that under settings, you cannot name paths for things like BAS,
INC, LIB, and ASM files.  You might also want the ability to define settings for
specific projects.

Second limitation is that while the IDE does highlight some of the syntax, it does
not highlight everything.  For instance, you enter function and it makes it function, so you know that is good.  But if you enter end function, it only make it into end function, which might scare the pants off you if you were not comfortable with the language.  You might also like to see some case enforcement, such as changing function to FUNCTION for better readability and consistency.

Also neglected is highlighting of assembly instructions.  and maybe some help on
standardizing the indents, cases, spacing, and so forth.  Assembly can be made
free form, but most assembly listings tend to be rather structured, so why not?

Aother problem is the cryptic settings dialoge that appears under View.  No help on what you could put there, and what does something like "<$file>" signify? What can you change it to?  What are your options?  Too cryptic for me by far.

There are many command-line parameters allowed when you call fbc.exe, which is the FreeBasicCompiler.  That would also require a bretty substantial dialoge to appear to allow you to select which ones you want to use.  You have the option to link to existing OBJ files for instance, but you need to be able to spedify which ones, either by identifying them as part of the project, by a path, or by explicitly naming them.  You need to be able to designate that you want to create a DLL file rather than an EXE file, or that you want to retain the ASM file that is produced as a byproduct during the compile process.

FBIDE also currently only allows one file to be opened in the editor.  That would be a serious drawback for complex editing tasks involving cut and paste, or copy and paste.  It currently keeps checking to see if you really want to save changes to the existing file when you want to do a test compile or compile and run, and that dialog gets tiresome very quickly.  The best alterantive is to allow you to keep an automatic backup, with a revert reature if you want to go back, or an undo feature that can step back through recent changes.

FBIDE is not bad for what it is, and I didn't mind working with it as long as I did, but it is time to move one and see if there is anything better to go with.

Donald Darden

#4
I decided to try the RQ Debugger IDE next.  RQ stands for RapidQ, and is, or was, an interpretive Basic that runs under several operating systems.  I've only seen a bit of the source coding that could be done in RapidQ, but based on what I saw, I was once anxious to see it continue.  I don't know the whole story, but I believe the developer had a job offer that he could not afford to turn down, but a condition of the hire was that he would not continue his efforts on RapidQ - after all, someone hires you for your programming talent, they don't want you spending all your time on your own projects.  So als, it went into decline.  I did note that the while shooting match was offered as nearly a 3 Megabyte download, but that link and the first fiew I tried for just the IDE failed, telling me the file could not be found on the server.  I added a link to the post above for one that did work.  I've only just unzipped it, but a quick look showed me quite a few features.  Let's see how this goes.  The RQ Debugger IDE link says it is for both RapidQ and FreeBasic, so I have hopes that it will prove to be fairly robust.

Okay, I've had the RQ Debugger IDE on my machine for about an hour, and that
is long enough.  It is really designed to support RapidQ, and so far the FreeBasic
support is just incidental.  In order to use it with FreeBasic, you have to find Options on the Toolbar, And under Options you have to find Directories (the third tab), then go down to the bottom half, and set a path to where your FreeBasic
compiler is located.  Make sure you include the end backslash (\), and do not include the compiler name.  You can't save this, so you end up having do do this every time you enter the IDE.  Go ahead and enter your souce code or load a
FreeBasic source file, but then in order to compile it, you have to click on the
button for the FreeBasic compiler, which is located on the task bar right next to
where it says DLL.  It will compile, and you can toggle around to see the Console Window if you want to.  Closing your console window will also take you out of
the IDE, so you have to start all over.  Too much effort involved, so I consider
this program to be too early in its development to be really useful.

However, the support it lavishes on RapidQ is remarkable, and the developer says he wants feedback, so your suggestions may lead to a product that really
works as well for FreeBasic as it does for RapidQ.  I see evidence of setting hot
tabs, incorporating windows graphical elements on the fly, creating complete
projects, selecting fonts and colors, supporting a debugger and trace capability,
and a whole lot more.  If you are interested in eventually seeing a really great IDE for FreeBasic, this product shows great promise.

Donald Darden

#5
Presently, QBLIDE seems to be vaporware.  I found one review on it, and comments that it is written in Visual Basic, but there is no download link, and the directory on SourceForge is empty.  No download links found.  So don't waste your time looking further.

FBEdit is available and can be downloaded.  When installed, the background color was black, which I hate.  I did find that you can change the color scheme, which I did.  No evidence of keyword highlighting or case control, but it is set up to work primarily with projects. which can be a good thing. I got it to compile a test program, but it failed to run it.  There is also a GO button which might mean compile and run in one step, but that did not work either.  You can modify paths and compiler call options, so at least it shows the possibility of being configurable to the point where some of these shortcomings can be resolved.   I'm not too happy about not seeing keywords being flagged, as this is a good check for possible typos and such.  I will have to play with it awhile longer, but it seems to have potential.

Let me just put this out there:  Anybody want to write an editor to meet the needs of developers has to really think in terms of individual preferences.  Colors, fonts, screen size, arrangement of dialogs, indentation, capitalization, bold, italic, it doesn't make any difference.  If there are choices, developers want to be able to pick and choose.  If you don't give them choices, they will not be happy and will look until they find what they want or what they are accustomed to using.

Right now I am going to spent a bit more time with PBEdit and see if I can tweak it around to what I want for my IDE.  You are welcomed to keep on looking if you like, and report back what you find, and what you like or dislike about what you find.

Okay, this is interesting.  I made a shortcut to PBIdit on my desktop and called it  p again.  This time when I tried the Run and GO options, they worked fine.  No idea why they did not work earlier.  So anyway, that is one impression that has been rectified.

I finally found Code Editor under Options that allows you to make certain changes to the font and colors.  You can't increase the size of the text, and the check boxes under Case Convert don't seem to do anything, but I managed to make the text darker - dark enough to discern that keywords are being set to their own color, which was one of my concerns.  But at a distance, I really need the keywords set to upper case for readability.  I found the Case Convert option again under Format, but whether I select that, highlight a portion of the source code and press again, the case never changes.  That seems to be a minor bug to be fixed.  All in all, of the four free IDEs found mentioned for FreeBasic, the FBEdit seems to be closer to a finished product than the others. 

Donald Darden

I was pleased with having some control over the IDE that PBEdit supplies, so I wanted to see what else I could do.  Looking under Options again, you see a button called Build Options.  When you left click on it, you will see a dialog open up with several options listed, which probably includes Windows GUI, Windows GUI (Debug), Windows Console, Windows Console (Debug), Windows DLL, and Library.  If you click on each link, you will see the two lower fields change, with the second field showing a compiler call with different switches.  You will also see an Insert and Delete button on the right.

As an experiment, I selected Insert, and a blank place appeared in the list.  I then typed in Compile and Keep ASM File for my menu item, and fpc -r for my command.  I then picked one of my test BAS files and loaded it, then did a compile with my new build option selected (the current build option appears in a box on the right side of the tool bar).  This is the test file I compiled:

dim aa as string
dim a as long, b, c, d, e, f, g, h
color 15,1
cls
aa="This is a test."
a=12345
print aa, "a ="; a
do while inkey$=""
loop

The next thing I did was attempt to open another file, but this time I indicated that I wanted to see all files, then I picked the one labelled test.asm.  This is the file that was created using the fbc -r "test.bas" command, used by the IDE in response to my new build option.  The FBEdit then opened another file tab and showed me the contents of the resulting ASM stage.  Thus, I now had this file on my screen:

.intel_syntax noprefix

#test.bas' compilation started at 22:40:36 (FreeBASIC v0.15b)

.section .text
.balign 16

.globl _main
_main:
push ebp
mov ebp, esp
and esp, 0xFFFFFFF0
call ___main
push dword ptr [ebp+12]
push dword ptr [ebp+8]
call _fb_Init@8
call _fb_CallCTORS
.Lt_0001:
push 1
push 15
call _fb_Color@8
push -65536
call _fb_Cls@4
push 0
push 16
push offset Lt_0003
push -1
push offset _AA
call _fb_StrAssign@20
mov dword ptr [_A], 12345
push 2
push offset _AA
push 0
call _fb_PrintString@12
push 0
push 3
push offset Lt_0004
call _fb_StrAllocTempDescZEx@8
push eax
push 0
call _fb_PrintString@12
push 1
push dword ptr [_A]
push 0
call _fb_PrintInt@12
.Lt_0005:
push 1
push offset Lt_0000
push -1
call _fb_Inkey@0
push eax
call _fb_StrCompare@16
test eax, eax
jne .Lt_0006
jmp .Lt_0005
.Lt_0006:
.Lt_0002:
push 0
call _fb_End@4
mov esp, ebp
pop ebp
ret
#test.bas' compilation took 2.86069876599626e-004 secs
#global initialized constants

.section .data
.balign 16
.balign 4
Lt_0000: .ascii "\0"
.balign 4
Lt_0003: .ascii "This is a test.\0"
.balign 4
Lt_0004: .ascii "a =\0"
#global non-initialized vars

.section .bss
.balign 16
.balign 4
.lcomm _AA,12
.balign 4
.lcomm _A,4
.balign 4
.lcomm _Bi,4
.balign 4
.lcomm _Ci,4
.balign 4
.lcomm _Di,4
.balign 4
.lcomm _Ei,4
.balign 4
.lcomm _Fi,4
.balign 4
.lcomm _Gi,4
.balign 4
.lcomm _Hi,4

This is the partial result in assembly form created during the compile process.
The only part really missing are the automatic constructs needed for actually
creating the resulting EXE file, and the appended procedures you see that are being called, and other procedure that might be called in turn, as these would be needed to complete the program.  These results are somewhat unstructured,
in that most assembly code is indented and aligned vertically, but still very useful.  Now we are going to look at the same assembly results again, and this time try to deduce what might be going on.  Not being real familiar with FreeBasic, I can only draw some preliminary conclusions at this point.  But you have to start somewhere:

.intel_syntax noprefix

#test.bas' compilation started at 22:40:36 (FreeBASIC v0.15b)

.section .text                       'we saw with IDE PRO that this was the CODE section
.balign 16

.globl _main                         'Since no function was started, this must be the main code
_main:
push ebp                             'we've discussed saving EBP contents on stack before
mov ebp, esp                       'then using EBP to hold current ESP contents
and esp, 0xFFFFFFF0             'here the contents of ESP are forced to align16
call ___main                         'this is FreeBasic's Main procedure
push dword ptr [ebp+12]        'an existing value on stack is pushed on stack again
push dword ptr [ebp+8]         'a second existing stack value is pushed on stack again
call _fb_Init@8                     'another FreeBasic procedure is called
call _fb_CallCTORS                'and another FreeBasic procedure is called
.Lt_0001:
push 1                                'first parameter pushed is background color (Blue)
push 15                               '2nd paramter pushed is forground color (Br White)
call _fb_Color@8                    'this is the COLOR command routine in FreeBasic
push -65536                          'This is a parameter for the CLS command
call _fb_Cls@4                       'this it the CLS routine for FreeBASIC
push 0                                 'we are probably singnalling at same location 
push 16                               'we need 15 bytes, plus 1 for a null terminator   
push offset Lt_0003               'and the stromg constant starts here
push -1                                'and we want to assign this to a dynamic string
push offset _AA                     'that we allocated to start here
call _fb_StrAssign@20            'this sets our dynamic string to the constant
mov dword ptr [_A], 12345     'now we do the "a = 12345"  FB instruction
push 2                                 'we signal that we want a tab done first 
push offset _AA                    'and what we want to print next 
push 0                                 'probably the device to print to (console)
call _fb_PrintString@12           'this will perform our FB "print aa;" instruction
push 0                                 'print at current location again
push 3                                 'the string consists of three characters
push offset Lt_0004               'this is where our "a =\0" constant is stored
call _fb_StrAllocTempDescZEx@8  'make this into a temporary dynamic string
push eax                              'eax contains where the temporary string is   
push 0                                 'print to the console screen again
call _fb_PrintString@12           'this is what does the string printing
push 1                                 'indicate that we are pushing a numberic value
push dword ptr [_A]               'put the value on the stack (12345)
push 0                                'print to console screen flag
call _fb_PrintInt@12              'this routine is what prints integers
.Lt_0005:
push 1                                'indicate just one byte
push offset Lt_0000              'push a null byte on stack
push -1                              'could indicate device, or nowait state?
call _fb_Inkey@0                  'This is where FB does the INKEY$ function
push eax                             'put the return code from INKEY$ on stack
call _fb_StrCompare@16        'see if it is a match for the null byte on stack
test eax, eax                       'see if the results in EAX are a match
jne .Lt_0006                        'if no match, we are done
jmp .Lt_0005                       'it was a null char (or no keypress) so loop   
.Lt_0006:                           'a key was pressed, so here we are
.Lt_0002:                           'seems there is always a label after a LOOP 
push 0                               'We set a zero as our return code
call _fb_End@4                    'FreeBasic's END routine, restores saved regs
mov esp, ebp                      'This is that neat trick that allows the ESP to be wiped of temps
pop ebp                              'and final step to restore EBP from stack
ret                                     'and we are done
#test.bas' compilation took 2.86069876599626e-004 secs
#global initialized constants

.section .data
.balign 16
.balign 4
Lt_0000: .ascii "\0"
.balign 4
Lt_0003: .ascii "This is a test.\0"
.balign 4
Lt_0004: .ascii "a =\0"
#global non-initialized vars

.section .bss
.balign 16
.balign 4
.lcomm _AA,12                'this is dynamic string variable AA
.balign 4
.lcomm _A,4                   'this is long variable a
.balign 4
.lcomm _Bi,4                   'this is long variable b 
.balign 4
.lcomm _Ci,4                   'this is long variable c
.balign 4
.lcomm _Di,4                   'this is long variable d
.balign 4
.lcomm _Ei,4                   'this is long variable e
.balign 4
.lcomm _Fi,4                   'this is long variable f
.balign 4
.lcomm _Gi,4                  'this is long variable g
.balign 4
.lcomm _Hi,4                  'this is long variable h

Like I said, without examining the actual FreeBasic routines, it is just a best
guess as to what the routines do (the names help) and what the parameters
on the stack represent.  Since the IDA PRO disassembler converts the whole
EXE file back into ASM form, it can be useful for examining the various FB routines and seeing what they really do, how they work, and what the passed
parameters really represent.

Donald Darden

#7
There seems to be some stability problems with FBEdit, and a surprising lack or two.  Trying to use it today, Ifound that whenever it type something like dim as as string, it would attempt to open a dialog box as soon as it recognized the keyword as.  Only as space for the box would appear though.  Then when I typed the keyword string , it would GPF.  I could get around this by using the ESC key, which would close the attempted dialog box, but I found it to be disconcerting.

Another problem showed up is that the help files could not be opened.  I have three provided, one each for Win32, FreeBasic, and FBEdit, but today I could not get them to open by clicking on them.  And if I used the F1 key, the only one that would respond was Win32 Help.

I stand corrected; I found that I can resize text as well as select the font for code and for line numbers.  Not sure why I reported otherwise before, but i've been downloading FBEdit from different internet sites, and at least the one I am on now gives me resizing capabilities.  I've also sent an email to the guy in the credits, to see if there is a newer version, or if he wants bug reports about the product.

I regard the inability to get keywords to change case as a slightly more serious problem, and the inability to adjust the indent in response to command (under Format), an irritation to be mentioned, I also found that there is no way to set a Command Prompt that can be returned by COMMAND$ when you test drive or debug your program.  Now that is somewhat aggrevating if you intend to use the command prompt when having your program called.  There is a button called Command Prompt, but it just takes you to the command promptm which is altogether a different matter.

I hope efforts to develop one or more of these editors continue, but right now I don't see any as being a done deal.

I decided to see if I could use FreeBasic with a DLL, so I whipped up a little one in PowerBasic with a single function, and tried to declare it in FreeBasic.  My first problem with FreeBasic is that the Help file is incomplete, and wrong.  Under DECLARE, there is no mention of using it with DLLs - I finally found my first mention when I tried the keyword LIB.  But before that, I had to go under Options and set my paths manually for Help to point to Win32.hlp, fb-manual.chm (it wanted fb.chm initially), and FbEdit.chm.  At least it can access help files in the old .HLP or the newer .CHM formats.  But the F1 key still fails to come up to give in context help, so I opened the FreeBasic help file by clicking on the button and typing in the search term myself.

Even though I finally found DECLARE that used ALIAS and LIB to access external
processes in from shared libraries, the syntax given was:

DECLARE FUNCTION FuncName ALIAS "XFuncName" LIB "test.dll" (a1$, a2$) AS LONG

And it turns out this is wrong.  It was probably right at one point, but I had to
search out other examples, and they used this format instead:

DECLARE FUNCTION FuncName LIB "test.dll" ALIAS "XFuncName" (a1$, a2$) AS LONG

Note how ALIAS and LIB have swapped positions.  Noting some comments in the log in passing, it seems that ALIAS doesn't do anything for you unless you export a function and need to reference it in another program, so it really ties in with LIB.  So apparently the decision was made that LIB needs to come first, and ALIAS is now required if you use LIB.  Whatever.

So I tried to call my PB dll from a little FB program, and I was told that the
compiler could not find my DLL file.  After wasting some time making sure that
I had the exact path, and there were no conflicting options involving paths,
I finally used the command prompt to try and use ld.exe directly to load the
DLL file.  The error message there was that it essentially could not find the
Main entry point to initialize the DLL. and was assuming a default address point.
FBEdit was incorrect in the error that it returned.

So I went looking for a DLL example already coded in FB, and found one under
examples\dll called mydll.bas.  It gives you a simple example, even has the
necessary fbc -dll mydll.bas command line call commented in, but then it
talked about mydll.bi, and a second produced file called mydll.dll.a that has to
be an import library reference when you compile your own program to call
any procedure in mydll.dll.  So I tried to read up on import or import library in
the FreeBasic Help file, and that section gets an error because it has not been
written yet.  The mydll.dll.a is a binary file, and I have no idea what it does.

So I decided to begin with just using the FreeBasic files, mydll.bas, Test,bas,
and TestLoad.bas.  when you compile fbc -dll mydll.bas, you get mydll.dll and mydll.dll.a, just as it says you should.  But when you compile and run Test.bas, which is suppose to show a typical use, the ld.exe program cannot find mydll.dll.  And when you try to use TestLoad.bas, which is suppose to show how you can test for mydll.dll being one the target system before you try to call it (this is dynamic or run-time loading and checking), again it could not find it.  I tried hard-coding the exact path to mydll.dll into Test.bas and TestLoad.bas, but it still could not find it, at least that is what it says.  If I try ld.exe directly, I might get a different response.

Right now, it appears that both FreeBasic itself and FBEdit are well short of
their final stable and fully functional versions.  Faced with any type of deadline,
the real choice here would seem to be PowerBasic.  I will be off the forums for a couple of days, and I hate to end this thread on such a note, so if anyone is
having more success, I would really appreciate if if they would fill in some of the missing blanks about creating and using DLLs with FreeBasic (and using PB DLLs
with FreeBasic if they can).
 

Donald Darden

I just got an email response from Ketil Olsen, the fellow that appears to be the
kingpin of FBEdit.  I quote in part:
QuoteThanks for your interest in FbEdit

For a first time installation i recomend FbEdit bundle
http://fbedit.freebasic.net/download.php?id=59&f=15
It contains everything you need to get started.

I downloaded the bundle and installed it over my existing installation, and though I have only had time for a curosry glance at it, it seems to have taken care of some of the issues I was having with the Editor.  I have to conclude that my other attempts to fetch and install FBEdit were to sites with earlier versions.

Theo Gottwald

#9
Have taken a short look on that bundle.
From the options etc. it looks quite Ok.

As said before, as a free tool it is an alternative,
and it is visible that they have already put a lot of work into it.

If you need 100% reliability on the result, you may take PB instead
because it is just several years ahead in terms of stability.