Hi Jakob
>Mark made great explanation of an OOP structure.
>However, reading it only makes me nod, it doesn't make me
shake my
>head, or feel dizzy, and that was sort of my expectation,
from all
>the fuzz.
Darn.. you mean I didn't totally put you to sleep.. drats..
I'll have to try harder the next time.
>Maybe there's an important mental difference in calling a
method
>"handle" something, rather than "set", but it boils down to
the same,
>if you tell the movie to go to 60%, it does so, or it's not
a
>reliable object.
>You have effectively "set" a state in the other object, and
you did
>so, by supplying flat data.
The name of the handler doesn't make a darn bit of
difference, I'd probably use set myself.. guess I had handle
on my mind.. too much using the MU xtra where you have to
deal with or handle incoming messages.
The crux of the issue is that the message being sent in
could do any number of things, including setting private
data structures and performing other functions but the
outside world need not know what it does internally and
shouldn't care.
On the issue of the QTObject, I truely believe that any
object that directly controls a sprite should take complete
and full control of that sprite and that the sprite
essentially becomes one with the object with the sprite's
properties becoming private to that object (or behaviour).
Therefore any other object that needs to change a property
of that sprite should route the message to the object
controlling that sprite and have it adjust the appropriate
property(s) in accordance to the message type. Therefore a
stop button should not attempt to directly stop the QTMovie
but rather send a message to the object controlling the QT
to tell it the stop button has been pressed. Again it makes
for much easier debugging.
On the topic of who controls what objects and where that
"control object" should reside is somewhat debateable. It
could be a very specific controller that fits only a custom
need, or it could be more "generic" providing the
infrastructure to facilitate communication between any set
of objects. The "generic" form would be my choice at the
moment making it more reuseable. In a case where the objects
are behaviours then it would make some sense that the
"control object" be attached as a property of any of the
major pieces, since the one piece that tends to require the
most messaging is the QT object I would most likely add the
"control object" as a property of that object or as a
seperate behaviour attached to the QT sprite. On the flip
side, if all of this was to be somewhat dynamic, then I'd
probably attach the "control object" as a property to a
static member of the screen that does not change for the
duration of the required viewing of the qt piece, read the
neccessary information from one of Irv Kalb's data members
as a property list passing in the name of the parent script
as a parameter when creating the control object.
Depending on whether one wants to set up direct
communication between the objects or have all communication
channeled through the controller via a single handler.
Eg.. assuming we are using at least D8 or D8.5 (only tested
in D8.5), I would set up the list of control objects as
such:
[ #QTObject: someRefToQTObject, #StopButton:
someRefToStopButton, #PlayButton: someRefToPlayButon ]
Therefore to pass a message to an specific object you could
call a generic handler:
on mRelayMessageToObject me, l_Sym_ObjectName,
l_Sym_HandlerName, l_List_Parameters
if ilk( p_ObjRefs_List[ l_Sym_ObjectName ], #Object ) then
return( call( l_Sym_HandlerName, p_ObjRefs_List[
l_Sym_ObjectName ], l_List_Parameters ) )
else
return( ) -- could be any error code that is unique to say
object not found
end if
end mRelayMessageToObject
if the message had to go to all objects then it would simply
require a seperate messaging handler that would relay a
single message to all objects in the object list.
If on the flipside the control object was a property of
another behaviour and we are dealing with a series of
behaviours that we are attempting to bring under control a
series of behaviours then the object's symbolic name would
be a property that could be set by the
getPropertyDescriptionList and a broadcast message from the
control object with an empty property list would allow each
object of the "group" to add themselves using setaProp with
the name and object reference, and a reference to the
control object, then again all messaging could pass through
the controller if so desired.
Obviously there would be a slight performance reduction
without using direct communication but in our case that
might be minimal (except perhaps between the thumb of the
slider and the qtobject - where performance might need to be
a little faster).
Just some additional thoughts on the subject..
can someone please give Jakob a nudge in the side to wake
him up.. he shouldn't be sleeping on the job ;-)
Sincerely
Mark
--------------------------------------------
Mark R. Jonkman
ADDRESS: 1902 E 4500 South, Holladay, UT 84117
PHONE: 801-274-1096
EMAIL: [EMAIL PROTECTED]
--------------------------------------------
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/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!]
