Announcement

Collapse
No announcement yet.

How to use a message pump? how to communicate between two dialogs?

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

  • Andrea Mariani
    replied
    Originally posted by Dale Yarker View Post
    https://docs.microsoft.com/en-us/win.../wm-syscommand

    %SC_CLOSE comes in wparam of %WM_SYSCOMMAND message.

    Cheers,
    Perfect.
    Thanks to both of you, it works.

    Leave a comment:


  • Dale Yarker
    replied
    Agreed! Confirming close, and hourly FLUSH #nFile saved a lot of PBX meta data.

    Leave a comment:


  • David Roberts
    replied
    I use Bob Scott's EZ-Post. For some reason, probably old age, I developed a habit of closing EZ-Post with the xPad button unselected so instead of saving a draft I lost everything that I had written and that could have been half a hours work or more. After including a %SC_CLOSE trap I have never lost anything.

    Leave a comment:


  • Dale Yarker
    replied
    https://docs.microsoft.com/en-us/win.../wm-syscommand

    %SC_CLOSE comes in wparam of %WM_SYSCOMMAND message.

    Cheers,

    Leave a comment:


  • David Roberts
    replied
    It has just dawned on me that I don't trap %WM_CLOSE but trap %SC_CLOSE; which I have been using for years. If I don't abort %SC_CLOSE, that is allow 'Function = 0', then Windows will then send a %WM_CLOSE.

    I trap %WM_CLOSE to kill a timer or save an ini file, for example.

    Sorry, Andrea.

    Thanks, Dave.
    Last edited by David Roberts; 23 Oct 2020, 11:10 PM. Reason: abort and not handle

    Leave a comment:


  • Dave Biggs
    replied
    You cannot prevent a Dialog closing once %WM_CLOSE is received. You do have the opportunity to save your work but the dialog will close in DDT.

    You can abort %WM_CLOSE for a SDK Window.

    Leave a comment:


  • David Roberts
    replied
    Originally posted by Andrea
    Question: how do you abort a %WM_CLOSE?
    From the manual:
    Callback Return Values

    Callback functions always return a long integer result. The primary purpose of this return value is to tell the PowerBASIC DDT engine and the Windows operating system whether your Callback Function has processed this particular message. If you return the value TRUE (any non-zero value), you are asserting that the message was processed and no further handling is needed. If you return the value FALSE (zero), the PowerBASIC DDT engine will manage the message for you, using the default message procedures in Windows. If you do not specify a return value in the function, PowerBASIC chooses the value FALSE (zero) for you.

    So, If lRslt = %IDNO Then Function = %True

    Leave a comment:


  • Andrea Mariani
    replied
    Question: how do you abort a %WM_CLOSE?
    Code:
    lRslt = mgsbox("Are you sure?", %MB_YESNO)
    If lRslt = %IDNO then what?

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Anne Wilson View Post
    DIALOG END CB.HNDL, 0

    does not work well in Windows 10 , there is a work around at

    https://forum.powerbasic.com/forum/u...696#post753696

    and Jose's explanation at

    https://forum.powerbasic.com/forum/u...620#post702620

    Your first link does not show a problem with DIALOG END.

    Jose's explanation is not only irrelevant to the question, , it is also incorrect. "When clicking the X button, Windows DOES NOT destroy the dialog, but sends an WM_CLOSE message". is not true. As Dale points out, it sends a %WM_SYSCOMMAND message.

    Leave a comment:


  • Michael Mattias
    replied
    Originally posted by Anne Wilson View Post
    DIALOG END CB.HNDL, 0

    does not work well in Windows 10 , there is a work around at

    https://forum.powerbasic.com/forum/u...696#post753696

    and Jose's explanation at

    https://forum.powerbasic.com/forum/u...620#post702620
    Those posts' relevant parts read..
    [from Pierre B]
    Problem is that we are not sure of what DDT is going on under the hood.
    A modal DDT dialog is suppose to end via DIALOG END.
    PostQuitMessage(0) is not supposed to be used, nor WM_QUIT.

    [from Jose:R]
    When clicking the X button, Windows DOES NOT destroy the dialog, but sends an WM_CLOSE message and leaves you to decide what to do, i.e. ignore it or destroy the dialog with DestroyWindow, and after calling DestroyWindow, WM_DESTROY will be received. Don't send PostQuitMessage in WM_CLOSE because, at this point, the dialog has not been destroyed.
    I think the bottom line is, "We don't know what DDT is doing on DIALOG END' and so at this point we cannot definitively say any "won't close" problem is being caused by "DIALOG END on WM_CLOSE"

    (Something related to mixing a DIALOG SHOW MODAL and DIALOG SHOW MODELESS on the same thread of execution?)

    MCM

    Leave a comment:


  • Dale Yarker
    replied
    DIALOG END CB.HNDL, 0

    does not work well in Windows 10 , there is a work around is at . . .
    ???Under what circumstances do you think it does not work?

    Right click on task bar icon and clicking close is not , repeat NOT, a DIALOG END thing. It is a %wm_syscommand action. That is referred to links subject.

    DIALOG END was used incorrectly here, see post 6 above.

    Also, in thread you linked to, no failing code was ever shown.

    Perhaps Windows 10 has a system menu problem. There is no PB problem apparent!

    Leave a comment:


  • Anne Wilson
    replied
    DIALOG END CB.HNDL, 0

    does not work well in Windows 10 , there is a work around at

    https://forum.powerbasic.com/forum/u...696#post753696

    and Jose's explanation at

    https://forum.powerbasic.com/forum/u...620#post702620

    Leave a comment:


  • Michael Mattias
    replied
    %WM_CLOSE is received when the Dialog is closing.

    Not necessarily.. WM_CLOSE is not a notification, it is in fact an opportunity message.

    WM_DESTROY is, I think, what you are thinking of.

    BUt back to WM_CLOSE. Thuss sayeth Microsoft:


    The WM_CLOSE message is sent as a signal that a window or an application should terminate.

    ....

    Return Value
    If an application processes this message, it should return zero.

    Remarks
    An application can prompt the user for confirmation, prior to destroying a window, by processing the WM_CLOSE message and calling the function only if the user confirms the choice.
    By default, the function calls the DestroyWindow function to destroy the window.
    As you can see, if you don't process a WM_CLOSE message, it will result in the destruction of this window...

    It is much like the "PostQuitMessage" function... which is called by the application to post a WM_QUIT message to the calling thread, which is how your message loop "lnows" to exit.

    We don't know (well, I sure don't know) what PowerBASIC uses as its default dialog procedure for DDT, but the standard processing for WM_CLOSE in the standard DefDlgProc is described here : https://docs.microsoft.com/en-us/win...considerations

    and as far as..

    In theory this is infinite recursion since DIALOG END [on WM_CLOSE processing] will trigger another %WM_CLOSE which will trigger another ....
    That the DIALOG END statement will generate a WM_CLOSE message is not documented as far as I can find; but if it does, you are 100% correct that you will put your dialog into an infinite loop by issuing DIALOG END in response to WM_CLOSE .. maybe.

    Except I don't think it does that.

    WM_CLOSE is typically sent or posted to the window when the user has taken an action meaning "end proceessing this screen" - actions like clicking a "done" button or hitting the "X" on a system menu - and the user may now take any action up to and including preempting the termination of the screen depending on the application state (e.g, "Save before exiting?" or the ubiquitous "Are you sure you want to quit?") .

    So... DIALOG END on WM_CLOSE actually makes really good sense to me... but without knowing PowerBASICs default dialog procedure I could not bet the ranch on this, and if maybe the dialog procedure should be exited after issuing a DIALOG END to avoid entering an infinite loop as you suggest.

    Disclaimer: I am not a "DDT Guy."


    MCM

    Leave a comment:


  • agustin tristan
    replied
    Thank you Stuart, sorry I didn't respond before. It is really cryptic of defective the information on this part of the PBHelp, but I can understand it is hard to explain everything to different users' levels. My regards for your help.

    Leave a comment:


  • Michael Mattias
    replied
    You don't need a message pump for the second modeless dialog. You only need one in your applicatio
    Actually, you need one message pump per GUI thread in your program. Meaniing if your program creates additional threads of execution, if an additional thread creates a window or dialog it requires its own message pump.

    I have posted a demo here but I think at this point that would be skipping ahead several chapters. For now the message (no pun intended) should be you usually only need one message pump per program.

    FWIW, the PB Win 10 doc shows under DIALOG SHOW MODELESS how to create the required message loop:

    A DIALOG SHOW MODELESS statement is usually followed by a message pump loop. For more information, please refer to the examples under DIALOG DOEVENTS.
    Well, at least the doc directs you to the right place, but is IMO deficient in not telling you you MUST create a message loop UNLESS a DIALOG SHOW MODAL statement has been used in this thread of execution.

    MCM

    Leave a comment:


  • agustin tristan
    replied
    Thank you Mike and Stuart! I am learning about the defects you've found in my code. I shall practice what you've proposed.

    Leave a comment:


  • Stuart McLachlan
    replied
    Originally posted by Mike Doty View Post
    Post #3 comments:

    The modal dialog sends a custom message within CASE %IDC_Send2 to main dialog and waits for response.
    The main dialog can optionally modify those values and return the new values to the modal dialog.

    The values do not need to be global (gstrMessage.)
    .
    Good point. If the data is gong to be acted on straight away and discarded then you just need
    '
    Code:
            CASE %wM_GetData
                pMsg = CB.WPARAM
                ?  @pMsg
                @pMsg = "Main dialog got the message" 'return a different message
    
    ...
                CASE %IDC_Send2
                    LOCAL strMsg AS STRING
                    IF CB.CTLMSG = %BN_CLICKED OR CB.CTLMSG = 1 THEN
                        CONTROL GET TEXT CB.HNDL, %IDC_txt TO gstrMessage
                        strT = "Test" 'original message
                        DIALOG SEND hDlg ,%WM_GetData,VARPTR(strMsg),0
                        ? strT   'display the changed message
                    END IF
    '
    And if you don't need a response or strng data, you don't need to use a pointer at all.
    You can use integers or numeric equates directly in WPARAM wth SELECT CASE AS LONG in %WM_GetData.

    Leave a comment:


  • Mike Doty
    replied
    Post #3 comments:

    The modal dialog sends a custom message within CASE %IDC_Send2 to main dialog and waits for response.
    The main dialog can optionally modify those values and return the new values to the modal dialog.

    The values do not need to be global (gstrMessage.)

    Very nice, Stuart.

    Leave a comment:


  • Stuart McLachlan
    replied
    Updated code in Post #3 to be more useful. it now appends entered text scrolls to the end of the text and returns focus to the man dialog

    Leave a comment:


  • Stuart McLachlan
    replied
    This is the culprit:

    Code:
         CASE %WM_CLOSE
            DIALOG END CB.HNDL
    No idea how it can be working on your 32bit Windows. It's definitely incorrect code.

    %WM_CLOSE is received when the Dialog is closing.
    In theory this is infinite recursion since DIALOG END will trigger another %WM_CLOSE which will trigger another ....
    In effect this results in sending a message to a dialog handle after the dialog has closed and the handle is no longer valid

    Just remove the whole CASE %WM_CLOSE and it works fine.

    Leave a comment:

Working...
X