detecting running environment, windows

[sdetweil]

I have a gui shell for my application, using wxPerl. the actual pgm is a command shell script. I use IPC::Run3 to launch the shell and capture/pass data to the background task. all works cool, except in one case.

IPC::Run3 uses system() to invoke the child.

when the GUI application is linked as a textmode app, and the child is launched, input to the child thru the $stdin handle works as expected.

when the GUI application is linked as a GUI app, and the child is launched, a textmode window appears on top of the gui, and the $stdin data from Run3 is NOT sent to the child. (but stdout/stderr are captured).

I'd also like to resolve that textmode window that was opened, but I don't see any options to system() that might provide this kind of control..

if I don't link the UI as a gui application, then when launched from the gui windows explorer, the textmode box appears when the gui is started instead.. (just can win here)..

are there any controls available in Perl to handle these two cases?

all works great on linux.

[BrowserUk]

I have a gui shell for my application, using wxPerl... when the GUI application is linked as a textmode app

Your gui is a compiled executable?

And by "linked as a textmode application", you mean you use /SUBSYSTEM:console when building the executable?

What linker options are you using when you "linked as a GUI app"?

If you are using /SUBSYSTEM:windows, then that might start to explain your symptoms (MSVC link.exe docs):

WINDOWS Application does not require a console, probably because it creates its own windows for interaction with the user.

Note: that "Application does not require a console," means when the application is loaded, no console is allocated to it. Of itself that is probably not a problem, but it ccan also mean that processes started by that application may inherit that trait.

if I don't link the UI as a gui application, then when launched from the gui windows explorer, the textmode box appears when the gui is started instead..

Probably your best solution would be to drop IPC::Run3 (on Windows at least), and use Win32::Process to start your subprocess(es).

This has options to control the creation of consoles (CREATE_NEW_CONSOLE) and console windows (CREATE_NO_WINDOW) and background processes (DETACHED_PROCESS) etc.

It's not clear to me how you are creating your perl application as a linked executable, so this is more a list of things to investigate rather than a definitive solution.

[sdetweil]

thanks that really clear up a bunch of things.. the Subsytem attribute on the executable is set to Windows as you suspected.. and the key thing there is that this application does HAVE a stdin for Run3 to dup and use. thank you.. I probably should be able to tell if handle 0 is valid or not.

[Anonymous Monk]

IPC::Run3 uses system() to invoke the child.

Nope :)

....

try  use Win32 qw(SW_HIDE); Win32::SetChildShowWindow(SW_HIDE);

Sorry if this doesn't help you, I won't be responding further in this thread :)

[sdetweil]

don't know what your 'Nope' means
from run3.pm

 my $r = ref $cmd
         ? system { $cmd->[0] }
               is_win32
                ? map {
                   # Probably need to offer a win32 escaping
                   # option, every command may be different.
                      ( my $s = $_ ) =~ s/"/"""/g;
                      $s = qq{"$s"};
                      $s;
                      } @$cmd
                  : @$cmd
         : system $cmd;

thanks for the hide.. I don't get the child window, but also stdin doesn't work.. will look thru the rest of run3..