<The previous article in this series | The table of contents of this series |
Here Is a Link to a List (Under Construction) of Dispatch Command Specifications That Can Be Used for Invoking Dispatch Commands
About: UNO (Universal Network Objects)
About: LibreOffice
About: Apache OpenOffice
About: Java Programming Language
About: Java Programming Language
About: LibreOffice Basic Programming Language
Necessity for a List of Dispatch Command Specifications That Can Be Used for Invoking Dispatch Commands
Here are -Hypothesizer and -Rebutter sitting in front of a computer screen in a room on a brook among some mountains on the Bias planet.
As we investigate how to trace the movement of the current cell, a haunting suspicion is "Aren't there some dispatch commands we can use for this purpose?" However, as we can't find any satisfactory list of dispatch command specifications, that suspicion is left haunting us.
Satisfactory?
Well, there is a list of dispatch commands, but that isn't satisfactory . . . for our purposes.
Let me see that list?
Here it is.
-Hypothesizer shows the document in a web browser. -Rebutter scans the document.
'Commands that are accessible through the GUI'?
That seems to imply that commands that can't be accessed through the GUI aren't included, which is a reason of its being unsatisfactory . . . for our purposes: whether a command can be accessed through the GUI or not isn't any our concern.
The column titles of the list are 'Commands', 'GUI Elements', 'Internal definitions of commands ID', 'Short Description', and 'ID' . . .
Why aren't the first characters of 'definitions' and 'commands' capitalized?
How should I know?
Does 'Commands' mean URLs?
Actually, the 'Command' prefixed by '.uno:' is the URL.
There is a dispatch command, 'StatusDocPos', whose 'GUI Elements' is 'S'. What does that mean?
'S' seems to mean the status bar.
I know that, but how can we invoke the 'StatusDocPos' command from the status bar?
Well, I guess, we can't invoke that command from the status bar, but the result of an internal invocation of the command is displayed on the status bar.
I wouldn't say that such a command is "accessible through the GUI", but that results of such a command is accessible.
Whatever.
And how are 'Internal definitions of commands ID' and 'ID' different?
I guess, what they mean is this, for example.
#define SID_AVMEDIA_PLAYER 6694
So, does 'ID' also mean 'commands ID'?
That's my guess.
I wondered, "ID? ID of what?"
I guess, the writer thought, "As I said it 'commands ID' once, I will be allowed to leave the qualification, 'commands', out hereafter."
I thought, "As one is called 'commands ID' and the other is called just 'ID', the two must be different things."
Well, I understand that misunderstandings happen that way.
And 'Short Description'? Aren't these short descriptions too short?
Well . . .
For example, 'Absolute Record'? What is an absolute record? What does the command do with an absolute record?
Well, that list is really an internal document, which isn't supposed to be understood by general users.
Not knowing what are absolute records may be just our insufficiency of knowledge, but I wonder, how do internal people know what does the command do with an absolute record . . .
Probably, that's obvious for internal people who share a certain mindset.
Anyway, that list is written in a secret language for internal people, which is another reason why that list is unsatisfactory . . . for our purposes, and as there is no explanation of command arguments, we can't call commands based on that list, which is the biggest reason why that list is unsatisfactory . . . for our purposes.
And isn't that list old?
Judging from the title of the document, it's old, which is another reason why that list is unsatisfactory . . . for our purposes.
Does the nonexistence of any list that is indispensable for calling dispatch commands imply that we aren't supposed to call dispatch commands?
I wonder. We might be supposed to know specifications of dispatch commands by reading source files.
Anyway, As we try to use some functionality of LibreOffice from our programs, we have to know specifications of dispatch commands: as we discussed before, we can access only part of the functionality of LibreOffice in the way we have mostly relied on (getting references to UNO objects and calling methods of those UNO objects). The dispatch mechanism is the other way of accessing the functionality of LibreOffice.
We can use the 'macro recording' feature to know some information of some dispatch commands, can't we?
Some . . . yes. However, that feature isn't particularly perfect.
How 'not particularly perfect' is it?
It does not record every possible command, not record every possible command argument, or not explain command arguments.
Ah, the last part is undeniable.
We want to know what each command argument means and what are options for each command argument, but we can't do that by a single macro recording.
Can we do that by multiple recordings?
In some cases, we would be able to do that by recording all of the possible argument patterns, but maybe, the GUI doesn't represent all the possibilities. And if we would be able to do that, that would be a tedious task.
And you say, not every command or command argument is recordable?
Yes, I say so, based on some tries. It seems that arguments that can't be prepared easily or commands that require such arguments won't be recorded.
Ah, an argument may not be a string or a number, but a UNO object that can't be gotten easily.
An example is the certificate argument of the command that exports the specified document as a PDF file.
We Begin to List Dispatch Command Specifications
The same with the previous scene.
So, we need a list of dispatch command specifications, and we will have to list them ourselves.
You say "we will have to", but there are very many commands, according to that list. Are we going to list all the commands?
-Hypothesizer scans that list.
. . . As we are dealing with only Calc right now, first we will concentrate on commands that can be invoked on Calc.
All commands for Calc?
-Hypothesizer scans that list, again.
. . . Honestly speaking, there are many commands that we will never be interested in. In fact, we aren't interested in commands that do what we can do by handling UNO objects.
For example?
For example, . . . 'Add'.
What a vague name is that? Add what?
The 'Short Description' says, "Append Sheet", which I understand as "This command appends a spread sheet."
So, we aren't interested in that command because we can append spread sheets by handling UNO objects?
Exactly. We might list also such commands in the future, but their priorities are low.
So, we don't declare that we are going to list all the commands, but will pick up commands that interest us, one by one.
Will we pick them up based on the very 'Short Description's of that list?
Actually, we won't rely much on that list. That list is old and only includes commands that are accessible through the GUI. We will have to pick up URLs from a source file. As we have to wildly infer what those commands do, some commands picked up that way may turn out to be useless for our purposes.
What will be our first command?
Let's begin with a command we already know: '.uno:GoToCell'.
Where will be our list?
Here. From each command in the list, we can go to the command specifications page, which explains command arguments and the return.
- Apache OpenOffice Wiki. (2010/12/13). Framework. Retrieved from https://wiki.openoffice.org/wiki/Framework
<The previous article in this series | The table of contents of this series |
