Announcement

Collapse
No announcement yet.

Graphic Subclassing

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

  • Graphic Subclassing

    Does subclassing two Graphic controls in the same dialog like this have any potential issues? I use it and haven't seen a problem. Sharing NewGraphicProc.is intended.

    Code:
    OldGraphicProc = SetWindowLong(hGraphicA, %GWL_WndProc, CodePtr(NewGraphicProc)) ​
    ​OldGraphicProc = SetWindowLong(hGraphicB, %GWL_WndProc, CodePtr(NewGraphicProc)) ​
    ​

    I checked and the returned value of OldGraphiProc is the same in both cases. I assume that would always be true for the same control classes.

    That would imply that once I get a value for OldGraphicProc I do not need to ask for it again in the second line of code (i.e., I could run that line of code without a return value). But just in case line 1 is not executed at all, line 2 should be written to capture the OldGraphicProc value.

    When I un-subclass, I use this:

    Code:
    SetWindowLong hGraphicA, %GWL_WNDPROC, OldGraphicProc
    SetWindowLong hGraphicB, %GWL_WNDPROC, OldGraphicProc​

  • #2
    Originally posted by Gary Beene View Post

    I checked and the returned value of OldGraphiProc is the same in both cases. I assume that would always be true for the same control classes.
    It must be if both hGraphicA and hGraphicB are handles to the same class of control

    "Calling SetWindowLong with the GWL_WNDPROC index creates a subclass of the window class used to create the window."

    Given the "used to create the window", it may be an interesting exercise to try.
    Code:
    OldGraphicProc = SetWindowLong(hGraphicA, %GWL_WndProc, CodePtr(NewGraphicProc)) ​
    ​OldGraphicProc2 = SetWindowLong(hGraphicA, %GWL_WndProc, CodePtr(NewGraphicProc2)) ​​
    Is Old GraphicProc2 equal to OldGraphProc or is it equal to CodePtr(NewGraphicProc) ?

    Comment


    • #3
      Gary,

      [Suggestion only]: Consider using these subclass functions... https://learn.microsoft.com/en-us/wi...windowsubclass

      Added later:
      When I have multiple copies of a control, such as a RichEdit, and want to enforce a common, modified behavior through subclassing, I've often used the same subclass procedure, something like this ... OldREProc = SetWindowLong(hRE_A, %GWL_WNDPROC, CodePtr(REProc)) OldREProc = SetWindowLong(hRE_B, %GWL_WNDPROC,
      Last edited by Jules Marchildon; 22 Jan 2023, 06:39 PM. Reason: I've lost my mind!

      Comment


      • #4
        Howdy, Stuart!

        OldGraphicProc and OldGraphicProc2 are the same.


        Howdy, Jules!

        Yes, I also use a shared subclass procedure when I want to ensure common behavior between like controls. It's a great way to avoid having multiple functions to synchronize.

        Comment


        • #5
          Gary,

          A word of wisdom from someone who has subclassed many controls in their time, for each control, make a separate subclass for it as they are easy to keep track of and you don't risk any cross over effects. I have in the past bundled multiple controls into a single subclass and you can get them to work but they can be a nightmare to track down any problems in, especially as you may need different code for different controls. For all of the additional complexity, you may gain a minor code size advantage but it would rarely ever effect a single 512 byte section and you gain nothing with the extra complexity.
          hutch at movsd dot com
          The MASM Forum - SLL Modules and PB Libraries

          http://www.masm32.com/board/index.php?board=69.0

          Comment


          • #6
            Howdy, Steve!

            Yes, there's no doubt that what you describe is the safer solution. The more complicated the subclass procedure, the more separate procedures make sense.

            It's one thing if my subclass procedure does nothing more than handle the mouse wheel. But add in code for a variety of of support features and separate procedures definitely become easier to troubleshoot.

            Comment


            • #7
              Originally posted by Gary Beene View Post
              It's one thing if my subclass procedure does nothing more than handle the mouse wheel. But add in code for a variety of of support features and separate procedures definitely become easier to troubleshoot.
              Not if you have a number of controls of the same class that you want to behave in the same way. In that case, duplicating subclass procedures just makes it harder to maintain for zero benefit. It's only when you want each control to act differently that there is any point in creating different procedures. Even then, if there are several common bevhaviours and only a few minor differences in behaviour then there is much to be said for the odd SELECT CASE block.

              As is so often the case, you need to decide the best approach for your specific situation rather than blindly following edicts as to how thiings should be done.




              Comment


              • #8
                There is another reason why you individually subclass each control, especially if the controls run at the same time. Windows controls are separate processes that do not interact with each other but when you make a common subclass, you risk interaction between them and unpredictable and unreliable performance. A subclass procedure is in fact very small code so it is not a code size issue, its simply whether you want reliable and maintainable code.

                The cheer squad will not help you if it goes BANG.
                hutch at movsd dot com
                The MASM Forum - SLL Modules and PB Libraries

                http://www.masm32.com/board/index.php?board=69.0

                Comment


                • #9
                  Going back to post #1
                  Code:
                  OldGraphicProc = SetWindowLong(hGraphicA, %GWL_WndProc, CodePtr(NewGraphicProc)) ​
                  ​OldGraphicProc = SetWindowLong(hGraphicB, %GWL_WndProc, CodePtr(NewGraphicProc)) ​​
                  I checked and the returned value of OldGraphiProc is the same in both cases.

                  Which rather negates any concerns about every control needing to have it's own separate procedure.
                  Until subclassed, every control of a specific class clearly shares the same procedure.

                  Comment


                  • #10


                    Feel free to live dangerously. Is the theoretical size gain worth the risk ?
                    hutch at movsd dot com
                    The MASM Forum - SLL Modules and PB Libraries

                    http://www.masm32.com/board/index.php?board=69.0

                    Comment


                    • #11
                      Windows controls are separate processes . . .
                      Not so.

                      Processes and Threads - Win32 apps | Microsoft Learn

                      Dale

                      Comment


                      • #12
                        Post #9 Mr. Hutchesson

                        Windows controls are separate processes . . .
                        Post #11 Mr. Yarker

                        Not so.​

                        Mr. Hutchesson certainly knows that. But this is another case of certain words - in this case "process" - having a specific and special meaning in the context of Windows programming.

                        There mIght be a penalty for "careless use of a word" but I believe it's an innocent oversight and not an attempt to mislead or spread disinformation.
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          . . . and not an attempt to mislead or spread disinformation.
                          Your words, not mine.
                          Dale

                          Comment


                          • #14
                            Dale,

                            Here is the test for your link and assertion.

                            1. The Microsoft link does not address what you are asserting.

                            2. A simple example solves your confusion.
                            (a) Create two (2) identical apps with a control in the client area.
                            (b) Try and directly operate the control in one (1) app from the other.
                            (c) Try and find a link in MSDN or its successor on apps running in their own memory space.
                            (d) The OS provides the control to both running applications even though both applications are running in their own memory space.

                            3. I will leave you to ponder your dilemma but absolutely do not hold your breath as we may miss out on your next profundity.
                            hutch at movsd dot com
                            The MASM Forum - SLL Modules and PB Libraries

                            http://www.masm32.com/board/index.php?board=69.0

                            Comment


                            • #15
                              A word of wisdom from someone who has subclassed many controls in their time, for each control, make a separate subclass for it as they are easy to keep track of and you don't risk any cross over effects
                              Less a "word of wisdom" than a "possibly useful suggestion?"

                              I have used the same subclass proc for multiple controls on the same or different screens successfully. And when "which" control makes a difference in the code to be executed, you can always call GetDlgCtrlId (hwnd) to get the control ID. I do this to avoid duplicate code. Of course, you need unique control IDs but I do that anyway.

                              IOW, YMMV.

                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment

                              Working...
                              X