Fwd: AppleScript questions/issues

[Brian C.]

Brian -
I haven't done much OO scripting in a while, but our QA lead is doing a 
ton of it as we're working on OO3 - i passed your questions along to 
him. His comments and questions are interspersed below. Including the 
list on the forward because several of the answers are probably useful 
for general consumption...

bwc


Begin forwarded message:

>
>>> - Inconsistency of results for columns and rows
>>>
>>> When I do something like:
>>> 		get selected column
>>> I'll get back a result in the form of:		
>>>     column 4 of document 1 of application "OmniOutliner"
>>> All's fine there.
>>>
>>> When I do something like:
>>>     get selected row
>>> I'll get back a result in the form of:
>>>     child 57 of child 1 of document 1 of application "OmniOutliner"
>>> Huh? I would expect something like:
>>>     row 57 of document 1 of application "OmniOutliner"
>>> Because I requesting it in terms of "rows". If I was asking in terms 
>>> of
>>> "child" I would not have an issue with the result. But that would 
>>> require
>>> a "selected child" property which I don't yet see (OO 2.2.6).
>
> Yup. Confusing. The thing to understand is that child and row (and 
> descendents and ancestors) are synonyms and are required that way 
> because row class has multiple relationships of type "row". 
> Applescript requires that you distinguish these relationships by type. 
> Sad, but true.
>
> Here is an additional example:
>
> tell application "OmniOutliner Professional"
> 	activate
> 	tell (make new document at end of documents)
> 		tell (make new row at end of rows)
> 			set text of cell 2 to "top"
> 			tell (make new row at end of rows)
> 				set text of cell 2 to "innie"
> 				tell (make new row at end of rows)
> 					set text of cell 2 to "way innie"
> 				end tell
> 			end tell
> 		end tell
> 		set expanded of every row to true
> 		
> 		row 3
> 		
> 	end tell
> end tell
>
> this replies with "child 1 of child 1 of child 1 of document 1" and 
> that actually tells me a lot about the structure of the document, but 
> is confusing because you asked for a row and got a child. Once you 
> know that they are the same thing, it becomes less of an Issue and 
> more of an Annoyance.
>
>>> - No true currency commands (not that kind of currency ($))
>>>
>>> The kind of currency I'm talking about is "what is the current ___" 
>>> type
>>> of property.
>
> We don't actually support currency at all. We support numbers and 
> simply have formatters on the numbers that make them look like 
> currency.
>
>>> OO seems to address current row by the "selected row"
>>> property. In a similar fashion, current column by "selected column". 
>>> But,
>>> it appears that you cannot have in the selected row/column 
>>> implementation
>>> both at once. And that IMO is what a true current row/column would
>>> provide. I would then know for example, regardless of which was 
>>> selected,
>>> that the current row is 57 and the current column is 4.
>
>>> This all leads to the current cell implementation. Again IMO, current
>>> cell is the intersection of current row and current column, and 
>>> that's
>>> also where the insertion point is located. I'm sort of amazed that 
>>> this
>>> is not present. I might enter some text and then wish to have 
>>> additional
>>> entry and/or calculations performed via script. Without current 
>>> cell, I
>>> can't do this (in a dynamic fashion). Any moving to cell offsets 
>>> (rows
>>> above or below, columns left or right) is woefully problematic 
>>> without
>>> knowing where you are starting from.
>
> Not quite true on a couple of fronts. I am going to make the following 
> assumptions: that you are using OO more like a spreadsheet and are 
> scripting it to do spreadsheet like functions.
>
> It is true, you cannot have the selected row/column implementation at 
> once. In the same vein, you can't select both a row and a column at 
> once. The same is true (last time I used it) in MS Excel. Selected row 
> means every cell of row X. Selected column means every cell of column 
> Y. We don't provide any means (GUI or otherwise) to select one of each 
> at the same time.
>
> Knowing this doesn't really solve your problem though. You probably 
> want to be able to go to cell X, Y and do stuff with it's contents. 
> This is a snap in Apple's UI Scriptability suite, but unfortunately, 
> since we are using a custom view (read: not even remotely a descendent 
> of NSOutlineView or NSTableView) apple doesn't have any insight into 
> the structure of our UI.
>
> I've filed a bug on this and assigned it (tentatively) to 3.0.
>
>>> I would suggest a change to have a new document property - selected
>>> orientation. This would have a value of either "row" or 'column"
>>> depending on what was selected in the document. With the addition of 
>>> the
>>> document-level current row/column/cell properties I just discussed, 
>>> the
>>> DOM for OO gains flexibility and power (IMHO).
>
> What would this do for you? I'm not a big spreadsheet user, so I 
> simply don't get it.
>
>>> Some examples:
>>>
>>> get selected column
>>> Result: column 4 of document 1 of application "OmniOutliner"
>
> currently possible in 2 & 3.
>
>>> get selected row
>>> Result: row 57 of document 1 of application "OmniOutliner"
>
> currently possible in 2 & 3.
>
>>> get selected cell
>>> Result: column 4 of row 57 of document 1 of application 
>>> "OmniOutliner"
>
> might be possible in 3.
>
>>> get selected orientation
>>> Result: orientation "row" of document 1 of application "OmniOutliner"
>
> not even on the drawing board. yet.
>
> I'll go further and add:
>
> + get selected rows
> - Result: { child 1 of document 1, child 2 of document 1 }
>
> might be possible in 3... I'll throw a minor tantrum if not (a bug is 
> filed, but not yet assigned).