A built-in subclassing mechanism

[EduardoVB]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] There is no built-in subclassing mechanism on VB6. Every developer uses a different one. Most with problems of some kind or another.

Describe the solution you'd like A clear and concise description of what you want to happen. The idea is to be able add subclassing without additional code modules or thunks and without the so many problems that it currently has, like crashing the IDE, hanging it, or having code windows disabled.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. I think that this feature needs to be thoroughly studied, because there are many things to consider.

Additional context Add any other context or screenshots about the feature request here. In plain VB6, callback procedures can be only in bas modules. That is a very limiting thing.

[WaynePhillipsEA]

Linking twinbasic/twinbasic#5 as we were talking earlier about delegates.

You're talking about subclassing forms & form controls right? I've got some ideas on that. I'll leave this open until we get on to GUI

[EduardoVB]

Any window can be subclassed, sometimes from an UserControl is is necessary to subclass the parent form.

But yes, in most of cases it will be the form and/or controls.

[dmrvb]

VB6 has a keyPreview option which intercepts all keypresses at Form level before they go to controls. Would a "messagePreview" be the way to implement subclassing so that all messages can be intercepted?

[bclothier]

The discussion about safe subclassing may be of interest. The basic problem seem to be related to the fact that VB6 in its original design tries very hard to hide the subclassing away from those who need it to the point that it's very unstable. After all, the code to enable subclassing has to be run in the IDE and if the IDE isn't aware, we get crash galore.

Hopefully, tB and its IDE can do better in this area.

[EduardoVB]

Subclassing in VB6 are all hacks. VB6 does not provide any way for subclassing. The only (little) help is the AddressOf operator.

Hopefully, tB and its IDE can do better in this area.

Yes, it can do better because VB6 does nothing.

Anyway, even when they are hacks, VB6 could do a lot more and unlock a lot of potential with those hacks. I think many of us would not be here otherwise.

Basically: messages in Windows are translated to events in VBx/tB. But not all are. For example, when a window changes size, Windows send a WM_SIZE message to an internal procedure that handles the messages. And a WM_SIZE message produces a Form_Resize event. But when a windows changes position instead of size, windows sends a WM_MOVE message. And it is translated into a Form_Move event...

• Err, wait, there is not Form_Move event. Not, that message is "ignored", it does not produce any event.

So, if you want to do something when a form is moved, what would you do? You can put a timer and check the form position every time. But that won't work always very well. So, you need the "event" that you don't have. That is what subclassing does: it is called in all the messages that you want.

I gave an example with WM_MOVE but there are many messages. Also in new Windows versions, sometimes new messages are introduced, so there cannot be an event for each one or that approach would be impractical IMO.

Why the instability? In most of cases it is because after pressing the Stop button Windows calls a procedure in a memory address that doesn't exist anymore. That could be easily "fixed" in the case that the IDE was the one that provides the subclassing mechanism by removing the subclass when the Stop button is pressed.

But now VB6 does not provide anything, so they are all hacks and you are on your own regarding subclassing. But... sometimes you need to process such messages (like WM_MOVE). Without that, VBx would be very limited.