Stop GUI Application returning when run

DaveHope · 06-29-2009, 05:33 AM

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

zacs7 · 06-29-2009, 07:25 AM

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

adeyblue · 06-29-2009, 10:13 AM

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).

Quote:

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.

DaveHope · 06-29-2009, 11:27 AM

Quote:

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.

Quote:

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.

adeyblue · 06-29-2009, 01:56 PM

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.

DaveHope · 06-29-2009, 02:27 PM

Quote:

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!

zacs7 · 06-29-2009, 05:33 PM

> 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.

adeyblue · 06-29-2009, 08:57 PM

Quote:

> 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.

Quote:

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?

Quote:

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

06-29-2009, 05:33 AM	#1
DaveHope 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
DaveHope is offline

06-29-2009, 07:25 AM	#2
zacs7 Woof, woof! Join Date: Mar 2007 Location: Australia Posts: 3,139	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 __________________ "I.T. gets the chicky-babes" - M. Kelly bakefile \| vim
zacs7 is offline

06-29-2009, 01:56 PM	#5
adeyblue Hat seller extraordinaire Join Date: Apr 2008 Posts: 159	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. __________________ Desktop Heap Monitor for Vista/7 A solution to Visual Studio 2005/8 runtime problems Getting Kernel Thread Call Stacks
adeyblue is offline

06-29-2009, 05:33 PM	#7
zacs7 Woof, woof! Join Date: Mar 2007 Location: Australia Posts: 3,139	> 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. __________________ "I.T. gets the chicky-babes" - M. Kelly bakefile \| vim Last edited by zacs7; 06-29-2009 at 05:41 PM.
zacs7 is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Creating a Stand-Alone Application	QtApprentice	C++ Programming	4	11-03-2003 01:33 PM
Simple C++ GUI programme does'nt run from dos	Shadowhunt	C++ Programming	4	05-31-2003 05:30 AM
Run vbscript from C++ console application	dp_goose	C++ Programming	3	05-15-2003 09:00 AM
EXE Closing all instances of Internet explorer - How can it run in Win 95/98	joh	Windows Programming	2	10-29-2002 04:56 PM
Win application not very portable	swed	Windows Programming	5	10-01-2001 11:17 AM