MsgQueue - OS2

This is a discussion on MsgQueue - OS2 ; I have a WinMessageBox in a VIO REXX DLL which, if possible, displays a fatal error when the size of the screen has been changed unexpectedly. When the error condition occurs the called REXX function returns REX40 in order to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: MsgQueue

  1. MsgQueue


    I have a WinMessageBox in a VIO REXX DLL which, if possible, displays a
    fatal error when the size of the screen has been changed unexpectedly.
    When the error condition occurs the called REXX function returns REX40
    in order to stop the REXX app. The DLL itself contains UI functions.

    From an earlier article of Rich Walsh: 'At shutdown, PM posts a WM_QUIT
    to each queue and won't proceed until each queue has processed it. If you
    create a msg queue that you don't plan to serve, you should call
    WinCancelShutdown( hmq, TRUE) immediately after creating the queue. This
    will prevent WM_QUIT from ever being posted to it and gumming up the
    works.

    I guess I could serve the WM_QUIT (and hopefully return to the REXX
    function, which finally returns a REX40), but how do I do that? I don't
    want to let my app stop the shutdown process. If WinCancelShutdown is
    an alternative, should I call creating the queue and the cancel in a
    CritSec ?

    TIA!



    ---

  2. Re: MsgQueue

    ML wrote:
    > I have a WinMessageBox in a VIO REXX DLL which, if possible, displays a
    > fatal error when the size of the screen has been changed unexpectedly.
    > When the error condition occurs the called REXX function returns REX40
    > in order to stop the REXX app. The DLL itself contains UI functions.
    >
    > From an earlier article of Rich Walsh: 'At shutdown, PM posts a WM_QUIT
    > to each queue and won't proceed until each queue has processed it. If you
    > create a msg queue that you don't plan to serve, you should call
    > WinCancelShutdown( hmq, TRUE) immediately after creating the queue. This
    > will prevent WM_QUIT from ever being posted to it and gumming up the
    > works.
    >
    > I guess I could serve the WM_QUIT (and hopefully return to the REXX
    > function, which finally returns a REX40), but how do I do that? I don't
    > want to let my app stop the shutdown process. If WinCancelShutdown is
    > an alternative, should I call creating the queue and the cancel in a
    > CritSec ?


    If you're falling through to WinDefWindowProc/WinDefDlgProc, I think it
    should handle this message for you.


  3. Re: MsgQueue

    On Sun, 21 Nov 2004 12:31:20 UTC, spamgate@hotmai1.com (ML) wrote:
    >
    > I have a WinMessageBox in a VIO REXX DLL which, if possible, displays a
    > fatal error when the size of the screen has been changed unexpectedly.
    > When the error condition occurs the called REXX function returns REX40
    > in order to stop the REXX app. The DLL itself contains UI functions.
    >
    > From an earlier article of Rich Walsh: 'At shutdown, PM posts a WM_QUIT
    > to each queue and won't proceed until each queue has processed it. If you
    > create a msg queue that you don't plan to serve, you should call

    ^^^^^
    Ooops, should be "service"

    > WinCancelShutdown( hmq, TRUE) immediately after creating the queue. This
    > will prevent WM_QUIT from ever being posted to it and gumming up the
    > works.
    >
    > I guess I could serve the WM_QUIT (and hopefully return to the REXX
    > function, which finally returns a REX40), but how do I do that? I don't
    > want to let my app stop the shutdown process. If WinCancelShutdown is
    > an alternative, should I call creating the queue and the cancel in a
    > CritSec ?


    I wouldn't be overly concerned. In any case, the WM_QUIT msg is probably
    posted by the shell process, so freezing your process's threads doesn't
    accomplish anything useful.

    It sounds like you only need a msg queue while you have the message box
    displayed. As such, I would expect that your code would create a queue
    when needed, display the box, then destroy the queue when WinMessageBox()
    returns. While the box is displayed, it will service your queue. The
    docs say that if the msg box retrieves a WM_QUIT, it will repost the msg
    then dismiss itself.

    AFAICT, the reason PM posts a WM_QUIT to each queue is get each thread
    to stop processing messages and destroy its queue. The (assumed)
    structure of your code accomplishes this end very nicely. In fact,
    calling WinCancelShutdown() may be counter-productive. If the msg box
    isn't dismissed automatically by WM_QUIT, your own REXX termination
    code that follows the return from WinMessageBox() may not be run.

    Try something simple like this:

    [...]
    WinInitialize()
    WinCreateMsgQueue()
    WinMessageBox()
    WinDestroyMsgQueue()
    WinTerminate()
    [...]

    then test, test, test... :-)


    --
    == == almost usable email address: rws AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | Remote Workplace Server
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws050.zip
    __________________________________________________ _________________

  4. Re: MsgQueue

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    > From an earlier article of Rich Walsh: 'At shutdown, PM posts a WM_QUIT
    > to each queue and won't proceed until each queue has processed it. If you
    > create a msg queue that you don't plan to serve, you should call
    > WinCancelShutdown( hmq, TRUE) immediately after creating the queue. This
    > will prevent WM_QUIT from ever being posted to it and gumming up the
    > works.
    >
    > I guess I could serve the WM_QUIT (and hopefully return to the REXX
    > function, which finally returns a REX40), but how do I do that?


    As others said, if you are going to service the message queue, then
    practically there is no need to do WinCancelShutdown().

    > I don't want to let my app stop the shutdown process. If
    > WinCancelShutdown is an alternative, should I call creating the
    > queue and the cancel in a CritSec ?


    Very few APIs can be safely called from inside CritSec. If you want
    to be bullet-proof with WinCancelShutdown(), the only
    possible solution I can see is

    a) create queue;
    b) call WinCancelShutdown();
    c) peek-and-serve messages which got into the queue between calls to
    (a) and (b).

    Hope this helps,
    Ilya

  5. Re: MsgQueue


    > It sounds like you only need a msg queue while you have the
    > message box displayed. As such, I would expect that your
    > code would create a queue when needed, display the box, then
    > destroy the queue when WinMessageBox() returns.


    Spot on.

    > While the box is displayed, it will service your queue. The
    > docs say that if the msg box retrieves a WM_QUIT, it will
    > repost the msg then dismiss itself.


    > then test, test, test... :-)


    The first test, test, test shows a problem. A regular shutdown
    during a 'REXXTRY PULL .' works fine. When I perform a regular
    shutdown (CAD always works fine) while my WinMessageBox() is
    displayed, the PC hangs. My copy of OS/2 doesn't speak English,
    but it looks like the REXX app receives the WM_QUIT. But then
    the CMD.EXE hangs with the title bar reading 'shutting down..'.
    If I manage to type 'EXIT', the shutdown continues. If I move
    the VIO window, it leaves a black spot (with a size like I was
    asked if it's okay to kill the running CMD.EXE too) and won't
    shutdown.

    Forget the not so important WinMessageBox()? It's not a very
    common error to occur (*), and it only looks nasty when a
    regular shutdown is performed while it's displayed.

    *=e.g. MODE 80,43, REXX DLL's InitTerm picks up 80x43, MODE 80,25
    without telling the DLL, call a DLL function which may depend
    on the right screen size



    ---

+ Reply to Thread