Windows gui with console



  • I want to make a gui program for Windows where the same executable works from the command line. If the program is run from the command line, it should show output in the same command line window. If it is run by double clicking it in Explorer, it should not display a cmd.exe window.

    I can't get both things to work on Windows. I can get it to work on Linux easily without any extra flags on the compiler, but on Windows, I apparently have to choose between having console output and having a huge black box show up when someone opens my program.


  • SockDev

    yep! don't you love the design choice windows made for that?

    nothing you can do about that without using multiple executables....




  • kills Dumbledore

    Can't you add command line flags to either the shortcut or when you call it from the command line? Or just use it in a GUI like god intended


  • SockDev

    @jaloopa said:

    Can't you add command line flags to either the shortcut or when you call it from the command line? Or just use it in a GUI like @blakeyrat tended

    FTFY


  • kills Dumbledore

    And @blakeyrat said let there be a usable interface, and lo the GUI appeared ands @blakeyrat saw that it was good


  • I survived the hour long Uno hand

    I had to QA a program like that. Their solution ended up having a splash screen appear from the command-line app. They didn't like that I found that unacceptable.



  • I think my solution is just going to be "windows users don't get command line output"



  • /SUBSYSTEM:CONSOLE, FreeConsole() in your entry point and hope nobody notices the flashing console window.





  • Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?


  • Discourse touched me in a no-no place

    Using my psychic powers, you're printing diagnostics.
    Open a window with a textarea in it. Print to it. Profit.

    Seriously, fuck standard console windows on Windows anyway. Can't even select/copy/paste without jumping through hoops.



  • @ben_lubar said:

    Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?"

    Try it in Mac Classic.

    When Windows was introduced, it was assumed that GUIs would completely replace CLIs and therefore there is no need for something like this. Oh, and... hey look, they were fucking right. It's only people who love the 1980s and their brainwashed progeny who worry about this shit.

    BTW, how does this work in Unixes? Do GUI applications just get a console they never use and never shows on the screen? Isn't that a stupid performance drain for no benefit? (Trivial now, of course, but back in 1993 when this was all designed...) Seems like Microsoft did the right thing here.


  • kills Dumbledore

    @ben_lubar said:

    Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?

    I reckon you could replace Windows with any other OS there, since they're, you know, different operating systems.

    In fact, I bet there are more than a few situations where it's between different Linux distros



  • AttachConsole(ATTACH_PARENT_PROCESS);
    	if (GetConsoleWindow() != NULL)
    	{
    		std::cout << "Test!\n";
    		std::cout << "This is a test\n";
    	}
    	else
    	{
                //do your graphics stuff here...
    

    The caveat: while you're attached to the parent process console, cmd is not detached from it. It behaves kinda odd, it's probably fixable, but I know as much about WinAPI as about MUMPS.



  • @ben_lubar said:

    Why does it seem that the answer to "how do I do some hacky cludge on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?

    FTFY



  • @blakeyrat said:

    BTW, how does this work in Unixes? Do GUI applications just get a console they never use and never shows on the screen?

    Bzzt! Wrong!

    The 'am I bound to a console or not?' question is not answered by the app itself in *nix land, it's answered by what its parent bound stdin/stdout/stderr to. When you start an app from a terminal in *nix (even if it's a GUI/X11 app), the app inherits stdin/stdout/stderr from the shell. When a X11 app is started through the GUI, though, stdin/stdout/stderr are simply pointed at /dev/null. So, there's no actual unused console floating around, just some standard handles that point at nowhere.

    Also, Windows console support sucks in that it takes a zillion and two hoops to emulate anything close to a proper pseudo-terminal (pty). I'd rather wire my standard handles (or at least stdout/stderr) up to a pipe whose other end is connected to my logging TextArea, TYVM!



  • @tarunik said:

    When a X11 app is started through the GUI, though, stdin/stdout/stderr are simply pointed at /dev/null.

    The GUI apps on the computer I’m currently using have stdout and stderr redirected to some pseudo-terminal (/dev/pts/15). I guess it’s managed by Upstart and the output ends up somewhere, but i’m not really sure...

    In any case, the Windows behavior makes sense to me. A GUI app should not mess up with the console at all. Detaching them right away is probably the best thing to do.



  • @VinDuv said:

    In any case, the Windows behavior makes sense to me. A GUI app should not mess up with the console at all. Detaching them right away is probably the best thing to do.
    I feel like this begs the question (in the strict sense people are always yammering on about!). Why does the phrase "a GUI app" even make sense in the first place?

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something? Or, like import, doesn't exactly have a GUI but still interacts with X programs?



  • @EvanED said:

    I feel like this begs the question (in the strict sense people are always yammering on about!). Why does the phrase "a GUI app" even make sense in the first place?

    • A GUI app interacts with the user using a windows, buttons, etc
    • A console app interacts with the user by doing I/O on a console

    I think it’s better to keep those separate because they don’t mix up well.

    @EvanED said:

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something?

    That doesn’t sounds like a good idea...

    @EvanED said:

    Or, like import, doesn't exactly have a GUI but still interacts with X programs?

    I don’t classify that as a GUI program.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.