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

[Doriano Blengino]

Benoît Minisini ha scritto:
>> Benoît Minisini ha scritto:
>>     
>>>>> I am modifying an old program, which uses a TableView to construct an
>>>>> invoice.
>>>>> The tableview is almost always in edit mode.
>>>>>
>>>>> With gambas version 2.0.0, the original version I used to write the
>>>>> program, there is no problem (not this one).
>>>>>
>>>>> Now I upgraded to gambas v. 2.15 (debian package gambas2 2.15.2-1),
>>>>> running on a debian "stable" release.
>>>>>
>>>>> When in the tableview (in edit mode) I press an arrow key, the cursor
>>>>> slips on every possible cell in the request direction, until it finds
>>>>> the end of the tableview. But this is not enough: if the cursor key is
>>>>> Left or Right, the cell walking goes even further, wrapping to the next
>>>>> or previous row and restarting.
>>>>>
>>>>> I created an executable, and it behaves the same.
>>>>>
>>>>> Then I copied the executable to another machine, having gbx2 version
>>>>> 2.0.0, and the problem does not show up.
>>>>>
>>>>> The program uses explicitly QT; both machines have libqt-mt.so.3.3.8
>>>>> installed, and the same debian "stable" os, and I use both machines
>>>>> from a third machine running an X11 server (XMing). So it seems the
>>>>> problem is related to gambas.
>>>>>
>>>>> I send a sample project that shows the problem. Launch the application,
>>>>> click on the Tableview to focus it, and press a cursor key. The cursor
>>>>> will travel in the requested direction 'til the end of the grid.
>>>>>
>>>>> What can I do about this? I was very very reluctant to upgrade gambas;
>>>>> but I reached a point where I could no more install or upgrade my
>>>>> system. Even when trying to install a simple htop(1) from debian
>>>>> repositories, I was told to upgrade some fu*ing library, which in turn
>>>>> meant to upgrade gambas, which in turn meant to upgrade QT, GTK,
>>>>> poppler, libc, libc-bin... well, *hundreds* of packages. I will contact
>>>>> the debian mantainer about this - I don't care about postgres,
>>>>> firebird, curl, smtp, opengl, sdl, v4l, xml and things. It seems that
>>>>> to install gambas on debian one must pull in all the world. The other
>>>>> machine, having the old version of gambas, has no problems - I copied
>>>>> the gambas binaries directly, instead of installing them from packages.
>>>>> I can install and upgrade, and everything runs smoothly. Sorry for the
>>>>> debian-related blow.
>>>>>
>>>>> Regards,
>>>>> Doriano
>>>>>           
>>>> OK, I understand the problem.
>>>>
>>>> The TableView is designed so that editing a cell must be decided in the
>>>>  Click event. Otherwise, if the Edit method is not called during a Click
>>>>  event, keyboard events automatically jump them.
>>>>
>>>> You must call the Edit method inside the Click event, not the GotFocus
>>>>  event.
>>>>
>>>> Before, keyboard events never ignored cells, so things were working
>>>>  normally.
>>>>
>>>> Regards,
>>>>         
>>> I filled the documentation with that information for other having the
>>> same problem.
>>>       
>> Did you try the attached project?
>>     
>
> Yes. Did you try what I told you to do?
>
>   
>> I tried it once more on another machine: debian stable version 5.0.3,
>> libqt-mt.so.3.3.8, and gambas version 2.15.2; the error *does not* show
>> up, with the edit call in the GotFocus event. I just used the project
>> attached in the previous mail.
>>
>>     
>
> The problem is not in the GotFocus event handler. You must call Edit in the 
> Click event handler, otherwise, when pressing an arrow key, all cells will be 
> assumed as not editable.
>
> Then, you can use Edit() in the GotFocus event handler if you want too. But 
> that is optional.
>
> Regards,
>
>   
I repeat.
I wrote:
> Well, tried several different setups - no problems. Implemented the 
> Save event, and all is work as intended. The edit call can be either 
> in the click event or the save event, or even the GotFocus event: it 
> is exactly the same. I attach the new project, but I think that if the 
> problem shows up somewhere, it is totally unrelated to the place where 
> the edit call is put.
This means that I tried what you told me, and even more.

I can say more. I took the original program, not the short sample I 
brought to the list, and it works as well. The edit call is in three 
places: the gotfocus event, the btInsert_Click and btDelete_Click 
events. The last two serve to insert and delete whole rows of the tableview.

But, this is half the problem, because in this office there is no 
problem (not *that* problem). As I can not prove anything right now, I 
will try once more where the problem appears: in the other office. Then 
I will try again what you say, and I will report results.

Just to keep in the point: what happens if a cell is assumed as not 
editable? Does it happen that all the cells are traversed up to the end 
of the grid? Because is that that is happening to me, and others on this 
list have confirmed; I am not sure we are understanding each other.

Anyway, I will investigate and let you know (if you are interested).

Regards,
Doriano