Wrong cursor position after changing List data

[mande]

Hi,

I come back with a cosmetic issue.

It is related with List class. After changing data, cursor position is wrongly calculated and displayed so i must call .set_form_row method after .list( new data) to properly display it.

This happens when previously @current_index value was greater than 0.

Thanks

[rkumar]

Will look into this. I dislike a user program having to call init_vars or set_form_row. These were supposed to be private. I am now trying to use textpad for a list also. However, I think even with Textpad, if i change the content, then the cursor is seen in same place until I press a key.

I will look into this today. Thanks.

[mande]

Hi,

To make things easier here you have a chunk of code:

encoding: utf-8

require 'rbcurse' require 'rbcurse/core/widgets/rlist'

begin

$log = Logger.new((File.join(ENV["LOGDIR"] || "./" ,"rbc13.log")))
$log.level = Logger::ERROR
VER::start_ncurses
@window = VER::Window.root_window
@form = Form.new @window

@list = List.new @form do
    name "list"
    title "Press any key"
    width 40
    height 20
    list [  "ONE", "TWO", "THREE", "FOUR", "FIVE"]
end

@list.current_index = @list.list.length - 1

@form.repaint
@window.getchar
@list.list( ["ONE", "TWO", "THREE"])
@form.repaint
@window.getchar 

ensure VER::stop_ncurses end

Thanks,

[rkumar]

Thanks for the snippet. There is a method called list_data_changed which was called by caller programs, or by events, from what i remember. But then I simplified the list along with other widgets and removed stuff. That method calls set_form_row, however it checks for row_count == 0 so it is useless for this case.

Perhaps, I should removed that check, so that callers can call that rather than directly call set_form_row.

I was checking older code of rlist (now named rlistbox.rb in rbcurse-extras):

  @list.bind(:LIST_DATA_EVENT) { |e| list_data_changed() }  

The above line is set whenever the list is set. This will result in the method being called whenever data is changed.

However, in that, set_form_row is commented off for the reason that if the user is editing another widget and based on that, the list data is changed, then if we call set_form_row the cursor will be shown in the list, instead of the field. e.g. if you are typing a filename and the list is showing matching files as you type.

In conclusion, set_form_row may have to be called based on the situation, and perhaps I cannot always call that when the list data is changed.

[mande]

Ok, i see, anyway this is a minor question and easily solved, but should not be related, cursor position, to the active widget ?, that is the widget focused should paint the cursor according to their coordinates.

[rkumar]

I think what you are saying is that only the active widget should be able to paint the cursor. It should not accidentally happen when another widget is being updated.

I will have to check this out more carefully. Maybe a check can be placed whenever a widget calls set_form_row.

On Fri, Apr 19, 2013 at 1:24 PM, mande notifications@github.com wrote:

Ok, i see, anyway this is a minor question and easily solved, but should not be related, cursor position, to the active widget ?, that is the widget focused should paint the cursor according to their coordinates.

— Reply to this email directly or view it on GitHubhttps://github.com/rkumar/rbcurse/issues/16#issuecomment-16640405 .

[mande]

Yes that is my intention.

Thanks