Stop GUI Application returning when run

This is a discussion on Stop GUI Application returning when run within the Windows Programming forums, part of the Platform Specific Boards category; Hi All, I have a GUI windows application that has some command line ( non-UI options ). When the application ...

  1. #1
    Registered User
    Join Date
    Dec 2003
    Posts
    68

    Stop GUI Application returning when run

    Hi All,

    I have a GUI windows application that has some command line ( non-UI options ).

    When the application is run from the command line, it detatches from the cmd process and still runs. For example, if I run

    c:\> App.exe /quiet /testparam:1

    I get a cmd prompt back striaght away. Whereas if I have a console app it obviously runs until int main() returns.

    I was hoping that by not returning DialogProc() to WinMain when params are passed I'd essentially have a console app, but that doesn't seem to be the case. I'm currently doing

    Code:
    int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
    {
        hInst = hInstance;
    
    	/*
    	 * Tokenize lpCmdLine (command line options)
    	 * and deal with various options.
    	 */
    	char *token;
    	token = strtok( lpCmdLine , " ");
    	bool bQuietMode = false;
    
    	/* Loop through tokenized lpCmdLine */
    	while ( token )
    	{
    		/* token is the commandline option */
    		if ( strcmp(token , "/csv") == 0 )
    		{
    			bQuietMode = true;
    			outputCSV();
    		}
    		token = strtok( NULL , " ");
    	}
    
    	/* If we've specified some cmd line options, don't show the GUI. */
    	if (!bQuietMode)
    	{
    		// The user interface is a modal dialog box
    		return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, DialogProc);
    	}
    	else
    	{
    		return ERROR_SUCCESS;
    	}
    }
    The above code works, but returns straight away whilst the program still executes. How can I prevent it returning until execution is complete if it's in "Quiet Mode" ?

    Thanks

    Dave

  2. #2
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    You still should be checking for events whether or not you spawned the dialog. See Tutorial: Understanding the Message Loop
    and/or http://en.wikipedia.org/wiki/Message...rosoft_Windows

  3. #3
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Unless outputCSV() spawns a thread I don't see why you'd want it to stall, as your program has finished doing it's work. That assumes what you posted is the entirety of your WinMain. Given those two conditions, you'll need to wait for it to the spawned thread to finish before exiting your app (WaitForSingleObject or whatever joining capability your thread api exposes).

    You still should be checking for events whether or not you spawned the dialog.
    DialogBox implements it own message loop, adding another one would be redundant if no other windows are created.

  4. #4
    Registered User
    Join Date
    Dec 2003
    Posts
    68
    Quote Originally Posted by adeyblue View Post
    Unless outputCSV() spawns a thread I don't see why you'd want it to stall, as your program has finished doing it's work. That assumes what you posted is the entirety of your WinMain. Given those two conditions, you'll need to wait for it to the spawned thread to finish before exiting your app (WaitForSingleObject or whatever joining capability your thread api exposes).
    outPutCSV() doesn't spawn a thread, It extracts some RCDATA, accesses the registry, saves to a CSV file and that's it.

    I'm not sure if I've managed to get my point across. Consider the following:

    From a cmd prompt, I run calc. The calc.exe process runs, and I can interact with it. Yet, the command prompt has returned. If calc.exe were a console app, the prompt would not be usable until main() from calc.exe returns.

    I want to achieve console app behavior with my Windows app, but only when command line params are passed.

    Quote Originally Posted by adeyblue View Post
    DialogBox implements it own message loop, adding another one would be redundant if no other windows are created.
    No other windows are created.

  5. #5
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    In that case, no you can't really do that. The page linked to in that article describes 2 workarounds, but both require two binaries.

    cmd.exe waits for child processes to exit if they require a console, since it and the child use the same console. It doesn't wait for GUI processes since they implicitly have no need to use its' console.

  6. #6
    Registered User
    Join Date
    Dec 2003
    Posts
    68
    Quote Originally Posted by adeyblue View Post
    In that case, no you can't really do that. The page linked to in that article describes 2 workarounds, but both require two binaries.

    cmd.exe waits for child processes to exit if they require a console, since it and the child use the same console. It doesn't wait for GUI processes since they implicitly have no need to use its' console.
    Thanks for the link. I'll admit, I had no idea you couldn't (easily) achieve this with windows.

    Thanks to the both of you for taking the time to respond to my question!

  7. #7
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    > DialogBox implements it own message loop, adding another one would be redundant if no other windows are created.
    I know that... that's the point.

    And no it is not redundant if you ignore various messages, and only catch WM_QUIT.

    Remember you still have stdin, stdout and stderr all valid, just Windows won't "swawn" a console for you.
    Last edited by zacs7; 06-29-2009 at 05:41 PM.

  8. #8
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    > DialogBox implements it own message loop, adding another one would be redundant if no other windows are created.
    I know that... that's the point.
    I don't follow. You assert it needs a message loop to check for events whether the dialog is created or not, I say DialogBox provides one for the dialog and a normal one is unnecessary, and that's the point of needing a normal loop?

    A message loop in this app given DaveHope's info (no other threads, no windows) will just stall it.

    And no it is not redundant if you ignore various messages, and only catch WM_QUIT.
    Without creating a window, the app now needs a second thread just to be able to post the exit message. At which point, why not just do the work in the main thread and exit normally?

    Remember you still have stdin, stdout and stderr all valid, just Windows won't "swawn" a console for you.
    At least that's something we can agree on

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Creating a Stand-Alone Application
    By QtApprentice in forum C++ Programming
    Replies: 4
    Last Post: 11-03-2003, 12:33 PM
  2. Simple C++ GUI programme does'nt run from dos
    By Shadowhunt in forum C++ Programming
    Replies: 4
    Last Post: 05-31-2003, 05:30 AM
  3. Run vbscript from C++ console application
    By dp_goose in forum C++ Programming
    Replies: 3
    Last Post: 05-15-2003, 09:00 AM
  4. Replies: 2
    Last Post: 10-29-2002, 03:56 PM
  5. Win application not very portable
    By swed in forum Windows Programming
    Replies: 5
    Last Post: 10-01-2001, 11:17 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21