>"transcript's ideosyncracies " I guess the basic issue is that the messaging hierarchy is designed so that there are several ways of building your functions/procedures into libraries, script containers, and objects so that they are 'available' in the message path and yet be dynamic.
You have chosen to put a function in one of the few places it is more difficult to "call". You could put this in a background group script or stack script just as easily and not have the ugly. This is "idiosyncracy" is actually fundamental to the "on mouseup" handler working.. imagine if the button and field objects did NOT have the current message path... that would be ugly scripting indeed, requiring an id for everything and no longer being a rapid development environment. If you do not want to code according to the way Revolution/Metacard/Supercard/Hypercard is set up, then I agree that you will generate several instances of ugly code. >" It also kinda obviates the entire strategy of invoking a method in >another object." Depends on the object, since you have many to choose from. Putting a function in a button or a field will have the advantage that it won't be accidentally called by another handler. This is very useful for user interfaces, menus, etc. It is this a dynamic nature of XTalk that gives it avenues of richness. You can set the scripts of objects, reset them, move them in and out of the hierarchy over to different stacks, into back or front script position and more. Move card to card and have different features and functions on each one. You could EVEN have most all of your scripts in text files and set the script containers of flds, btns, cards, etc when the stack is opened. Jim Ault Las Vegas On 3/17/06 12:09 AM, "Arthur Urban" <[EMAIL PROTECTED]> wrote: > The problem with this solution is that varA and varB are not evaluated. > In order to use your syntax it would need to be: > > send "calc" && varA & comma & varB to btn "source" > or > send merge( "calc [[varA]], [[varB]]" ) to btn "source" > > I find both inelegant readability wise. I think there is a great burden > on language developers to create a language that goes as far as it can > toward self-documentation. I feel that the message passing mechanisms > are a sore spot in transcript. I do not understand why Rev would be > unable to parse my proposed syntax. > > Thank you for your suggestion, however! > > Andre Garzia wrote: >> Err... >> >> can't you make it a Handler use send and check for the result??? >> >> send "calc VarA, VarB" to btn "source" >> put the result into localResult >> >> of course calc is not a function but a handler with a return statement. >> >> Cheers >> andre >> >> >> >> On Mar 17, 2006, at 2:55 AM, Jim Ault wrote: >> >>>> I'm not sure that this is the right direction for any language to be >>>> headed. Please explain why we can't have the following syntax: >>>> >>>> put calc(varA,varB) of btn "source" into localResult >>>> >> >> _______________________________________________ >> use-revolution mailing list >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-revolution >> >> > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
