Feature request: instrisic Defines for console / gui mode

General discussion for topics related to the FreeBASIC project or its community.
marpon
Posts: 342
Joined: Dec 28, 2012 13:31
Location: Paris - France

Feature request: instrisic Defines for console / gui mode

Post by marpon »

Hi

I would be nice if we could have new intrisic defines for console / gui mode as : _FB_CONSOLE_ _FB_GUI_

to be able to do something like

Code: Select all

#ifdef _FB_CONSOLE_
PRINT "CONSOLE MODE"
#endif
or to avoid the pb of sleep when gui mode

Code: Select all

#ifdef _FB_CONSOLE_
PRINT "press key to continue"
sleep
#else
#error "sleep, used on gui mode"
#endif

as that option gui/console is known via the cmd line at compile time, i can imagine it would be quite easy to implement, i hope...
thanks in advance
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by jj2007 »

Windows only:

Code: Select all

  Case WM_PAINT
	PtDC=BeginPaint(hWnd, @ps)
	if GetConsoleWindow() then
		TextOut(PtDC, 3, 3, "Hey, we've got a console", 24)
	else
		TextOut(PtDC, 3, 3, "No console found", 16)
	endif
	EndPaint(hWnd, @ps)
marpon
Posts: 342
Joined: Dec 28, 2012 13:31
Location: Paris - France

Re: Feature request: instrisic Defines for console / gui mode

Post by marpon »

@jj2007
thanks for the trick, but it's not my request

I am asking an intrinsic define or 2 allowing conditionnal compilation as we have
__FB_OUT_DLL__, __FB_OUT_EXE__, __FB_OUT_LIB__, or __FB_OUT_OBJ__ and more...

to know the requested mode according the compile cmd line, it is much more general and allow much to do
marpon
Posts: 342
Joined: Dec 28, 2012 13:31
Location: Paris - France

New Feature : instrisic Defines for console / gui mode

Post by marpon »

As I expected it was not too hard to get 2 new defines

now we can have __FB_CONSOLE__ and __FB_GUI__ following the : -s console / -s gui compile cmd line state

only adding some lines in 4 files is enougth
in fbc.bas ; fb.bi ; fb.bas ; symb-define.bas

the lines are marked with '***** console/gui

it work without any difficulty on 32 or 64 :)

i put under the modified files and the exe files created on a zip file it is downloadable from Paul Squires forum
https://www.planetsquires.com/protect/f ... 4#msg32464

I hope , some admin can test and implement it on the github ( i don't know how to do and i don't have the rights...)

thanks all the community for this splendid compiler.


exemple to use

Code: Select all

#if __FB_CONSOLE__
print "Console mode"
print : print "Any key to close"
sleep
#endif

#if __FB_GUI__
#include "windows.bi"
messagebox(0, "Gui mode", "info",0)
#endif
adele
Posts: 47
Joined: Jun 13, 2015 19:33

Re: Feature request: instrisic Defines for console / gui mode

Post by adele »

this is a "Like"
Adi
marcov
Posts: 3452
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by marcov »

Does the -s commandline mean anything on *nix ?

On Windows console/gui is in PE/EXE fields, and the OS doesn't open consoles depending on it.

But on *nix, consoles are always created, gui apps just close them on startup ?
St_W
Posts: 1617
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by St_W »

No, unix does not support something like subsystems.

The option is ignored for targets other than win32/cygwin.
See also: https://freebasic.net/wiki/wikka.php?wakka=CompilerOpts
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Feature request: instrisic Defines for console / gui mode

Post by caseih »

Indeed on Unix machines, all processes can write to standard out and standard error, regardless of whether they are "graphical" or not. So distinguishing between console and GUI at compile time is meaningless. If a terminal is attached to the process's streams, you can see messages if the app emits them. Otherwise the streams are directed to /dev/null, and the app runs with only a graphical window visible (or none at all).

Similarly on Windows it is possible for an app to have a console window while also displaying a graphical window. Thus I'm a little unsure of what the use case is for these intrinsic defines.
marcov
Posts: 3452
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by marcov »

caseih wrote:
Similarly on Windows it is possible for an app to have a console window while also displaying a graphical window. Thus I'm a little unsure of what the use case is for these intrinsic defines.
Well, that can afaik happen in two ways.

- a gui program can open consoles for its stdin/out/err
- a console program can create a graphical window. This is sometimes encountered with programs and compilers with dos origins. Dos applications could simply swap into graphics mode. However in NT this is no longer possible or easy, so they create a GUI window.

