WINLIB2B Close buttons don't work.

Discussions related to mouse, keyboard and Graphical User Interface
User avatar
hellomike
Posts: 55
Joined: Sat 09 Jun 2018, 09:47

Re: WINLIB2B Close buttons don't work.

Post by hellomike » Sat 29 Jun 2019, 08:32

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

User avatar
hellomike
Posts: 55
Joined: Sat 09 Jun 2018, 09:47

Re: WINLIB2B Close buttons don't work.

Post by hellomike » Sat 29 Jun 2019, 20:21

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
Posts: 144
Joined: Mon 02 Apr 2018, 21:51

Re: WINLIB2B Close buttons don't work.

Post by p_m21987 » Mon 01 Jul 2019, 00:58

Hello,

Richard says:

-----------------------------------------------------------------------------
Zaphod wrote:
Thu 27 Jun 2019, 23:03
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.

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

User avatar
hellomike
Posts: 55
Joined: Sat 09 Jun 2018, 09:47

Re: WINLIB2B Close buttons don't work.

Post by hellomike » Mon 01 Jul 2019, 07:47

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. :cry:
Then again, there might be an API that returns parent handle....

Thanks Richard

Edja
Posts: 21
Joined: Tue 03 Apr 2018, 12:07

Re: WINLIB2B Close buttons don't work.

Post by Edja » Mon 01 Jul 2019, 09:50

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
Posts: 78
Joined: Sat 23 Jun 2018, 15:51

Re: WINLIB2B Close buttons don't work.

Post by Zaphod » Fri 05 Jul 2019, 18:39

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

User avatar
hellomike
Posts: 55
Joined: Sat 09 Jun 2018, 09:47

Re: WINLIB2B Close buttons don't work.

Post by hellomike » Sun 07 Jul 2019, 09:33

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

Post Reply