Graphic Subclassing

[Gary Beene]

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.

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:

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

[Stuart McLachlan]

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.

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) ?

[Jules Marchildon]

Gary,

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

Added later:

https://forum.powerbasic.com/forum/user-to-user-discussions/powerbasic-for-windows/778009-shared-subclass-procedure

[Gary Beene]

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.

[Steve Hutchesson]

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.

[Gary Beene]

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.

[Stuart McLachlan]

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.

[Steve Hutchesson]

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.

[Stuart McLachlan]

Going back to post #1

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.

[Steve Hutchesson]

Feel free to live dangerously. Is the theoretical size gain worth the risk ?

[Dale Yarker]

Windows controls are separate processes . . .

Not so.

Processes and Threads - Win32 apps | Microsoft Learn

[Michael Mattias]

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.

[Dale Yarker]

. . . and not an attempt to mislead or spread disinformation.

Your words, not mine.

[Steve Hutchesson]

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.

[Michael Mattias]

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.