Announcement

Collapse
No announcement yet.

Windows to DOS to Windows

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Doty
    replied
    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


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

    Leave a comment:


  • Larry Coleman
    replied
    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]

    Leave a comment:


  • Semen Matusovski
    replied
    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).]

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Lance Edmonds
    replied
    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>

    Leave a comment:


  • Semen Matusovski
    replied
    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).]

    Leave a comment:


  • Lance Edmonds
    replied
    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:
    Code:
    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>

    Leave a comment:


  • Larry Coleman
    replied
    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]

    Leave a comment:


  • Steve Hutchesson
    replied
    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]

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

    Leave a comment:


  • Larry Coleman
    started a topic Windows to DOS to Windows

    Windows to DOS to Windows

    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).]
Working...
X