The MASM Forum Archive 2004 to 2012

General Forums => The Workshop => Topic started by: NCR on October 09, 2010, 02:20:02 AM

Title: advices about mixed console-gui app
Post by: NCR on October 09, 2010, 02:20:02 AM
Hi!,

i'm one of the developers behind fuu (code.google.com/p/fuu) and i'm looking for some advice.

For the next version of FUU, we want to re-desing the program, basically, we want to separate the core functions from the GUI and add a console version of FUU and that is one of our major problems. let me explain a little bit more my idea. we have some ideas about how to implement the mixed console-GUI version but, to be honest, i don't like very much none of those solutions, so, i'm here to ask if you can give me some advices about this, can i implement a console version and, for example, add a parameter like "-g" to indicate that my console app must run as GUI?. i've been looking a while on the net for some tip about it but i did not find anything.

what is the solution i like the most?, well, basically, distribute two flavors of the same app, a console version and a GUI version.

Thanks in advanced!,
NCR
Title: Re: advices about mixed console-gui app
Post by: ecube on October 09, 2010, 03:36:13 AM
Hi NCR, nice project. I don't know exactly what you want but you can absolutely mix console/GUI. You can use the GetCommandLine (http://msdn.microsoft.com/en-us/library/ms683156%28VS.85%29.aspx ) to see any passed parameters to it. in MASM32 SDK the function GetCL uses that and helps parse parameters easy.

invoke GetCL,0,addr mybuff ;should contain your exes fullpath+name
invoke GetCL,1,addr mybuff ;should contain the first param passed for instance -g

etc...
Title: Re: advices about mixed console-gui app
Post by: redskull on October 09, 2010, 05:26:23 PM
A lot of how 'well written' the program is will determine how easy a mixed-mode alteration is; if you do all your domain logic within the GUI message handlers, you are more-or-less SOL, and will essentially have to write an entire second version of the program.  If, on the other hand, your user interface is seperate from your program logic, then you can just call the same functions from either the console part or the GUI part.  Google "model-view-control", or pick up a design patterns book , etc.

-r

PS - mods, please don't suspend my account for suggesting design patterns  :toothy
Title: Re: advices about mixed console-gui app
Post by: NCR on October 10, 2010, 06:30:44 PM
Quote from: E^cube on October 09, 2010, 03:36:13 AM
Hi NCR, nice project. I don't know exactly what you want but you can absolutely mix console/GUI. You can use the GetCommandLine (http://msdn.microsoft.com/en-us/library/ms683156%28VS.85%29.aspx ) to see any passed parameters to it. in MASM32 SDK the function GetCL uses that and helps parse parameters easy.

invoke GetCL,0,addr mybuff ;should contain your exes fullpath+name
invoke GetCL,1,addr mybuff ;should contain the first param passed for instance -g

etc...

Hi E^cube!,

Thanks for your answer.

I know how to get the parameter with GetCommandLine but that is not my problem. I will try to explain me better. My problem is that i just want to distribute a single exe but if the user run it from the cmd as "fuu.exe -g", then, my app will run in gui mode, but, if the user run it with another parameter, then, the app will run just in console mode. that is the main idea. can i do this? do i need to assembly the project as GUI or console? i know i can use the AllocConsole from a GUI app but i'm not sure if that is the best solution, i think the best solution would be if i can create a single console app and trigger a GUI or console mode by parameters.

anyways, i will check the code you told me about!.
Title: Re: advices about mixed console-gui app
Post by: NCR on October 10, 2010, 06:37:58 PM
Quote from: redskull on October 09, 2010, 05:26:23 PM
A lot of how 'well written' the program is will determine how easy a mixed-mode alteration is; if you do all your domain logic within the GUI message handlers, you are more-or-less SOL, and will essentially have to write an entire second version of the program.  If, on the other hand, your user interface is seperate from your program logic, then you can just call the same functions from either the console part or the GUI part.  Google "model-view-control", or pick up a design patterns book , etc.

-r

PS - mods, please don't suspend my account for suggesting design patterns  :toothy

Hi redskull!,

i agree. our problem is with the implementation of the mixed gui-console app. we can't find any good solution to do it except the one i told you in my first message, to distribute a console version and a separate gui version.

if anyone has an example of a mixed gui-console app in masm it would be great!.
Title: Re: advices about mixed console-gui app
Post by: redskull on October 10, 2010, 07:10:19 PM
There really is no difference between a Console and a GUI app; either type can freely use the entire range of the Win32 API.  Console apps can open windows, and GUI apps can use consoles.  The only difference is that when you link with the /SUBSYSTEM:CONSOLE switch, Windows allocates a new console for you or inherits the existing one if launched from cmd.exe (presumably to make it easier for DOS programmers to port to Windows).  All you have to do is test for the command line switch you want, and either call AllocConsole() or CreateWindow() as appropriate.

VLC media player is a good example of an application that uses both the console or a GUI window.

-r
Title: Re: advices about mixed console-gui app
Post by: NCR on October 12, 2010, 11:14:21 AM
ok then, i will do some test and i'll let you know!.

Thanks!.

Quote from: redskull on October 10, 2010, 07:10:19 PM
There really is no difference between a Console and a GUI app; either type can freely use the entire range of the Win32 API.  Console apps can open windows, and GUI apps can use consoles.  The only difference is that when you link with the /SUBSYSTEM:CONSOLE switch, Windows allocates a new console for you or inherits the existing one if launched from cmd.exe (presumably to make it easier for DOS programmers to port to Windows).  All you have to do is test for the command line switch you want, and either call AllocConsole() or CreateWindow() as appropriate.

VLC media player is a good example of an application that uses both the console or a GUI window.

-r