News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

advices about mixed console-gui app

Started by NCR, October 09, 2010, 02:20:02 AM

Previous topic - Next topic

NCR

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

ecube

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...

redskull

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
Strange women, lying in ponds, distributing swords, is no basis for a system of government

NCR

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!.

NCR

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!.

redskull

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
Strange women, lying in ponds, distributing swords, is no basis for a system of government

NCR

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