When clicking f.i. a button It would be very usefull to be able to get the button's objectname, the segment of the button ( number ) and/or use Self.
This, of course, to pass it as a script parameter
I would slightly modify this to be: Get ( TriggerObjectName ) which would return:
1. the object name of a button that was clicked
2. the script name of the previous script in the script stack, i.e. the calling script
3. the object name of a field or layout that triggers a script trigger
...and so on.
While waiting to have more information and therefore more control natively on the button bars, you can test (and perhaps adopt? ) a very nice tool that will save you a lot of time: BBT (ButtonBarTool) !
I would suggest this in a completely different direction than focusing on 'active' objects.
I'd suggest something like a: GetLayoutObjectAttribute ( Self; "xyz" )
this would allow objects to 'become intelligent' -- knowing who they are and how they relate.
one could then tie, say a button bar button calculation to the object name of itself (by 'self', not by objectname), and thereby perform a lookup on it's name..
this could become HUGELY powerful in dynamic development of conditional formatting and design/visibility of numerous layout objects..
For example, the age-old idea of creating a bar graph using button bars would become trivial, as one could point ALL references for all enclosed button bar buttons at their enclosed bar (by Self), allowing the developer to simply change the object name of the bar to fully manage conditionals for all buttons within that bar.
It would be valuable in other uses for conditional formatting, visibility, etc - as you would no longer have to actively name every single item, but simply encode that item with a set of intelligent codes..
For example, one could have a button or object which could be programmed to have numerous different colors or attributes based upon the data presented in (or thru) the object name or value of its enclosed object (or its own objectname, location, etc)..
The ramifications of this would allow a developer to create a single button which could masquarade as dozens of different buttons (without any reprogramming) simply by virtue of its layout attributes (what it is named, its enclosing object, or any 'queriable attribute' of it or its enclosing object etc)..
Retrieving data ...