How to (best) detect siting of a control?

I am working on a resizer control and one of the problems I am facing is how to detect when a control is sited on the form? One way to do this is obviously to use a timer and continusly check the UserControl.Extender.Parent.Controls.Count value for changes, but I was thinking the might be a better more effective way e.g. by subclass the form and trap a message. I'm sure how to go about with that though, if it's even possible - anyone, hard core enough?

I am already using subclassing for other things so I'm not strange to the subject, I'm not considering me an expert though.

So.. from what i understand, you're trying to detect a form_resize event to be able to resize\reposition all contained controls from within that form ?

Code:

---

Dim ctrl As Control

For Each ctrl In Form1.Controls
    MsgBox ctrl.Name
Next ctrl

---

...
what am i missing here ?

Quote:

---

Originally Posted by stum

So.. from what i understand, you're trying to detect a form_resize event to be able to resize\reposition all contained controls from within that form ?

Code:

---

Dim ctrl As Control

For Each ctrl In Form1.Controls
    MsgBox ctrl.Name
Next ctrl

---

...
what am i missing here ?

---

No, I want to detect at design-time when a control is sited (i.e. placed) on or unsited from the form, so I can add it to or remove it from a collection that stores anchor values for all resizeable controls. The resizing as such is no problem, I think, but it goes like this.

When my resizer control is added to a form, it steps through all form controls in a For Each loop reading/testing all controls to see if they qualify as "resizable". If that's the case a base configuration for its anchoring is added to a collection with the controls name as key name. The collection correspond to a properties value, which can be opened in a PropertyPage for configuration. The property value is saved in the controls property bag as a serialized JSON string, which gets deserialized on recreation of the control. The problem is the situation that after the Resizer control has been added, new controls may be added to the form and that's what I like to handle.

Right now I am working with timer to simple recheck the controls count and try to deal with it if the count changes, but, it's not very effective. You have to loop through all controls again and check against the collection and add/remove items. This will then happen even if it's e.g. a menu item etc. While this can work while I complete and refine my code, I would like to find a more efficient soloution for the final result. I don't know, but maybe its not possible. I have serached the fora and googled it but all I found was this tip about the timer although the original example was for run-time.

Quote:

---

Originally Posted by 7edm

No, I want to detect at design-time........

---

You sure didn't make that clear in your 1st post

Quote:

---

Originally Posted by jmsrickland

You sure didn't make that clear in your 1st post

---

You are correct, although I thought it was understood by "sited on the form" - but - a control can of course be dynamically sited during run-time as well. Thanks for pointing it out, will try to be clearer future wise. By the way, also now realize that detecting addition/removal of controls are not enough as basically same problem would occur if a control changed name - so to define it even cleared, what I need is to detect a change in the forms controls collection.

I imagine this code be done by trapping a Windows message, not sure which and how though. So optimally I want to trap something like WM_CONTROL_ADDED, WM_CONTROL_REMOVED or WM_CONTROL_CHANGED, get the name and update my collection.

Per MSDN, when InitProperties & ReadProperties events occur, the control is sited

Since OP wants to detect the presence/absence of controls at design time then there is no code involved so things like WM_CONTROL_ADDED, WM_CONTROL_REMOVED or WM_CONTROL_CHANGED, "....what I need is to detect a change in the forms controls collection.", etc are meaningless since your program is not running if I understand OP

Maybe you would need to create an addin for VB of some sort. Can't say as I have never looked into it nor had a need for such a thing as described in the OP.

After re-reading some of these threads, I realized my answer was incorrect. The OP isn't wanting to know when his usercontrol is sited (which is what I was interpreting), but when any control is added to a form...

At design-time, not sure this is needed? The form's controls aren't resized/positioned by the resizer control during design-time, are they? If not, the items at design-time could be cached/updated during the resizer control's WriteProperties event by looping thru the control's parent. Of course that event isn't triggered unless a property on the resizer changes. This can be forced by changing a property (i.e., PropertyChanged call) after ReadProperties event is called.

At run-time, dynamically added controls would be a challenge. Instead of running some timer to check if anything on the form that can contain controls (the form, frames, pic boxes, etc) have had controls loaded/unloaded dynamically, require user to call a resizer function you wrote, something as simple as maybe: Refresh

Quote:

---

Originally Posted by LaVolpe

Per MSDN, when InitProperties & ReadProperties events occur, the control is sited

---

As for sited, only InitProperties, but that just concerns my UserControl, it's the other controls of the form I'm after. ReadProperties fires every time an instance of the UserControl is created, except the very first which fires InitProperties.

Quote:

---

