Le 25 mars 07, à 07:22, Andy Dent a écrit : >> I've set it to the app itself > I wouldn't. > [...] > >> it involves writing many methods to create an >> interface between RBScript and the other objects accessible to the >> user. > > You may want to rethink your design then. Why does one particular > script require such a broad interface - could the logic be broken > down into multiple scripts?
I dont think so. One single line of code in the script source must be able to deal with several different objects, in a command like someObject.someNumProperty=len(someOtherObject.someStringProperty) > Don't forget that the RBScript receives a chunk of text which might > not be just what the user enters - a common technique is to include > your own class definitions or variable declarations before the user > script. I've thought about that. But an object defined and instantiated in a script would disappear as soon as the script is over, right ? I would do that if the app could hold such an object in memory, and if another script entered by the user could use it again. I can imagine a possible workaround from the top of my head : to define classes within the script where the constructor automatically creates a reference to its new instance in a property of the application. Then, the script would include a portion of code that creates a new copy of these instances to make them available to the script. Another portion of code would 'refresh' on the app side the image of objects used. If it makes any sense (I realize I might be unclear), do you think it would work ? Octave _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
