Thread: 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

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.

Originally Posted by adeyblue

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.

Originally Posted by adeyblue

DialogBox implements it own message loop, adding another one would be redundant if no other windows are created.

No other windows are created.

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.

Originally Posted by adeyblue

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!

> 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