Hello all, I have been trying to attach a behavior dynamically to a sprite with the properties of the behavior also dynamically added/changed using values from a db at runtime. I've been using setScriptList and at first am having wonderful success at attaching the behavior and setting it's properties however this being a db app, the behavior's properties to a given sprite need to change many times throughout the lifetime of the application. This is where the problem is. If I change the behavior properties with setScriptList again there is a lag in it's response, the sprite seems to hold the values of the previous state.
setscriptlist doesn't actually set the properties of your behavior, but rather it sets the values, which are recorded in the score, which will be used to instatiate the behavior, when the playback head reaches the first frame where the behavior is.
so you'd have to leave the frame, where the givem behavior is to a frame without this behavior and then return to the frame with the behavior in order to have the score create a new instance of the behavior with the new values that you set before with setscriptlist.
if you want to change the properties at runtime, you'd rather change their values directly on the instance.
normally you know the names of the properties you want to change, so you could just:
sprite(x).pMyProperty = newValue
which is not a very clean way in the sense of OOP.
better is to have a handler in the script to change the value of a given property.
at first it seems more complicated than the single line to change the value and it is a bit slower too, but believe me, as the complexity of your projects scripts grow, the more you'll understand the benefits and take advantage of this approach.
so in your behavior you'll have a handler like:
on mSetValue me, prop, newVal me[prop] = newVal end
then you can change it with:
sendSprite(x, mSetValue, #pMyProperty, newValue)
now the sendsprite call won't fail even if there is no behavior or no behavior with the handler.
in mSetValue you will be able to easyily react on future changes without touching other scripts.
so the behavior is independant and 'knows' about each change it has to do, instead of being changed from outside without 'knowing' about that...
--
||| ażex -- [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
