See bellow

On Friday, March 21, 2003, at 11:11 AM, Raymond Irving wrote:


--- Benoit Marchant <[EMAIL PROTECTED]> wrote:

On Friday, March 21, 2003, at 10:19 AM, Raymond Irving wrote:


--- Doug Melvin <[EMAIL PROTECTED]>
wrote:
These are issues we will have to collaborate on.
Is it
best to add invokeEvent inside the setSize()
function?
How many apps/widgets will make use of the
onresize
events?
I do use it.
The pros and cons will have to be carefully
look at.

Having invokeEvent inside setSize will slow
down animations and layers/widgets that makes use
of
the 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
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.


If you say yes add the onresize,
then you'll have to add the onmove,etc events that
have been removed.
I guess.

DynAPI 3.0 removed the onresize and onmove events.
IMO
I don't think we need these events. I've found
other
ways 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.
Are you talking about existing code using dynapi2 and porting to dynapi3 ?

Event propagation
is very important.
Can you give a common scenario where delegates wouldn't do the trick ?


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.
Everything where ? I'm not talking about suppressing events like mouse events and so on, of course not !
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

but 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 the
view
of as many as posible.


As for onload... It was suggested the the
onCreate()
onPrecreate() functions be used to trigger
callbacks
once the object (elm) is loaded.

See previous email (if it ever arrives on the
server)

same as comment above.

--
Raymond Irving

__________________________________________________
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]/




__________________________________________________
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]/

Reply via email to