WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V3.1.0 June 4, 2023)

[PaulSquires]

I'm not sure that the capture of the STDERR output is the right solution, because it is necessary that a compiled program (under the IDE with -exx) also works when it is launched directly from a command window, and It continues to be able to display a runtime error message on the command window.

For the 3 working IDEs that I know, they all open a command window, run the program, and then wait for a key press before closing it (an eventual runtime error message is always displayed on the command window itself).

Sure, I could code it that way but it is not the most elegant solution. Capturing the error output allows me to position the editor to the offending code. It also looks cleaner and more professional :-)

[PaulSquires]

We can redirect to get stderr message, but the normal output and input will gone, so I think the solution is as fxm says...

My understanding is that PRINT goes to STDOUT. If I only capture STDERR then only the error messages get captured and anything else being printed to the console window should be fine. I am a little concerned that fxm can't see the PRINT statements in the last two WinFBE versions whereas I can. I am using Windows 10.

[fxm]

Yes, "CONSOLE" and "FBC 32bit" were well selected.
I am using Win7.

1)
Versions 1.3.7 and 1.3.8 (with code 'PRINT "OK" : SLEEP'):
- The command "Run Executable" works (after any compilation): the console window appears and "OK' is printed to it, waiting for a keypress.
- With the command "Build and Execute" or "Rebuild All": the compilation is successful, but after keying "OK", an empty windows appears and using the close button (X) is mandatory to close it (keypress is unsuccessful).

Same behavior for "FBC 64bit".
Same behavior using WinFBE32 or WinFBE64.

Remark in case of code inducing a runtime error:
- Only the commands "Build and Execute" and "Rebuild All" display the error message at execution time.
- The command "Run Executable" alone does not display the error message at execution. For example, a sequence with "Compile" followed by "Run Executable" does not display the runtime error message (in fact, it appears very furtively on the console window just before its automatic closure, as if there is no modification compared to revision 1.3.6).
(undoubtedly this is linked to the fact that 'Print "OK"' works with "Run Executable" and not with "Build and Execute")

2)
All is right with version 1.3.6 (for code 'PRINT "OK" : SLEEP').

3)
General remark on the command "Run Executable":
The executed file name is always the last compiled, not necessarily the one selected for the current edition, even if such a previously compiled file exists already.

[fxm]

