Re: About the menu's toprow and menu's curitem

[Thomas Dickey]

On Mon, Mar 03, 2014 at 07:14:21PM +0800, 王德亮 wrote:
> But, when I change the current items in line 77, the error occur:
>  ret = set_current_item(my_menu, my_items[8]);
> recomplie and run it, the result is below:
> now, ether the menu->toprow or the menu->curitem is not match with what we 
> see in the subwin.
> After reading the sources, I find that, ether the function [set_current_item] 
> or [set_top_row] can do what I wanted, so I change the source below:
>  76 /* Added by address@hidden [2014-03-03 18:31:12] */
>  77     ret = set_current_item(my_menu, my_items[8]);
>  78     cur_idx = item_index(current_item(my_menu));
>  79     count = item_count(my_menu);
>  80     if (cur_idx >= count - my_menu->arows) {
>  81         /* It's ugly that we use the menu's internal member 
> [menu->toprow],
>  82          * because ether 'set_current_item' or 'set_top_row' will modify
>  83          * both of the member [menu->toprow] and [menu->curitem], and the 
>  84          * logic between the two member is what we wanted */
>  85         my_menu->toprow = count - my_menu->arows;
>  86     }
> then, the result is what I wanted:
> Is there other method can do what I wanted? or is it a bug? Looking forward 
> to your reply, thanks!

There is no standard way to do this:  combining the two was not in the
SVr4 menu library.  ncurses actually has a private function
_nc_New_TopRow_and_CurrentItem which appears to do this (it is of course
not recommended to use private functions - doing that is always at your
own risk...).

I agree that using struct-members is not as elegant as using functions. 
However, even NetBSD hasn't made their menu/form structs opaque (as they
did for WINDOW).  A quick look at their headers indicates that a similar
workaround would be _needed_ to make this port to that implementation
also (no corresponding set-function exists).  Because the structs are not
opaque, it would be _possible_ to do the same thing with NetBSD curses.

In considering whether to add an extension, I generally consider
whether it is possible to do a given function using the library as
it is - not whether a particular set of features could be recombined
in a nicer way.  Along those lines, NetBSD's set_field_printf() is
not a necessary extension, because it could be implemented outside
the library.  (I might add it to ncurses as a convenience feature if
the function were widely used - but it is not).

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature