On Wed, Jan 11, 2012 at 7:08 AM, Oliver Sims <oliver.sims@simsassociates.co.uk> wrote:
>> If you store it in a class attribute of a superclass and you have more than 1 subclass object instantiated, then you will have problems ...
 
I plan tthe attribute to be a collection of some sort. Each entry will have the a hwnd and its corresponding dialog id.
So on each onMove message I get, I ask the View class whether I'm over an ooDialog window. In the View's class method, I'll do a mapWindowPoints on each hwnd. I return either null (no hit) or the dlg id.
 
Or something along those lines. My thinking is that since I cannot foresee (in apps similar to the Guide exercise) how many dialogs will be surfaced, the question arises, what should know about dlg ids and corresponding hwnds? The answer popped out - the View class. 
 
Does this make sense? I think the approach should be generalisable to handle situations like your dragNdrop example - except instead of hwnds it would be controls.
 
 
It makes some sense.  Although I'm by no means proficient at designing classes, I sort of intuitively feel making it a class attribute and class method may not be ideal.  But I have no reason for that which I can state clearly.  Why isn't it an instance method and attribute of the View class?
 
Do you think there'll be any performance problems? If yes or maybe, do you happen to know if any collection type is faster than others on a "lookup"?
 
The answer to "any performance problems" is the standard one, code it and see.  Or, don't worry about performance until you actually see a problem. 
 
I'm assuming the user of the drag and drop framework is only going to put the window handles of things he is interested in, into the collection?  If you are thinking of just blindly putting in the window handles of all dialogs and all dialog controls, then you could have performance problems with large dialogs.  But it won't have anything to do with the look up in the collection, it will have to do with trying to map window points a lot of times in an event handler.  Mouse move messages come very fast and very often when the user is moving the mouse.
 
--
Mark Miesfeld