[Gambas-user] Problem with tableview when in edit mode

Doriano Blengino doriano.blengino at ...1909...
Sat Dec 5 22:49:23 CET 2009


Benoît Minisini ha scritto:
>> Don't take me wrong. Sometimes it seems to me that you don't read the
>> whole message before replying, and sometimes it seems to me that the
>> real problem is not in evidence (english language plays a role in
>> this...). You say that you just added a Click event handler to get the
>> program work. Well, this is not the problem. The program *is* correct
>> (it does practically nothing). The sample program, without
>> modifications, on some machine runs well, and on other machines shows a
>> problem that I will explain better. When you say "old version of gambas
>> (<2.13)", again it seems that you didn't read carefully what I've
>> posted. In every post I specified precisely what gambas version was
>> installed, what os was running on, and the QT library.
>>
>> Now the problem. The problem is that, when the grid is in edit mode, if
>> you press a cursor key the cursor does not move to the adiacent cell; it
>> does not stop: it travels all the cells until it stops on the upper-left
>> cell, or the lower-right one. By doing this, it scrolls the tableview up
>> or down, and if the cursor key was Left or Right, it goes to the
>> right-most or left-most, then wraps around and restarts. For every
>> visited cell a Click event is generated. Note that in the sample program
>> there was no Click handler, just to shows precisely that my program does
>> nothing strange in the click handler (by doing nothing, you can't do
>> anything strange). Now you see that I was not complaining about
>> gotfocus, or "not editable" cells, or anything else. I say that a single
>> key press should move the cursor by a single cell, not travel the whole
>> tableview.
>>
>> Now the history.
>>
>> 1. I discovered the error on one machine, with an updated debian stable,
>> gambas v. 2.15.2, libqt-mt.so.3.3.8, while working on an old
>> application. Suspecting that the complexity of the application could
>> have hide something, I wrote a new project (the sample program). Same
>> error. Then I tried it on the other machine: same OS, same libraries,
>> same X server - only gambas different: version 2.0.0. No error.
>>
>> 2. I posted a message on the list, to ask if someone else saw the same
>> error. Two users confirmed it - one gambas 2.16, another with gambas
>> 2.17. So the problem is alive, on at least three machines.
>>
>> 3. I tried on a third machine. Same os, same libraries, gambas 2.15,
>> same remote X server. Identical situation. No error.
>>
>> 4. Now I am at home. Same os, same libraries, gambas 2.0.0. No error.
>>
>> At this point, if someone tells me that I have to modify the program to
>> make it work, I ask myself _why_ it works (I have seen more machines on
>> which the program works well than machines where the problem shows up).
>> On my machines, which are four, I've seen the problem only once. But two
>> users on this list confirmed the error. So, it seems to be an error
>> which shows up rarely, if we want to say so.
>>
>> The only idea I have now is to go back to my first machine and
>> investigate more. It is very difficult to investigate on an error if
>> that error does not show up...
>>
>> Now I ask you: you say you added a Click event to make the program work
>> properly. Why you did so? Why you say this event handler was missing?
>> What was the "wrong" behaviour, when the event handler was missing?
>>
>> I wait for your reply; the next week I will work again on the original
>> machine (the only one where I saw the problem), and I am determined to
>> see over the fog.
>>
>> Regards,
>>
>>     
>
> No, no. I think I read you correctly. I am going to try to explain the things 
> differently...
>
> Before Gambas 2.13, when you hit an arrow key in the TableView control, the 
> TableView cursor was move by one cell only, and the Edit method was called 
> automatically. So things were working *only* for TableView whose all cells are 
> editable. For TableView having some cells read-only, the keyboard management 
> was flawed.
>
> So, in Gambas 2.13, the Edit method is not called automatically anymore, and I 
> decided that a cell will be considered as "non-editable" if the Edit method 
> was not called during the Click event. And "non-editable" cells are 
> automatically ignored when using the arrow key.
>
> That explains the behaviour you noticed in computers using Gambas >= 2.13. 
> (Let's ignore the computer #3 at the moment): for example, if you are on the 
> top of the TableView, and if you hit the "down arrow" key, the current cell 
> will be moved one by one until an editable cell is found. As you don't call 
> the Edit method inside the Click event handler, no cell is considered as 
> editable, and so the TableView cursor is moved down to the bottom. I hope I 
> was clear!
>
> As for the computer #3: I don't understand that you don't have the problem, as 
> the Gambas version is >= 2.15.
>
> To fix your problem, you *have to* call the Edit() method inside the Click 
> event handler. It will tell TableView that your cell are editable when the 
> user use the arrow keys. But, of course, you *can* use the Edit() method 
> outside of the Click event handler.
>
> Then things will work for Gambas >= 2.13, and stay the same for Gambas < 2.13.
>
> Regards,
>
>   
Ok, so we are talking about the same thing :-)

But this does not explain why the program works well the other times 
(computer #3, for example).

Knowing what there is behind, I will experiment (try to call edit in the 
click event: this should stop the crazy traveling).

But, I think that traveling many cells is anyway wrong - it is too easy 
to get the wrong behaviour. Would not it be more predictable to move 
just one cell, and simply avoid to enter the edit mode? This way, a 
programmer could understand that he should call edit() again.

Thanks for the more clear reply.

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."





More information about the User mailing list