AW: lingo-l OOP question
Hi Daniel! You could easily test it by a) watch the freebytes / freeblocks both commands don't work in Windows (at least not for me: win2000, Dir 8.5G) I would be lucky if I could use them change the image good idea, maybe I'll do that, unless someone else confirms the impression you're under ... Thanks anyway Michael [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!]
Re: AW: lingo-l OOP question
i think an even more sure fire way to see if all images dealt w/ are the same object, is if you just throw in a put imageXYZ command. if you have your image contained in variable x and you pass x to a new object, and the new object holds the image in variable y, if, from each object you put xy respectively, you should be able to compare what comes out. and yes, as long as you aren't specifically duplicating your image, it should be the same object (thus is a reference w/in your scripts, not actually occupying more and more memory). Evan Michael von Aichberger wrote: Hi Daniel! You could easily test it by a) watch the freebytes / freeblocks both commands don't work in Windows (at least not for me: win2000, Dir 8.5G) I would be lucky if I could use them change the image good idea, maybe I'll do that, unless someone else confirms the impression you're under ... Thanks anyway Michael [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!] [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!]
Re: AW: lingo-l OOP question
At 06:28 2002-09-11, Michael von Aichberger wrote: You could easily test it by a) watch the freebytes / freeblocks both commands don't work in Windows (at least not for me: win2000, Dir 8.5G) I would be lucky if I could use them Yea, they've returned bogus information on every Win system I've tried - ever since D7. I use Buddy API's baMemoryInfo(). It doesn't have an equivalent for the intended function of freeBlock, though. -- Mark A. Boyd Keep-On-Learnin' :) [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!]
Re: AW: lingo-l oop question
Michael, Welcome to the wonderful world of OOP. Actually, your questions are really about OOD (object oriented design). I'm sorry, but I don't fully understand what your program is trying to do. I'm sure that it's because I don't know enough about video rather than your explanation of the program. But I may be able to offer a few hints. I think Brian's description of nouns and verbs is an excellent way to help you design! As for your specific problem, if you are new at OOP/OOD, stay away from ancestors. It will only confuse you. From what I do understand about what you are trying to do, you probably don't need them anyway. In fact, I would probably do most of this work in a single object, with messages fed by behaviors. That is, assuming that the user works on only one sequence at a time, I would create a single global instance of the Sequence object: global goSequence -- global object sequence on startMovie goSequence = new(script Sequence) end on stopMovie goSequence.mCleanup() -- something to allow itself to clean up goSequence = VOID end That way, any behaviors you have on buttons can simply refer to the global object by name. For example, on your screen where the user enters data into fields, there is probably some OK button. When the user hits that button, you send a message to the goSequence object telling it to start. global goSequence on mouseUp me goSequence.mStart() -- ready to go end The mStart handler can check the user's input and see if it is OK to go. If not, it can put out an error message. If everything is OK, it can call some routine that really does the work. I know that my view of your program is very simplistic, but here's a skeleton of how I would build such a Sequence script: property pnFrames -- number of frames to generate for this sequence property pCurrentFrameNum -- the current frame number you are working on. on new me return me end on mStart me -- Check if data in fields is OK to go -- If not, put out error message and return -- If OK, start processing pnFrames = some calculation based on above data pCurrentFrameNum = 0 append(the actorList, me) end -- The following assumes that you can generate one frame at a time and this is not interruptable on stepFrame me pCurrentFrameNum = pCurrentFrameNum + 1 if pCurrentFrameNum pnFrames then deleteOne(the actorList, me) return -- we're done end if -- Do whatever you have to do to process frame number pCurrentFrameNum end on mStopRightThereThatEnough me deleteOne(the actorList, me) pCurrentFrameNum = 0 end on mCleanUp me -- get us out of the actorList if we are in it deleteOne(the actorList, me) end Then you can have a Stop button on the screen while processing the frames that just has this script: on mouseUp me goSequence.mStopRightThereThatsEnough() end As far as the me.propertyName stuff goes, if you declare a property and use it within the current script, you can choose to use me. or leave it off. That is: property pSomePropertyName on mSomeHandler me pSomePropertyName = 1 -- and me.pSomePropertyName = 1 -- will do exactly the same thing. end You only need to use me.some property name when the property is not defined in the current script. This occurs in two places that I can think of. 1) If you do not declare property spriteNum in a behavior, then you need to say me.spriteNum (alternatively, you can just declare it as a property and just use spriteNum), and 2) when dealing with ancestors - since a property may be declared in an ancestor but used in the current script, then you need to say me.some property name to make the Lingo compiler understand that this is a reference to a property. Hope this helps rather than confuses the issue. Irv At 11:57 PM +0200 8/1/02, Michael von Aichberger wrote: It looks at the data and finds out what source images are needed. I assume here you are referring to what image frames were specified by the user. If so, I'll buy that. No, to give you a simplified description of what could be going on: The sequence could be a zoom into or a pan across one very large source image. With source image I referred to that large master image. But I think you still buy that. So each oFrame object has the code to create an image. In my simplied example, as the oFrame object is created, it gets a reference to the source image(s), which is/are a property/properties of oSequence. It then copyPixels a selection thus creating the wanted single image. Again: Would I pass the very large source image as a parameter? No need to make oSequence an ancestor to oFrame (to inherit the property source image)? Sure, you could have a handler that looped through the frames and called something like oFrame.destroy(). How would the destroy method look like? I guess me = VOID wouldn't work well. Wouldn't it be sufficient to
AW: lingo-l oop question
It looks at the data and finds out what source images are needed. I assume here you are referring to what image frames were specified by the user. If so, I'll buy that. No, to give you a simplified description of what could be going on: The sequence could be a zoom into or a pan across one very large source image. With source image I referred to that large master image. But I think you still buy that. So each oFrame object has the code to create an image. In my simplied example, as the oFrame object is created, it gets a reference to the source image(s), which is/are a property/properties of oSequence. It then copyPixels a selection thus creating the wanted single image. Again: Would I pass the very large source image as a parameter? No need to make oSequence an ancestor to oFrame (to inherit the property source image)? Sure, you could have a handler that looped through the frames and called something like oFrame.destroy(). How would the destroy method look like? I guess me = VOID wouldn't work well. Wouldn't it be sufficient to delete the reference to the object in pFrames? Well, you could add the object to the actorList and then export an image on each stepFrame event. Which object? oSequence or oFrame? If oFrame then I could have hundreds of instances, all getting the on stepFrame event and all trying to do their job at the same time. That wouldn't work, would it? So it's rather an on stepFrame method in oSequence that increments a counter, so that on every stepFrame event another frame is created. Am I right? I think I need this approach because the image export with the direct image Xtra may take some time and in an repeat loop of hundreds of image the user wouldn't have a chance to stop/cancel the process. The progress bar is a good idea though. Can this approach work like that? Another question yet, more general: I have seen code, where all properties were referenced with me like that: me.pFrames. What for? Thank you very much for all your help Michael [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!]
