On Thu, Apr 12, 2012 at 5:34 PM, REPLeffect repleffect@gmail.com wrote:
On Thu, Apr 12, 2012 at 4:05 PM, Mikael mikael.rcv@gmail.com wrote:
Den 12 april 2012 23:44 skrev Marc Feeley feeley@iro.umontreal.ca:
My question is this: is it important that your application be a "windows" application? What are the benefits over a "console" application.
"console" applications are good for apps where you have a practical use of the app being hardwired to the presence of a console window only. So it's a nice default setting for developers, to have a console to print out to, take text input, and so on.
The issue is just that "console" applications, if launched not from a console (but from, say, Explorer), get a console window allocated to them at startup, even if there is no console IO.
If you want to make an UI app (for example, an alarm clock), obviously you want your users' experience to be about your UI only, and a console window popping up in the background would be quiet shocking for them.
^^ This is indeed the reason why my app has to be a windows app. The users would complain if a console window appears when the app is run (they would probably interpret that to mean something was wrong :-D ).
In console apps, you can deallocate the console I think, but even then it flashes by quickly on the screen, giving the user a feeling that something is not right.
Yes, one solution would be to use GetConsoleWindow() and hide the window immediately after calling AllocConsole() and then hide the window. But, again the users wouldn't like the flashing window any better.
"hide the window immediately after calling AllocConsole() and then hide the window."
^^ Ugh. Brought to you by the "Department of Redundancy Department".
You think you've read over a post enought times, then you reread it just after posting it and you find stuff like this!! :-D