In the first case the define will be gui, in the second console, since those are the types in the EXE sections which the compiler parameters influence.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: Feature request: instrisic Defines for console / gui mode

Post by caseih »

What do you mean it's no longer possible in NT? I've been compiling GUI apps as console apps with C# and C++ for debugging purposes and it works on Windows 10 anyway. I assume there's an implicit main() that calls winmain(). But I never see that.

Seems to me the behavior changes marpon is looking for depend more on run-time state than compile time. For example, if the destination of PRINT is the graphics window then he wants behavior a, otherwise if the destination of PRINT is the console, he wants to add a sleep. This is best determined at runtime in my opinion.
St_W
Posts: 1617
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by St_W »

We're mixing completely different things here. The options -s gui /console specify the subsystem to use. It is written into the exe file and cannot be changed at runtime. Neither does it matter whether a gui window is used (e.g. by calling Screen) or not.

The option whether the current output is a screen mode > 0 or a console can only be determined at runtime, in contrast. Thus compiler defines cannot be used for that.

In DOS there was a BIOS call that allowed to switch from text to graphics mode (screen in qbasic). There is no such thing in modern Windows.
adele
Posts: 47
Joined: Jun 13, 2015 19:33

Re: Feature request: instrisic Defines for console / gui mode

Post by adele »

Hi,
any one ever used the __FB_VER_PATCH__ ?
so what? if Win-Users can use Marpon´s contribution, why not?
It takes less effort to integrate it than to explain why some of us do _not_ need it.
Esp. because Marpon has done the work already himself.

Adi
St_W
Posts: 1617
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Feature request: instrisic Defines for console / gui mode

Post by St_W »

I mainly agree with adele. Although we shouldn't integrate a lot of very specific stuff only needed by single users (because it needs to be maintained, documented, etc. and finally just blows up the compiler) this addition could be helpful for a few others as well.

The only thing I'd like to discuss is the name. I'd rather call it __FB_SUBSYSTEM__ which can have the string values "gui" and "console" (or maybe "windows" and "console"?)
marpon
Posts: 342
Joined: Dec 28, 2012 13:31
Location: Paris - France

Re: Feature request: instrisic Defines for console / gui mode

Post by marpon »

Hi all,
happy my topic got some interrest!

let me try to explain, what was my intention:
I wanted to have conditionnal compilation according the state of -s console / gui used at compile time
i know it is only interresting for windows but I think, it"s still an important os...

As you have also discussed, it is related to "trace" facility, because the console can give you the opportunity to follow the execution with print informations.
So you can imagine the code has some print lines to do it, interresting when you test your code, but not when you use the prog.
if you don't have explicit define to know, the print is always executed (in dummy way) even not in console mode ( i mean also even without visible gui), that impacts the speed execution, and the size of the executable for nothing, with conditionnal compilation we can avoid that.

other point, the sleep ( without time value) found often at the end of many test programs,
if by mistake you compile with -s gui the program will never close when executed, you don't see it still executing, you have to kill the process...
and whith some ide, it is not detected until the fbc link time, (error 1 in most case)
not very easy for non expert people ( like myself , i've felt often into that trap)

so that why I was requesting ( and now it's done) that evolution
The only thing I'd like to discuss is the name. I'd rather call it __FB_SUBSYSTEM__
i don't like that proposal because nobody care about SUBSYSTEM, it's for me expert level again
it's different approach as done with outpout "exe,dll,lib,obj" ;
these defines are not groupped into only 1 and test the string to know what state it is

i prefer and it is simpler to understand because same philosophy as "exe,dll,lib,obj"
and i think the names __FB_CONSOLE__ and __FB_GUI__ are much more understandable (it is as you use -s console /gui)

last point, the code to make it
as you probably have seen, it's quite simple, i just mirrored the approach done with "exe,dll,lib,obj", so easy to maintain : not big headeck.

So, i'm on the same position as adele ( thanks for support),
it is done, it is simple, it can give something for some users, it does not give problems for users not using it...
lets implement it now on the rolling fbc version!
adele
Posts: 47
Joined: Jun 13, 2015 19:33

Re: Feature request: instrisic Defines for console / gui mode

Post by adele »

Hi,
The only thing I'd like to discuss is the name. I'd rather call it __FB_SUBSYSTEM__
i don't like that proposal because nobody care about SUBSYSTEM, it's for me expert level again
(..) and i think the names __FB_CONSOLE__ and __FB_GUI__ are much more understandable (it is as you use -s console /gui)
If it is __GUI__, it cannot be __CONSOLE__, right? And vice versa...
So let´s take the half ( just one of it, "MUTEX" ) and get the whole.

Adi
Post Reply