Windows to DOS to Windows

[Mike Doty]

If a FULL screen DOS app shells to a GUI
application and anything is displayed before
the DOS app regains control, the DOS app will
be minimized no matter how SHELL is used.
Print monitor programs will always minimize
FULL screen DOS applications if the GUI app
displays anything.

Placing a delay after using SHELL in a DOS app
shells to a Windows program will give the Windows
app time to allocate. This can eliminate lengthy
print delays without having to shell synchronously.

WINLINK is necessary if the shelled to program must
finish first.

To restore FULL screen DOS programs after being minimized
by GUI apps the solution is DOSBOX. http://www.powerbasic.com/products/dosbox http://www.perfectsync.com/DOSBox.htm


------------------

[Larry Coleman]

Lance and Semen,

Thanks.

Lance. I sent you an e-mail. Your approach seems a lot cleaner
than mine.

Thanks,

Larry

------------------
Larry Coleman
[email protected]

[Semen Matusovski]

Lance --
> Still, I stand by my research that START /W was not always 100% reliable
Can you give a sample ? (except obvious cases - GUI starts another GUI and finishes).

BTW. Returning a control to full-screen DOS without external assistance ... Impossible, agree.

[This message has been edited by Semen Matusovski (edited April 26, 2001).]

[Lance Edmonds]

Semen, I see you changed your reply significantly while I composed my response.

Still, I stand by my research that START /W was not always 100% reliable.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Lance Edmonds]

I seem to remember there was a problem when I looked into it... in some cases, START still launched GUI apps asynchronously (as a separate process).

If you tested it, did you test what happens when the DOS app is full-screen when it launches various GUI apps?

That is, does the DOS app get brought back to the foreground (restored to full-screen) after the GUI app finishes? AFAIR, this is where the problem came to light with START, and this was the exact problem that WINLINK was designed to solve.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Shell "start notepad.exe" in PB/DOS should work async.
Shell "start /w notepad.exe" - sync.

[This message has been edited by Semen Matusovski (edited April 26, 2001).]

[Lance Edmonds]

PB/DOS does not have an asynchronous SHELL function, only a synchronous SHELL statement. Unfortunately, when a Windows GUI app is shelled from a DOS app, Windows starts it as a separate process. There is no native way to force synchronous behavior of a GUI app from a DOS app.

However, I have a small utility app called WINLINK (written with PB/CC) that enables a DOS app to synchronously shell to a Windows GUI app. It launches the Windows app, and does not return until the GUI app terminates. WINLINK then restores the DOS app back to the foreground. The app is freeware, and I'll send it to you if email me privately at mailto:[email protected][email protected]</A>

Basically, you just use WINLINK as the SHELL target and pass the GUI app name to WINLINK as a command-line parameter, thus:

SHELL "WINLINK.EXE NOTEPAD.EXE filename.txt"

Dead simple. As the history goes, I developed this app for my DOSPRINT product to enable a DOS app to regain focus even if the printer driver launches a GUI "manager" window. Without WINLINK, a DOS app may not regain focus if such a popup manager launches.

Anyway, you are free to use WINLINK with your app if you so wish. Just ask.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Larry Coleman]

Steve,

I was incorrect in stating that other windows programs react differently. All Windows
programs return control immediately to the DOS calling program, This was
not obvious because in all other instances the DOS program required
input or a decision from the user. In these cases the windows programs
had adequate time to complete. Since this seems to be the normal
way windows operates (In regards to shelling from DOS to Windows) I have a
workaround.

The shelled to program requires input from the user. This is passed to the
shelling program via a small temporary file. The DOS program will
now check for the existence of the file , in a timeing loop, before continuing.
I also insure that the file does not exist prior to issuing the shell.

This seems to work fine. I'm not sure if the law of unintended consequences
will apply.

Thanks,

Larry

------------------
Larry Coleman
[email protected]

[Steve Hutchesson]

Larry,

Try either the function form of SHELL or the API function WinExec()
as both allow the called program(s) to run asynchronously rather
that synchronously.

The SHELL statement is designed to run programs sequentially which
is very useful in some instances but you require the alternative.

Regards,

[email protected]

------------------

[Larry Coleman]

Currently I am shelling to a DOS program from a Windows program.
The DOS program then shells to another Windows program. The Windows program
loads but does not execute before control is returned to the
shelling DOS program.

I am able to shell to Wordpad from DOS without this problem.

Any ideas?

Thanks

Larry

------------------
Larry Coleman
[email protected]

[This message has been edited by Larry Coleman (edited April 25, 2001).]