>> 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
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).
On Wed, Jan 11, 2012 at 7:08 AM, Oliver Sims <firstname.lastname@example.org>
>> 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
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
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
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.