Look at this post of dkl (viewtopic.php?f=4&t=24383#p215783)

Hi,

like many programs, fbc returns a non-zero exit code in case of an error. You can check the result of the shell() function to detect this.

Code: Select all

var result = shell("fbc -version")
select case result
case 0
	print "ok, it worked"
case -1
	print "command not found (or other shell() failure)"
case else
	print "command aborted with exit code " & result
end select

By the way, fbc prints error messages to stdout, not stderr (yea, that's rather non-standard).

If you want to capture the error messages, check out Open Pipe.

[Kuan Hsu]

We can redirect to get stderr message, but the normal output and input will gone, so I think the solution is as fxm says...

My understanding is that PRINT goes to STDOUT. If I only capture STDERR then only the error messages get captured and anything else being printed to the console window should be fine. I am a little concerned that fxm can't see the PRINT statements in the last two WinFBE versions whereas I can. I am using Windows 10.

The same result as fxm, I'm using Win 7.

In my case, when set the dwFlags = STARTF_USESTDHANDLES and create pipe to get STDERR message, but STDOUT and STDIN handle will lost. so if I redirect to STDERR, normal STDOUT won't print~~ I combine fxm's code to test:

Code: Select all

Sub s()
  Dim As Integer Ptr p
  Print *(p+1)
End Sub

print "OK"
sleep
s()

Maybe the issue is by OS version???(Win 7 vs Win 10)

In Linux, I can get the STDERR message and STDIN and STDOUT keep working( but I don't know how to open a console window form my IDE, using "gnome-terminal -e" can create a console window but the message is catch by gnome-terminal )

[PaulSquires]

This is an interesting discussion. I just tried the examples on Windows 7 and I am getting the same results/behaviour as both of you have found.

By the way, fbc prints error messages to stdout, not stderr (yea, that's rather non-standard).

Well, that pretty much ensures that myself and Kuan will have to implement the command window solution rather than using pipes, etc. Too bad but sometimes things don't always work out as planned. :-)

[marcov]

IIRC I tried to solve that with separate pipes for both stderr and stdout (using createprocess), but then you have to take care to poll both pipes regularly, since one gets about 10MB ahead of the other, the process stalls and you get a deadlock

[fxm]

Nevertheless, have you noticed my little remark about the operation of the command "Run Executable" ? :

3)
General remark on the command "Run Executable":
The executed file name is always the last compiled, not necessarily the one selected for the current edition, even if such a previously compiled file exists already.

I think that the compiled file to be executed (from command "Run Executable") should only be the one corresponding to the selected source file being edited. If it does not exist, the command should remain grayed out (or an error message is displayed as with poseidonFB).

[PaulSquires]

Nevertheless, have you noticed my little remark about the operation of the command "Run Executable" ? :

3)
General remark on the command "Run Executable":
The executed file name is always the last compiled, not necessarily the one selected for the current edition, even if such a previously compiled file exists already.

I think that the compiled file to be executed (from command "Run Executable") should only be the one corresponding to the selected source file being edited. If it does not exist, the command should remain grayed out (or an error message is displayed as with poseidonFB).

Thanks fxm, yes I will make these changes. Hope to have a new version on GitHub this evening.
I am now looking at the way that the other editors handle the launching of the exe with the command window just to ensure that my approach is consistent.

As an aside, the "Rebuild All" functionality was added in order to recompile all *.obj that exist for a project. In WinFBE, if you work with a project, the editor creates a subfolder called .wfbe and stores all compile object files for the project in there. For a large project like the FB compiler itself, there can easily be over a hundred source files. WinFBE uses a kind of poor man's MAKE approach by comparing source file time stamps and object file time stamps to determine what source files need to be incrementally compiled to object files. The result is that large projects can be recompiled extremely fast.

In order for the above approach to be effective you need to structure your project so that you are creating individual bas files that compile to obj files that when all combined together will form your exe. In WinFBE you need to specify what type of file each source code file is in your project. There are several ways to do this such as right click on the source code and select either "Normal file", "Module file", Main file", "Resource file". Another fast way is to click on the statusbar panel that holds the description and select from the resulting popup menu.

Personally, given the speed of modern computer hardware and the compiler itself, I find it easier, less complicated, and convenient to simply #INCLUDE my source files into the main bas file. The difference in compilation speed is pretty negligible in most cases of projects of small and medium size.

[fxm]

Me too, each time, I always include the sources of my various modules reused in the main program in development, without ever building libraries (static or DLL) or even compile separately the different modules (as when I was young with QuickBASIC).

[Josep Roca]

Me too, each time, I always include the sources of my various modules reused in the main program in development, without ever building libraries (static or DLL) or even compile separately the different modules (as when I was young with QuickBASIC).

Then maybe you could be interested in the technique that I'm using in my CWindow framework to benefit of dead code removal. It is pretty simple: instead of .bas modules, I use .inc files and declare all the procedures and methods as private. Only the procedures and methods being called will be added to the .exe. This allows to have include files with hundreds of general purpose procedures and extensive classes without bloating the executable.

With modern hardware, compiling is slower only the first time that you use the framework. Then, Windows caches the files and subsequent compilations are quite fast.

[fxm]

This method is effective only if there are many independent procedures in the file constituted with all inclusions (which is not at all the general case). Indeed, the procedures that call each other will always be compiled even if none of them are really called in the program execution (the exclusion rule is simplistic, otherwise the compiler should build and test elaborate call trees).

[Josep Roca]

It all depends of the granularity of the code. For example, I have a class, CFileSys, with 59 methods. If I use DIM pFileSys AS CFileSys : print pFileSys.DriveExists("C:"), only the constructor and the DriveExists and SetResult methods are included in the .exe. If the class was in a module or a library, all the methods will be compiled.

> otherwise the compiler should build and test elaborate call trees

That would be fantastic, but I'm not going to hold my breath waiting for it.

[PaulSquires]

Version 1.3.9 (July 25, 2017)
- Added: Option (Environment Options :: Compiler Setup) to run compiled programs from a spawned command window. Useful for catching runtime errors.

https://github.com/PaulSquires/WinFBE/releases


Not in this release but coming soon:
- enhancing the logic for "Run Executable".
- implement option prompt user for confirmation with messagebox when closing the editor.
- implement a Build Options dialog in order to create user defined compile/build options. Release, Debug, 32bit, 64bit, etc....

[fxm]

It's perfect for me (for the runtime errors displaying)!