What is Index prop? 32767?
args2(1).Name = “Index”
args2(1).Value = 32767
dim args2(2) as new com.sun.star.beans.PropertyValue
args2(0).Name = “DocName”
args2(0).Value = “Sales 2 - Open Office”
args2(1).Name = “Index”
args2(1).Value = 32767
args2(2).Name = “Copy”
args2(2).Value = true
dispatcher.executeDispatch(document, “.uno:Move”, “”, 0, args2())
I don’t know.
And I don’t know anybody who knows anybody who knows …
@JohnSUN knew.
Judged from my experience:
There are a few developers developing and debugging .uno: commands.
There is no clear regime concerning the documentation of .uno: commanmds and its availability.
There is no organized namespace for arguments to use.
Therefore a thing named “Index” when related to one command may be a collection of flags (in this case telling what (kinds of) attributes should be pasted, may in a similar case in a slighhtly different context be named “Flags”, and in a third case possibly “Attributes”.
Can you think of anything that clearly contradicts my assumption?
Once upon a time, when bytes were big and spreadsheets were small, the number of sheets available was limited to 2^15-1=32767
Since the command to copy a sheet had to specify where the new sheet should be inserted, the macro recorder recorded the command as “put at the very end” exactly like this - “put 32767th sheet in this spreadsheet”
Strange.
I never used many sheets, but thought the maximum index was much lower.
Now I’m standing in a daze, and have to admit … find the words yourself.
Anyway: Do you, Vladyslav, know a place where facts about .uno: commands the usable argument names and the meaning of argument values are clearly described?
Are you kidding? No, I don’t know such a place… You wrote correctly, most likely there is simply no such place… My understanding of all these strange things is just intuition.
Fairy intuition (once upon a time) 
Sometime, at the instigation of Pitonyak, I tried to use this table. I haven’t been very good at it. slots.ods (204.2 KB)
(Three minutes ago it was a .sxc file - I couldn’t attach it to the post, the forum engine didn’t allow it. I had to convert to .ods)
The most complete information about .uno commands here (including the program to generate the list).
I’m too lazy to count now how many questions containing macro recorder production scripts instantly receive the comment “you should not record macros, you should write them.”
This is my message - just an analogy that will explain this position.
If you look at the code generated by the macro recorder, you can immediately see that only four office objects are used in the code. However, two of them - ThisComponent and CurrentController - are mentioned only in the first line. That is, of everything that is in the office suite, only two objects are used.
When constructing a script, the programmer acts as a sign language interpreter who tries to translate the task into a language understandable to the computer. Of course, the wider the “language reserve” of the programmer, the better the translation.
Just compare what a regular sign language interpreter uses and what Hector Salamanca had to use to communicate
Therefore, the recommendation will always be this - do not torture the tongue-tied macro recorder, do not force him to write hundreds of lines of code, he will still not be able to make a good script. So once again -
You should not record macros, you should write them
In the future, perhaps this will be the case. Today, alas, not all .uno commands have an equivalent in the UNO API.
For the command from this topic, of course, there is a corresponding UNO method.
I am interested in some relevant examples.
I just looked through an old toolbox and found that all the routines I had used dispatcher commands in, meanwhile were replaced by “pure API”.
But even if I missed some exceptions: All the concerned routines weren’t just recorded but written using the DispatchHelper and the respective frame.
Well, I simply couldn’t stand the "document = " used for a frame object.
Offhand.
Have no equivalent in UNO API:
.uno:Copy, .uno:InsertContents.
For multiple sheets of a Calc document (operations for a group of sheets):
.uno:SelectTables, .uno:Move.
More convenient/efficient than UNO API equivalents:
.uno:ConvertFormulaToValue, .uno:SetOptimalColumnWidth.
Donno. How to get via the UI?
In the other cases there arent exact equivalents, but satisfying (if not better) solutions.
For an example
cellRange.setDataArray(cellRange.dataArray())
replaces formulas with the results.
Advantages? Mhm… It preserves the reporting of errors, albeit unified as “#N/A”.
And
Sub setOptimalColumnWidths(Optional pSCRgs)
If IsMissing(pSCRgs) Then pSCRgs = sheetCellSetAsRanges(ThisComponent.CurrentSelection)
REM Here I used a function I made to get unified handling of selections in Calc.
For Each rg In pSCRgs
rg.Columns.OptimalWidth = True
Next rg
End Sub
What’s bad with it?
I’m afraid this needs a substantive discussion and tests. We can be disqualified for offtopic.
Someday it will be possible to test (in a suitable topic).
https://wiki.documentfoundation.org/Development/DispatchCommands
would be the best place (and could be improved further), with references to the source, where the argument names are specified (SDI).
The references are not ideal: they need to be revision-specific, since today, e.g., reference to .uno:AddDateField is displaced, because the source files have changed since, and the URL didn’t include the specific revision when it was current.
EDIT: ah, I see that @sokol92 already mentioned it. Sorry 