Originally Posted by jmsrickland

Since OP wants to detect the presence/absence of controls at design time then there is no code involved so things like WM_CONTROL_ADDED, WM_CONTROL_REMOVED or WM_CONTROL_CHANGED, "....what I need is to detect a change in the forms controls collection.", etc are meaningless since your program is not running if I understand OP

---

Not entirely correct, UserControl code executes both at run-time and design-time, but I wasn't clear of that either before I started to dive in to this.

Quote:

---

Originally Posted by LaVolpe

After re-reading some of these threads, I realized my answer was incorrect. The OP isn't wanting to know when his usercontrol is sited (which is what I was interpreting), but when any control is added to a form...

At design-time, not sure this is needed? The form's controls aren't resized/positioned by the resizer control during design-time, are they? If not, the items at design-time could be cached/updated during the resizer control's WriteProperties event by looping thru the control's parent. Of course that event isn't triggered unless a property on the resizer changes. This can be forced by changing a property (i.e., PropertyChanged call) after ReadProperties event is called.

At run-time, dynamically added controls would be a challenge. Instead of running some timer to check if anything on the form that can contain controls (the form, frames, pic boxes, etc) have had controls loaded/unloaded dynamically, require user to call a resizer function you wrote, something as simple as maybe: Refresh

---

Maybe I still haven't made this absolutely clear, the control is a resizer control, but this part isn't about the actual resizing but the configuration of the resizing that will take place as at run time, when the forms resize event fires. Each of the form's resizeable control has a configuration item in a collection which keeps info about anchoring etc. This information is set/changed on a property page and the challange is to keep the collection in sync with the form. So if a control is removed,added or renamed this need to be reflected in the collection. The collection is then read-only so to speak during run-time.

As I understand it, the only way this can be done is by subclassing the form and trap the proper WM_ messages, if they exists, but I don't know which they would be and exactly how to do it but as long as no one been able to prove it cannot be done I'm going to try. And thanks for your contribution by the way.

So you're building the collection during design time, and .. need the 'resizer' to do its stuff on run-time .. so if nothing needs to be done in design time other than 'reading' properties of controls and storing them on a collection, why not do exactly that, at run time ? why not iterate through the controls, at run-time collect what needs to be collected when the form\the control is initialized , at run time ?
i feel like im totally misinterpreting this thread...

