On Friday, March 21, 2003, at 11:11 AM, Raymond Irving wrote:
I agree, it's a little more work. But when you're a user of animations, where that would be used, it's transparent to you. It's jut an optimization.
--- Benoit Marchant <[EMAIL PROTECTED]> wrote:
On Friday, March 21, 2003, at 10:19 AM, Raymond Irving wrote:
wrote:
--- Doug Melvin <[EMAIL PROTECTED]>These are issues we will have to collaborate on.Is itbest to add invokeEvent inside the setSize()function?How many apps/widgets will make use of theonresizeevents?I do use it.The pros and cons will have to be carefully look at.
ofHaving invokeEvent inside setSize will slow down animations and layers/widgets that makes usethe anchor feature.Shouldn't the ability to pass noevent==false as an argument on all methods that send event fix that ? This means that if an animation call setSize or setLocation, it could send it with the extra argument to say don't send the event, this should fix the performance issue, right ? I have used that feature for performance optimization.
Everytime you call setSize you will have to remember to set noevt, correct? That's not effiecient in my option, as most user will not remember to set noevt as default
Are you talking about existing code using dynapi2 and porting to dynapi3 ?
I guess.If you say yes add the onresize, then you'll have to add the onmove,etc events that have been removed.IMO
DynAPI 3.0 removed the onresize and onmove events.I don't think we need these events. I've foundotherways to solve my resize issues,
Could you tell which ones ?
Well for me I just overwite/subclass a method I need additional features for.
The one I've used is by using a delegate. The delegate concept has been always present in NeXT, and Apple now Object Oriented frameworks. The idea is that one object is attached a delegate which will have the ability to change some default behaviours, react to some events. For example, a delegate could be sent : layerWillDrag(aLayer). This could give the delegate, which can be a delegate of multiple layers, to prevent a drag to start. You frequently find delegate methods like willDoSomething, and didDoSomething. This is slightly more efficient than notifications as there's only one object to message, and it's available by an instance variable. I have to say that a lot of the use I made of events could have been re implemented by a delegate. You usually don't have multiple objects observing others. For example, you usually don't have multiple objects listening for drag events of the same layers, would you agree ?
No. Many times users need to extend widgets and other apps that already use these events.
Can you give a common scenario where delegates wouldn't do the trick ?Event propagation is very important.
Everything where ? I'm not talking about suppressing events like mouse events and so on, of course not !
And if you do, than we could provide a delegate that send events. So to summarize: Introduce the concept of delegate: The events we currently send, we replace them by sending an equivallent method directly to the delegate. Now if by design you really need a notification, the delegate can send the equivallent event, and you're back to the old schema.
What do you think ?
Well, it would seems as though this approach does not support propagation. Beside, that it will break every thing.
I'm talking about some specific events like resize/move and some specialized events that might be created for special purposes where a direct interaction between 2 objects might be enough.
Does size/move events needs to propagate ?
I understand it looks scary that events might not be sent to anybody, but we could do that. We could have a setting that, per layer, send events (like now) on top of delegate methods. My point is that If the scenario where you have multiple different objects listening events on the same layer is pretty uncommon. And if that's true, than delegate can achieve the same job as events, and we can still keep events when needed.
The delegate implementation could just be a hard coded single listener. This way it doesn't change anything, and if there's no delegate, and you don't specifically say on a layer, I want you to send event, nothing would happens.
Benoit
-- Raymond Irving
Benoit-------------------------------------------------------
viewbut let's get some feedback from the other developers.
Should be sacrifice add onresize,onmove and onload back into 3.0?
We have about 7 active debvelopers, let hear theof as many as posible.live on your desktop!
server)onCreate()
As for onload... It was suggested the theonPrecreate() functions be used to triggercallbacksonce the object (elm) is loaded.
See previous email (if it ever arrives on the
same as comment above.
-- Raymond Irving
__________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness,http://platinum.yahoo.com
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031enThis SF.net email is sponsored by:Crypto Challengeis now open!Get cracking and register here for some mindboggling fun andthe chance of winning an Apple iPod:
http://www.mail-archive.com/[EMAIL PROTECTED]/_______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED]
__________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/