WINLIB2B Close buttons don't work.

[hellomike]

Thanks for the offer.

In the forum historie I indeed saw that you have dealt with the library before. Clearly you have better figured out how the library works, i.e. how Richard incorporates the dialog box procedure in it.

Ideally I would like to have a wrapper function "FNappNewDialog(title$,x%,y%,cx%,cy%,font%,size%)" which calls "FN_newdialog(title$,x%,y%,cx%,cy%,font%,size%)" but before returning patches the generated dialog procedure.

I.e. something like:

Code: Select all

      DEF FNappNewDialog(title$,x%,y%,cx%,cy%,font%,size%)
      LOCAL dlg%, P%
      dlg%=FN_newdialog(title$,x%,y%,cx%,cy%,font%,size%)
      P%=(dlg%!4) - 22 : REM ????
      [ OPT 10
      NOP : NOP : NOP ; ????
      ]
      =dlg%

This way I don't have to rely on a modified library for some programs and the original for others.

Would something like the above viable? If your modification helps me to understand the library code/design better I'm definitely interested.

Mike

[hellomike]

Hi,

Latest situation is that the following seems to work........

Code: Select all

          CASE id% OF
            WHEN ID_CANCEL
              SYS "GetCursorPos", Point{}
              SYS "WindowFromPoint", Point.x%, Point.y% TO D%
              IF D%=@hwnd% THEN
                Ready%=TRUE
              ELSE
                PROCappAddCol(95)
                PROCappCDSet(95)
                PROCappCDWidths(95)
                PROCappCellDetails(95, -1)
                PROCappLists(95)
                PROCappNewCDs(95)
                PROCappOptions(95)
                PROCappOperations(95)
                PROCappSearchAlbum(95)
              ENDIF
            WHEN ......
            ENDCASE

So if handle isn't @hwnd%, I give every dedicated PROC a change to match its PRIVATE !dlg% with D% and act accordingly. For the time being no need to use a patched WINLIB2B or to patch it myself.

Mike

[p_m21987]

Hello,

Richard says:

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

So far as I can see, when you click on the close box of a dialog the @lparam% that is returned by ON SYS is "0", so that suggestion does not appear to work.

It definitely does work in Windows 10. Have you definitely got a Cancel button (i.e. a button with an ID of 2) in your dialogue box? If you haven't got such a button then @lparam% will indeed be zero, but that's not the situation I described. If you don't want to have a visible Cancel button you can obviously have an invisible one (e.g. outside the bounds of the parent dialogue box) and still use the @lparam% test successfully.

Can I take this opportunity to express my extreme frustration that I am unable to reply for myself, but have to rely on the kindness of a third party to relay my messages. I would request that either we take this discussion to a forum that I can post to (e.g. StarDot) or that I be allowed to return to being a member of this forum on my own behalf. I realise that the likelihood of the latter is very small.

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

[hellomike]

Wow. Richard is, of course, correct. Only when there is a button on the dialog box with a IDCANCEL id, @lparam% contains a handle when WM_COMMAND with id IDCANCEL is received. When there is no button with IDCANCEL, @lparam% contains 0 when clicking close button.

Either clicking on the close button or the Cancel button, @lparam% has the same handle so you cannot distinguish between them. That is no problem though.

Unfortunately, the handle that @lparam% holds is the handle of the Cancel button, NOT the handle of the dialog box that the Cancel button and close button belong to.
Then again, there might be an API that returns parent handle....

Thanks Richard

[Edja]

I would request that ............... I be allowed to return to being a member of this forum on my own behalf.

Yes, please do !!!
Edja

[Zaphod]

Unfortunately, the handle that @lparam% holds is the handle of the Cancel button, NOT the handle of the dialog box that the Cancel button and close button belong to.

It is interesting how the close button on the title bar works. It simply forwards a button click event with an ID of 2 for the Windows dialog handler to deal with. That then looks at the information it registered when the dialog was created and returns the handle of the control with an ID of 2 in the lparam%. So in the case that I described in the earlier code example where there were no controls at all in the dialog it returned a zero.
But the Windows dialog handler does not know anything about the control type with ID 2 if it finds one. The expectation is that this will be the user supplied close button but this isn't actually a requirement. This means that if you do want to do something similar to Mike and you already have a control that does not generate click events you could give that an ID of 2. A static control would be ideal and very likely to exist already in the dialog. It does not have to be an additional button in that case and a static control would suffice since all you are after is the handle of any control on that dialog.
Then you get your handle from @lparam% and use SYS "Get Parent" to get the dialog handle so you can identify and manipulate the related dialog.
Here is the modification to the earlier code.

Code: Select all

      INSTALL @lib$+"WINLIB2B"
      :
      dlg%= FN_newdialog("First",50,50,100,100,8,200)
      PROC_static(dlg%,"",2,55,55,20,20,0)
      PROC_showdialog(dlg%)

      dlg1%=FN_newdialog("Second",250,50,100,100,8,200)
      PROC_static(dlg1%,"",2,55,55,20,20,0)
      PROC_showdialog(dlg1%)

      dlg2%=FN_newdialog("Third",450,50,100,100,8,200)
      PROC_static(dlg2%,"",2,55,55,20,20,0)
      PROC_showdialog(dlg2%)
      :
      DIM Q%(2)
      ON SYS Q%()=@msg%, @wparam% AND &FFFF, @lparam% : RETURN

      DIM Point{x%,y%}
      REM ========================== MAIN LOOP =============================

      REPEAT
        IF Q%(1) = 2 THEN
          SYS "GetParent", Q%(2) TO Q%(2)
          CASE TRUE OF
            WHEN Q%(2)=!dlg%: PROC_closedialog(dlg%)
            WHEN Q%(2)=!dlg1%: PROC_closedialog(dlg1%)
            WHEN Q%(2)=!dlg2%: PROC_closedialog(dlg2%)
          ENDCASE
          PRINT Q%(0), Q%(1), Q%(2)
        ENDIF
        Q%()=0
        WAIT 10
      UNTIL FALSE

      END

I would point out that this is not a recommendation but just pointing out what is possible and safe, if somewhat unconventional.
EDIT: And before someone else points it out the Static control can't have the SS_NOTIFY style or it would also close the dialog when clicked on.

Z

[hellomike]

Yes indeed. I'm using SYS "GetParent" now, storing the handle in global variable D% and then giving each dedicated dialog PROC a chance to match.
Without Richards help I wouldn't have know though that a button with IDCANCEL id HAS to exist in order to get a handle back in @lparam%. It probably is in the Microsoft docs somewhere but I didn't come across it.

Unfortunately the Windows complexity with callbacks routines and queues and threads and modal/modeless dialogs and windows and notifications and handles and device contexts and messages etc consumes by far the most time of developing a (GUI) program.

This forum with all the helpful people is great!

Mike