Hi, At 12:01 PM 5/15/2002 -0500, you wrote:
>>>>What is the purpose of using 'alert'? >>> >>>Just to show that the program knows something is happening. In a >>>projector that's one of the few ways you can easily get an internal >>>event to display some kind of external message. >> >>Whar are the other ways? > >They involve creating a projector that displays a message window at >runtime, or that writes message window output to a text file. That's >somewhat involved and not really important to know right now, beyond >knowing there are ways to get *some* information from a projector >regarding its internal processes. I'm sorry - are you becoming tired at having to explain (and re-explain) so many concepts? I apologize for asking so many questions but there are so many things which are unclear and very confusing as I try to explore Director and Lingo. Instead of becoming easier as I go along, it is actually becoming more and more difficult to understand. >>>Because you have to. There is no other way to save user information >>>except to write a handler that does so, saving out whatever information >>>you want to retain. >> >>So this is another use for custom handlers - to save information? > >You can use custom handlers to do anything you need to do that Director >(or Director via Xtras) is capable of doing. > >>>In an object, encapsulation is innate, yes. You have to go to rather >>>extreme lengths to get past that encapsulation, in fact. >> >>No one does this? > >I believe those who don't have a complete understanding of OOP do so. I don't understand what you mean. >>>>How does an object look for and squash errors? >>> >>>It doesn't. Your code makes it do so. The three-behavior version is a >>>simple example of that. >> >>Sorry, I still do not understand. I use the object so that I may make >>use of its code for this? > >No, you create code that traps errors. You can use that code in an object, >if you are doing OOP design. > >>Could you please provide an example of non-OOP language so that I may >>understand better what you are trying to say? How does it look like? > >Any code that takes place in a movie script is non-object code, something >that doesn't require instantiation, is not encapsulated, and is generally >globally available. The "TestDefault" handler I sent earlier is such an >example. So the major difference between a parent script and a movie script is that a parent script is OOP while a movie script is not? >>>That's not something that can easily be answered apart from the phrase >>>"with experience". With experience, an understanding of abstraction of >>>data from interface will be easier for you. >> >>But I still do not understand. Why is it that the more I abstract data >>from interface, the harder it is to break things? > >Interface is the means by which data is manipulated. If the interface is >mishandled, data can become damaged. Thus, the more abstraction you have >between data and interface -- the less *direct* access interface has to >data -- the less opportunity there is for that interface, via accidental >or deliberate mishandling, to corrupt the data. > >>Is a parent script then somewhat similar to a movie script, i.e. as in >>the pizza ship example, >> >>on page 364, >> >>'Since you're accessing the same shop object you made the first time >>(oShop), the properties you set for the initial call has been >>retained. They're now available anywhere,as many times as you want, as >>many places as you want.' > >Not really -- it's a script instance contained inside a variable. Its >functions might be available for calling by its access methods, but they >have to be explicitly invoked. What's more, the data contained and >manipulated inside one pizza shop instance would be discrete from data >held inside another instance, even when that instance is being created and >handled in the sane Director movie. It's as though you have two completely >separate miniature programs running in your Director movie. Then why do you write that they are now available anywhere, as many times as you want, as many places are you want? >>Are property lists the only way to store orders? > >They are the most efficient way that is internal to Director (that uses >Director's own tools). Does this mean that there are other ways which do not use Director's own tools? >>>>>Not just that. You also write it as a form of error trapping, as I did >>>>>with the void tests. It doesn't hurt to confirm the integrity of a >>>>>variable before proceeding to work with it. >>>> >>>>How could I learn to write this ? >>> >>>Again, experience -- start with the stuff you've seen so far. >> >>But I barely understand what you write... Aren't there any standards or >>rules I may follow? > >Actually surprisingly little. Lingo is a very loose language as far as >structure and syntax are concerned. If you're looking for structure, to no >small extent you have to either create your own or adopt that of others. >That's why I introduced and explained my own set of conventions rather >early in the beginner's guide. Yes, I am beginning to understand your set of conventions but I am still unable to comprehend completely. >While this lack of structure does make it easier to simply sit down and >start from nothing in Lingo, I believe it does make it harder to learn if >you've got a mind that prefers orderly handling of things. If, for >instance, you're a fan of symbolic logic, you might find Lingo to be very >chaotic. No, I just simply don't understand it. How then is it chaotic? >>>>Here the active sender is the volume control button, right? >>>>The passive receptor is the QT music sprite. >>> >>>Yes. >>> >>>>And it is the passive receptor that prevents script errors. Would >>>>this normally be the case in this type of encapsulation? >>> >>>This is one way of doing it, but it's not by any means the "required" >>>way of going about it. >> >>What then are other ways of doing it? > >After I'm done numbering the grains of sand on the beach I'll get back to >you on that question. ;) Sorry, I really do not understand what you mean. >>That is, passive receptors does not always prevent script errors? > >That's correct. You can't plan for everything, for instance, and you can't >create perfectly bulletproof code, if the program is going to do something >of even moderate complexity. All you can really do is try to introduce as >much crash padding as possible. How much crash padding have I to introduce? Is there a way to do this? >>I substitute the code like this: >> >> >>on AdjustVolume me, yMyDirection >> >>on isOKToAttach me >> return sprite(me.spriteNum).member.type = #quickTimeMedia >> END isOKToAttach >> >> >> if yMyDirection = #down then >> sprite(me.spriteNum).volume = \ >> sprite(me.spriteNum).volume - 1 >> else >> sprite(me.spriteNum).volume = \ >> sprite(me.spriteNum).volume + 1 >> end if >> END AdjustVolume >> >> >>is this correct? > >No, you have one handler defined within another. Meaning I can't do such things? Rather no one defines one handler within another? >You'll want to remove the isOKToAttach handler from within the >SdjustVolume handler. Sorry, but could you please be more explicit? If I remove the isOKTOAttach handler, I place this where? Thank you. Noelle [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!]