Why would you go to subclassing (which, lets face it, isn't pretty) to read controls properties when you can read them straight off the form ? at run time

Quote:

---

Originally Posted by stum

So you're building the collection during design time, and .. need the 'resizer' to do its stuff on run-time .. so if nothing needs to be done in design time other than 'reading' properties of controls and storing them on a collection, why not do exactly that, at run time ? why not iterate through the controls, at run-time collect what needs to be collected when the form\the control is initialized , at run time ?
i feel like im totally misinterpreting this thread...

Why would you go to subclassing (which, lets face it, isn't pretty) to read controls properties when you can read them straight off the form ? at run time

---

I think you are missing the point, the values stored in the collection are configuration values concerning a controls anchor preferences at resizing. This is read in at a default, like anchor left and top is True, anchor Right and Bottom is False, but this information can be changed by the developer that uses the control and it can only be done at design-time. The "problem" is that controls may be added/removed or renamed after the resizer control is sited and it then need to know about this so an item can be added, removed or updated (control renamed) in the collection.

I wish to show some code but don't feel I'm quite there yet, but the item added to the collection is a class currently with 4 properties As Long (although they are boolean values) for Left, Top, Right, Bottom for how the control will be anchored, and thus resized, when the form is resized. The only way for the Resizer control to figure out when the change to the form is happening is to catch a Windows message by subclassing the form. I'm now trying to find out what message(s) I need to catch.

Sure sounds like a job for an IDE add-in to me. But perhaps I don't understand the goal.

Quote:

---

Originally Posted by dilettante

Sure sounds like a job for an IDE add-in to me. But perhaps I don't understand the goal.

---

Goal appears to always know what controls are on a form, both during design & runtime.

At design time, this can be accomplished anytime the custom property page is accessed or during WriteProperties event. At runtime, maybe user should be required to 'refresh' the resizer control anytime a control is added/removed? Or have a runtime method like AddControl or RemoveControl?

Since it appears some controls may be anchored off of other controls, I can see the issue if an 'anchored' control is removed and the resizer control not aware of it. Any controls that are discovered during runtime that are not in the 'collection', maybe should have default properties based off of the 1st anchor control?

I think forcing the resizer control to know about all controls, all the time, could be troublesome. Default actions/properties might be a better option if the user didn't make the control known to the resizer control. Just an idea

Quote:

---

Originally Posted by dilettante

Sure sounds like a job for an IDE add-in to me. But perhaps I don't understand the goal.

---

No, it's a resizer control, but maybe what I am trying to do is so outside the box that it's not possible...

Quote:

---

Originally Posted by LaVolpe

Goal appears to always know what controls are on a form, both during design & runtime.

---

Maybe it's because English isn't my native language and I explain myself poorly, but... No, only design time as for configuration. I don't really have in mind to deal with dynamically added controls as it's not something I have worked with up to now. So I assume one run-time mode fires everything will stay the same with controls. Maybe I will look at that once I have covered my own needs.

Quote:

---

Originally Posted by LaVolpe

At design time, this can be accomplished anytime the custom property page is accessed or during WriteProperties event. At runtime, maybe user should be required to 'refresh' the resizer control anytime a control is added/removed? Or have a runtime method like AddControl or RemoveControl?

Since it appears some controls may be anchored off of other controls, I can see the issue if an 'anchored' control is removed and the resizer control not aware of it. Any controls that are discovered during runtime that are not in the 'collection', maybe should have default properties based off of the 1st anchor control?

---

The only thing I plan for during run-time is resizing of controls according to the anchor information set up during design-time. Using the property page to add anchor configuration for any new doesn't cover it fully.

My aim is to have run-time only deal with resizing and don't worry about gaps it the configuration. Of course, an adoption for dynamically added controls wouldn't get away with that. But your observation about a default anchor value is correct, when a control is added to the collection it gets a default Left and Top anchor. This could probably be brought over to make a dynamic adaption working as well but I don't want that to get in the way at this point.

Quote:

---

Originally Posted by LaVolpe

I think forcing the resizer control to know about all controls, all the time, could be troublesome. Default actions/properties might be a better option if the user didn't make the control known to the resizer control. Just an idea

---

Well the default is there, but otherwise is my idea the rather opposite, that the resizer control doesn't need to know about all controls all the time, only when they are added/removed to the form or renamed. This is what I hope to achieve with subclassing, during design-time, but I'm not sure what messages to process. I figure that WM_CREATE may be sent when a control is added, and WM_DESTROY when removed, although WM_PARENTNOTIFY may be a better candidate still. Not sure what happens at a control rename but maybe it's simply a WM_DESTROY and WM_CREATE operation.

I don't have so much experience with subclassing although I have used it by applying already created concepts, like using as part of a button code taken from PSC etc. The code for the control I am working on also has it's origin at PSC. A need for a resizer control arised and I went there looking but wasn't 100% satisfied with anything I found. I found 2 projects though that separately applied different ideas that inspired me to what I'm now trying to do. What strikes me is that many coders don't seem to be aware of that a UC actually executes code also during design time or even if they do I have seen few example of anyone taking advantage of that power and that's basically what I'm trying to do.

Right now I am struggling with understanding everything the developers in the 2 PSC projects try to achieve with there code as I apply my own changes and I haven't really got to the point yet to add the subclassing, as at that point it will be much harder to debug. So my first goal is to reach a "static" completion where everything works as intended after siting the resizer and then don't change anything except for the anchor configuration.

During design time, the IDE does receive WM_CREATE and WM_DESTROY messages as part of a WM_PARENTNOTIFY message when windowed controls (those with hWnd) are added/removed from the form. If you have Spy++ installed (came with your VB6 installation CDs), you can see this occurring.

So it seems possible to subclass the parent form during design time and look for WM_PARENTNOTIFY messages. But that is not going to help when VB adds windowless controls (labels, image, lines, etc) because not that message is not sent for those. And haven't looked closely at other control-types that wouldn't trigger WM_PARENTNOTIFY messages

Quote:

---

Originally Posted by LaVolpe

During design time, the IDE does receive WM_CREATE and WM_DESTROY messages as part of a WM_PARENTNOTIFY message when windowed controls (those with hWnd) are added/removed from the form. If you have Spy++ installed (came with your VB6 installation CDs), you can see this occurring.

So it seems possible to subclass the parent form during design time and look for WM_PARENTNOTIFY messages. But that is not going to help when VB adds windowless controls (labels, image, lines, etc) because not that message is not sent for those. And haven't looked closely at other control-types that wouldn't trigger WM_PARENTNOTIFY messages

---

Ahh, good point regarding the windowless controls, didn't really think of that. Looks like I have to get back to the drawing board again... Hmm, I think I abstained from installing spy++ due to difficulties to install VB6 on W7 when I did that some years ago. I should probably look at having it installed now. Thanks for the hint.