jhance
asked on
MFC GUI app started from DOS window
It seems to me that this has been addressed before but (as usual) I can't find it when I need it.....
I have an MFC GUI application. I am adding a command line capability. If the app is started from a command line it should:
1) Detect that it's been started this way, if possible. If it's not possible, then I'm OK with just using a command line arg to specify non-GUI.
2) If started from the command line, be able to input/output to the existing console with printf, etc. I know about ::AllocConsole() but this creates a new console. I want to use the existing one.
I have an MFC GUI application. I am adding a command line capability. If the app is started from a command line it should:
1) Detect that it's been started this way, if possible. If it's not possible, then I'm OK with just using a command line arg to specify non-GUI.
2) If started from the command line, be able to input/output to the existing console with printf, etc. I know about ::AllocConsole() but this creates a new console. I want to use the existing one.
ASKER
#1 is not that important, certainly not important enough to do a NT specific thing....
#2 Are you sure? I've seen this done elsewhere with just a single app and I thought I'd seen a write up on this somewhere...
#2 Are you sure? I've seen this done elsewhere with just a single app and I thought I'd seen a write up on this somewhere...
I've never tried to do anything like what you're asking, but I think what you need to do is create separate main and winmain functions. Console applications use the function main as their entry point, while Win32 applications use winmain. I'm afraid I can't give you more details than that, though.
The VC++ help has information in article mk:@ivt:vclang/F8/DA/S1D8B
The VC++ help has information in article mk:@ivt:vclang/F8/DA/S1D8B
ASKER
brandts:
mk:@ivt:vclang/F8/DA/S1D8B
is not very helpful. These links are MSDN version specific. What's the title of the article?
mk:@ivt:vclang/F8/DA/S1D8B
is not very helpful. These links are MSDN version specific. What's the title of the article?
I'm *quite* sure about #2, as I desparately tried to do the same a while ago (well, I'm not perfect ;-) - the problem is that a console app can display GUI elements to the user, but a GUI app cannot connect to the console it was started from. The last resort is 'AllocConsole()' :-(
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Mike,
Thanks for the comment.
Yes, I did read about this in your book and reviewed the HYBRID sample. It doesn't deal with this specifically. HYBRID creates a new console from a GUI, it doesn't link a existing app to an existing console.
I was almost positive I'd seen something else on this topic, perhaps a Dr. GUI note or something but I could be mixed up....
Oh well, I guess it's on to plan "B".
Regards...
Thanks for the comment.
Yes, I did read about this in your book and reviewed the HYBRID sample. It doesn't deal with this specifically. HYBRID creates a new console from a GUI, it doesn't link a existing app to an existing console.
I was almost positive I'd seen something else on this topic, perhaps a Dr. GUI note or something but I could be mixed up....
Oh well, I guess it's on to plan "B".
Regards...
>>If you link your application
>>/SUBSYSTEM:CONSOLE, you'll always get
>>a console window--that you can't
>>close!--even if you're launched from
>>some part of the GUI.
'FreeConsole()'
>>/SUBSYSTEM:CONSOLE, you'll always get
>>a console window--that you can't
>>close!--even if you're launched from
>>some part of the GUI.
'FreeConsole()'
> 'FreeConsole()'
FreeConsole() can close the console you get if your subsystem console app is launched from a subsystem Windows app, but:
1) You'll find that all the standard handles you used to have are broken (eg, stdout, stderr, cout, etc.)
2) You'll still suffer a flash as the console window appears and disappears.
I'd have to check with the systems guys, but I'd really recommend against using it--having your app free something it didn't allocate seems dubious to me.
..B ekiM
FreeConsole() can close the console you get if your subsystem console app is launched from a subsystem Windows app, but:
1) You'll find that all the standard handles you used to have are broken (eg, stdout, stderr, cout, etc.)
2) You'll still suffer a flash as the console window appears and disappears.
I'd have to check with the systems guys, but I'd really recommend against using it--having your app free something it didn't allocate seems dubious to me.
..B ekiM
You're right, I just wanted to object to "that you can't close!", which - as your comment implies - can be done...
>>but I'd really recommend against using it
It comes in handy to detach an application from the command line to do background processing (and should not occupy the console - it can be compared to 'daemonizing' a process on UN*X) - IMHO it's just a matter of what you want to do...
>>but I'd really recommend against using it
It comes in handy to detach an application from the command line to do background processing (and should not occupy the console - it can be compared to 'daemonizing' a process on UN*X) - IMHO it's just a matter of what you want to do...
You're right, I just wanted to object to "that you can't close!", which - as your comment implies - can be done...
>>but I'd really recommend against using it
It comes in handy to detach an application from the command line to do background processing (and should not occupy the console - it can be compared to 'daemonizing' a process on UN*X) - IMHO it's just a matter of what you want to do...
>>but I'd really recommend against using it
It comes in handy to detach an application from the command line to do background processing (and should not occupy the console - it can be compared to 'daemonizing' a process on UN*X) - IMHO it's just a matter of what you want to do...
"can be done..." isn't always the same as "a correct and safe thing to do".
..B ekiM
Well, unfortunately not always. But it is in this special case, otherwise I wouldn't have mentioned it.
#2 can only be achieved by using a 'proxy' non-GUI app (would make #1 obsolete...)