>>  I sort of intuitively feel making it a class attribute and class method may not be ideal. 
The collection needs to be a singleton - i.e. one place I can go to to find any dialog's hwnd. This suggests either the class object or a singleton instance of something if the amount of code required is not small. If a singleton instance, then its object id would be stored in a class attribute of the View class.
 
>> 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?
Yes. The user of the framework, in creating a dialog, and having determined that it would accept drops, would do something like self~storeDlg:super. Then in the View superclass I'd have a storeDlg instance method that would get the hwnd and store self and hwnd into the singleton instance (or class collection attribute). Or maybe go straight to the super's class method using .View~storeDialog(self). I will also have to include the droppable area as a param (or even areas plural but not in V1) - e,g, self~storeDlg:super(dropArea).
 
The framework should also be able to handle either push or pull drag/drop approaches (although I haven't thought out yet how to provide for both, and plan to use only the pull approach in the Guide exercises).
 
--
Oliver Sims
 


From: Mark Miesfeld [mailto:miesfeld@gmail.com]
Sent: 11 January 2012 15:58
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] ooDialog - How soon is a dialog's hwnd available?

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