Announcement

Collapse
No announcement yet.

Windows to DOS to Windows

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

  • 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).]
    Larry Coleman
    Savannah, Ga USA

  • #2
    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]

    ------------------
    hutch at movsd dot com
    The MASM Forum

    www.masm32.com

    Comment


    • #3
      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]
      Larry Coleman
      Savannah, Ga USA

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment


        • #5
          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).]

          Comment


          • #6
            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>
            Lance
            mailto:[email protected]

            Comment


            • #7
              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
              mailto:[email protected]

              Comment


              • #8
                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).]

                Comment


                • #9
                  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]
                  Larry Coleman
                  Savannah, Ga USA

                  Comment


                  • #10
                    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


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

                    Comment

                    Working...
                    X