Mark R. Jonkman wrote
> 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).
I agree with Mark. The difficulty for me is establishing effective lines of
communication between the various objects that respect the principles that
accessors tend to indicate sloppy encapsulation, and that 'mutual references
are evil'.
Leaving aside the 'mutual references' issue (which still confuses me), I'd
approach the problem something like this:
A. Identify classes:
QTObject
-- responsible for the media (no other objects should deal with its QT
member directly)
-- responsible for enabling/disabling any control widgets should the media
not be ready
Controls / Widgets
-- responsible for accepting user input (mouse clicks etc), and outputs
messages to the QTObject
-- any controls (such as a slider) should be responsible for all their
subcomponents (Widget Subcomponents, such as the thumb of a slider,
shouldn't have anything to do with any objects outside their subsystem)
-- should be generic and not specific to the QTObject
B. Establish communication channels:
QTObject
-- should be aware that various widgets will want to send it messages, so it
will have a method for return a reference (or other form of address, such as
spriteNum) when a widget asks for the address
-- the QTObject will also want to send messages to the widgets (to update
the progress bar, to tell them to go into 'disabled' state if the media is
not available etc), so it will need keep a list of Widget addresses
Widgets
-- these need to be able to send messages to the QTObject (to play, stop
etc)
-- some widgets will need to be able to receive messages from the QTObject
(the movie is playing, what percentage has been played etc)
C. Sketch out classes:
/// QTObject
property myWidgets
on mRegisterWidget (me, widgetRef, groupID, widgetID)
if groupID = myGroupID then
case(widgetID) of
#PlayButton:
myWidgets.add(widgetRef)
widgetRef.mSetEnabledState(myState)
widgetRef.mSetCallBack(me, #mPlay)
... etc
end case
return me
end if
end
on mDeregisterwidget (me, widgetObj)
-- delete reference to the widget
end
/// Widget / Generic Button
property myTarget, myGroupID, myWidgetID
on beginSprite (me)
sendAllSprites(#mRegisterWidget, me, myGroupID, myWidgetID)
end
on endSprite (me)
sendAllSprites(#mDeregisterwidget, me, myGroupID, myWidgetID)
end
on mSetCallBack (me, callbackObj, aMethod)
myTarget = callbackObj
myCallback = aMethod
end
on mouseUp (me)
if myTarget.ilk = #instance then myTarget.myCallback()
end
on getPropertyDescriptionList (me)
-- assign myGroupID, myWidgetID etc
end
Unless I am missing something (I've not been following the thread closely),
the communication between the QTObject and the various widgets is confined
to calling methods. There may be a fine line between passing data in a
parameter (such as the percentage of the movie played) and a blunt "heres my
private data for anyone that asks" type accessor, but surely such a line can
be measured only by how it protects object encapsulation and re-usability?
(I'd love to know how you can create such dynamic systems without mutual
references though)
Luke
[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!]
