<The previous article in this series | The table of contents of this series | The next article in this series>
How to Listen to Spread Sheet Cells Selection Events and (Possibly) Trace the Current Cell Movement in LibreOffice or Apache OpenOffice Is Explained
About: UNO (Universal Network Objects)
About: LibreOffice
About: Apache OpenOffice
About: Java Programming Language
Necessity for Listening to Cells Selection Events and Clarification Between Selected Cells and the Current Cell
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.
When we have created a spread sheet cell editor, we encountered an issue of how to detect changes of cell selection on spread sheets.
Ah, we wanted our spread sheet cell editor to be able to automatically attach to the current cell as we select a cell on a spread sheet.
From the viewpoint of functionality, we can do without reacting to such events, just requiring users to push a button in order to reattach the cell editor to the currently selected cell, but from the viewpoint of user experience, such a requirement can be frustrating.
There are some use cases in which we don't want the cell editor to be linked to the current cell, but when the user is in the mode, "the cell editor should be linked to the current cell", . . .
. . . that requirement is frustrating. I mean, in the user's head, they are already linked, but the program refuses to understand that expectation. The user thinks, "Why isn't my intention understood?" He or she feels alienated.
I don't know whether someone has a sense of alienation just using a piece of software . . .
At least, I feel alienated.
OK. Talk only of your feelings. Don't assume you know what others feel.
I feel being abused.
'Abused' will be an overstatement . . .
That's my feeling.
Well, I can't deny what you feel, but I can say, "You are cranky".
. . . I know.
By the way, we have been using two terms, 'the current cell' and 'the selected cell', interchangeably, but in fact, multiple cells can be selected at the same time, right?
Ah, . . . that hits us close to home . . . us who are proud of accurate expressions . . .
Don't be proud of that, or of anything. Just be a student of accurate expressions, or of something.
. . . Yes. All we have to do and can do is to do our best, admit mistakes, and improve . . . So, let's clarify things here.
First, I admit here that I was thinking only of single cell selections. Certainly, I knew that we could select multiple cells, but that wasn't in the scope of our discussions. When we use only simple single cell selections, the selected cell is the current cell. However, in general, there isn't such thing as 'the selected cell', but are multiple selected cells.
So, what is 'the current cell'?
I don't know whether 'the current cell' is a term universally agreed upon, but I am using the term as the cell that has the focus of key inputs.
So, even if there are multiple selected cells, there is only one current cell?
That's my understanding.
Is it also your understanding that the current cell may not be one of the selected cells?
Well, . . . as I far as I understand, it doesn't seem to be my understanding.
Open a spread sheet document.
-Hypothesizer opens a spread sheet document.
Select 3x3 rectangle of cells.
Why 3x3?
. . . It doesn't particularly have to be 3x3; I just thought, without the size being specified, someone who got the direction would be at a loss . . .
OK. 3x3.
-Hypothesizer selects a 3x3 rectangle of cells.
The top leftmost cell is the current cell, right?
Right. That cell is enclosed in the black borders.
Now, click the center cell with the control key pushed.
Ah, . . .
How to Listen to Cells Selection Events
The same with the previous scene.
In fact, registering a listener of spread sheet cells selection events, itself, is easy.
'Itself'?
Well, there is a problem, which I will talk about eventually.
The controller has the UNO interface, 'XSelectionSupplier', to which we can register an events listener of 'XSelectionChangeListener'.
Does 'the controller' mean that controller we used before?
Yes, I mean that controller.
'XSelectionChangeListener' has a method, 'selectionChanged', which is called when the cells selection has changed.
The selection information is passed as the argument of the method, I presume?
Actually, it isn't directly passed, but the event source is passed.
What is the event source, exactly?
The controller itself.
Well, so we are supposed to get the selection information from the controller?
That's my guess.
Well, it's fine because we can get the selection information from the controller.
A problem is, the listener method is called four times when we click a cell on a spread sheet.
. . . Why?
I don't know. I also noted that when we move the selection by pushing an arrow key, the listener method is called only once; when the selection change is caused by an activation of a spread sheet, the listener method is called twice.
. . . Why?
I don't know.
Anyway, as we don't want to unnecessarily react multiple times, we will have to have a way to ignore unnecessary events.
I guess so.
My plan is to save the last selection information, and react only when the selection information is changed compared with the last selection information.
Hmm, in what form will you save the last selection information?
The selection can be a single cell, a single cells range, or a collection of cells ranges, and we will identify a cell by its row and column indexes, a cells range by its top row, leftmost column, bottom row, and rightmost column indexes, and a collection of cells ranges by the identities of all of its element cells ranges.
I guess, a selection can be split into multiple cells ranges because the selection may not consist of a consecutive area?
It's not just a matter of consecutiveness. As a cells range is really a cells rectangle, if a selection isn't a rectangle, it will be split into rectangles.
Does the splitting of a selection into cells ranges depend only on the shape of the selection?
Ah, you seem to be asking whether it depends on the formation process of the selection . . .
I seem to be asking that. For example, if a selection was first consisted of two rectangles, and is made a big rectangle by adding some cells, will the selection become a single cells range?
Probably . . .. I don't know for sure, but that won't matter in this context.
How to Trace the Current Cell Movement (Not Found, Actually)
The same with the previous scene.
Tracing the current cell movement is a problem . . .
How is it a problem?
I can't find any listener of such events.
So, . . . did you give up?
I didn't particularly give up; I was persuing a possibility . . .
Which is?
I thought that the current cell might have a property value or something that distinguishes itself as the current cell . . .
The existence of such a property value or something aside, isn't it too resource intensive to find a single cell among so many cells?
Ah, in that respect, it seems unpromising, or I would say, unrealistic.
You will have to search the spread sheet or the controller for such a property value.
Actually, I did, and couldn't find one. I also thought that there might be another UNO object accessible to us that provides a way to such a value, but I couldn't find one. You know, the reference documents aren't so intensive . . .
Well, when a cell is clicked, does the cell always become the current cell?
As far as I know, yes.
Can we detect such clicks?
Yes. So, limited to that particular case, we can detect the movement of the current cell. However, as you of course know, the current cell can also be moved by key strokes.
Can we also detect key strokes?
Yes.
Are there other sources that can move the current cell? Psychokinesis? A strong belief or a will to power?
As far as I am concerned, clicks and key strokes are the only sources.
Hmm, . . .
Are you suggesting that we could infer the current cell movement from clicks and key strokes, not detecting the current cell movement?
I'm not suggesting anything.
By the way, what if we keep pushing the return key for a while? Can we trust that the number of key strokes we receive is the number of key strokes the LibreOffice program processes?
Well, . . . I don't know. I don't see a better way than we just try . . .. What are you suggesting?
None at all.
. . .
<The previous article in this series | The table of contents of this series | The next article in this series>
