Results 1 to 20 of 20

Thread: How to (best) detect siting of a control?

  1. #1

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Question 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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  2. #2
    Hyperactive Member
    Join Date
    Oct 2013
    Posts
    389

    Re: How to (best) detect siting of a control?

    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 ?

  3. #3

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by stum View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  4. #4
    PowerPoster
    Join Date
    Jan 2008
    Posts
    11,074

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by 7edm View Post
    No, I want to detect at design-time........
    You sure didn't make that clear in your 1st post


    Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.

  5. #5

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by jmsrickland View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  6. #6
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: How to (best) detect siting of a control?

    Per MSDN, when InitProperties & ReadProperties events occur, the control is sited
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  7. #7
    PowerPoster
    Join Date
    Jan 2008
    Posts
    11,074

    Re: How to (best) detect siting of a control?

    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


    Anything I post is an example only and is not intended to be the only solution, the total solution nor the final solution to your request nor do I claim that it is. If you find it useful then it is entirely up to you to make whatever changes necessary you feel are adequate for your purposes.

  8. #8
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: How to (best) detect siting of a control?

    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.

  9. #9
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: How to (best) detect siting of a control?

    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
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  10. #10

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by LaVolpe View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  11. #11

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by jmsrickland View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  12. #12

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by LaVolpe View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  13. #13
    Hyperactive Member
    Join Date
    Oct 2013
    Posts
    389

    Re: How to (best) detect siting of a control?

    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

  14. #14

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by stum View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  15. #15
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: How to (best) detect siting of a control?

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

  16. #16
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by dilettante View Post
    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
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  17. #17

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by dilettante View Post
    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...
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  18. #18

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by LaVolpe View Post
    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 View Post
    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 View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  19. #19
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    19,541

    Re: How to (best) detect siting of a control?

    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
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  20. #20

    Thread Starter
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: How to (best) detect siting of a control?

    Quote Originally Posted by LaVolpe View Post
    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.
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width