Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn
From: "Ivo Beltchev" ivo _ on 21 Nov 2007 11:30
If AttachConsole does what you want and the only problem is that the batch file doesn't block, you can use the start /wait command. Note that AttachConsole works only on Windows XP and up.

"Martin Irman" <imartin(a)inro.ca> wrote in message news:%23vmv4H6KIHA.4584(a)TK2MSFTNGP03.phx.gbl...
> Pops wrote:
> > Martin Irman wrote:
> >
> >> Actually, you can always see the console window appearing for a short
> >> moment. That's okay. The problem is that the first time after login
> >> the console window stays ... indefinitely.
> >
> > Ok, I wondered if this was your main issue. :-) Old Problem dating back
> > to Windows 95 which many solutions depending on our OS including one of
> > the strangest recommendations from Microsoft ever. :-) More below.
>
> Oups! Sorry, I think I've misled you! I shouldn't have said
> "indefinitely" ... the console window IS closed when our application
> exits but it remains open for the whole time our application is
> running. This is what we are doing:
>
> + if our application is called from the shell with a special
> command line option (let's say 'app.exe --command-line') the
> application has to operate as a console application with no GUI to
> support legacy use in batch files.
> + if our application is started, let's say, using a shortcut on the
> desktop, the application starts in a different mode - GUI mode - and
> does not send any output to the console. In this case, explorer.exe
> (which manages the desktop, if I'm not mistaken) creates a console
> window for our application (because the app is flaged as a console
> application to support use case #1). We don't want this console
> window to be displayed because we don't send any output to it and
> more importantly, clicking on the 'X' button of the console window
> would instantly and relentlessly kill our application. Thus, we hide
> the window while our app is running. And this 'hiding' part does not
> seem to work on Windows Vista the first time after login.
>
> The problem seems to be caused by the fact that the console window is
> shown asynchronously by the OS (Vista) as I've already mentioned in my
> previous e-mail to Remy. I thought that I could solve the problem by
> flagging the application as a GUI application and using
> AttachConsole() to reconnect to the console in the command line mode
> ... but this would not work because then a call such as 'app.exe
> --command-line', if used in a batch file, would not be blocking.
>
> Thanks for the help.
> Martin.
>
From: Martin Irman on 21 Nov 2007 11:59
Pops wrote:
> If no switches is provided, then WCNODE.EXE spawns WCNODEW.EXE which is
> the GUI version of the Node Manager, and silently exits.

Yep, this is a good solution but we decided to go with only one
executable long time ago ... so I was stuck with that ... and had to
implement a rather ugly workaround.

Martin.
From: Martin Irman on 21 Nov 2007 12:12
Ivo Beltchev wrote:
> If AttachConsole does what you want and the only problem is that the batch file doesn't block, you can use the start /wait command.

Yep, that works ... but another problem is with input/output
redirections. I've implemented a workaround for my original problem now.

> Note that AttachConsole works only on Windows XP and up.

Thanks. I didn't notice. Yes, that would be a problem.
Martin.
From: Martin Irman on 21 Nov 2007 12:17
Remy Lebeau wrote:
> "Martin Irman" <imartin(a)inro.ca> wrote in message
> news:u7ZLpa5KIHA.5360(a)TK2MSFTNGP03.phx.gbl...
>
>> our app has to work as a GUI application (while hiding the console)
>> but also in a legacy command line mode.
>
> At startup, once the app has determined that it needs to run in GUI mode, it
> can use CreateProcess() to start a second copy of itself, specifying SW_HIDE
> in the dwShowWindow member of the the STARTUPINFO structure, and then the
> first instance can exit immediately without doing anything else.

Interesting idea. That could work. I've already implemented another
workaround (I wait for the OS to show the console window before hiding
it), so I'll stick with that for now.

Thanks,
Martin.
From: Pops on 21 Nov 2007 12:40
Martin Irman wrote:
> Ivo Beltchev wrote:
>
>> Note that AttachConsole works only on Windows XP and up.
>
> Thanks. I didn't notice. Yes, that would be a problem.

hmmmm, I don't recall that OS limitation. I know for sure it worked
because our products started on WIN95/NT 4.0 systems.

Let me check something ....

ok, VS6.0 MSDN APRIL 2001 requires Windows NT 3.1 and Window 95/98/ME.
We know this is true.

But the current Microsoft MSDN web site says:

Requires Windows Vista, Windows XP, or Windows 2000 Professional.

Of course, we should not be surprise because Microsoft no longer has any
interest in promoting the ideas that Windows 95 or NT 4.0 is still
supported. Also note it also lacks saying Windows 2003 :-)

But if 95/NT/2000 is still a OS you support, AllocConsole will work.

--
HLS
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn