On 5 June 2012 12:50, Ferdinand Ramirez <ramirez.ferdin...@yahoo.com> wrote:
> --- On Tue, 6/5/12, James Tappin <jtap...@gmail.com> wrote:
>
> > I think the solution is to place the treeview in a gtk_scrolled_window
> > rather than using an hbox and an explicit scrollbar.
>
> The reason for trying out with an explicit hbox is that the column headers
> scroll out of view with a gtk_scrolled_window.
>
I'm puzzled as it doesn't do that in my RPN calculator stack and registers
display. This uses a list model (i.e. no sub-rows). Here are the key bits
of code (in Fortran 2003 -- I'm not a C programmer).
The list creator function:
function hl_gtk_listn_new(scroll, ncols, types, changed, data, multiple,&
& width, titles, height, swidth, align, ixpad, iypad, sensitive, &
& tooltip, sortable, editable, colnos, edited, data_edited)
result(list)
type(c_ptr) :: list
type(c_ptr), intent(out) :: scroll
integer(kind=c_int), intent(in), optional :: ncols
integer(kind=type_kind), dimension(:), intent(in), optional :: types
.
.
.
! Create the storage model
model = gtk_list_store_newv(ncols_all, c_loc(types_all))
! Create the list in the scroll box
scroll = gtk_scrolled_window_new(C_NULL_PTR, C_NULL_PTR)
call gtk_scrolled_window_set_policy(scroll, GTK_POLICY_AUTOMATIC, &
& GTK_POLICY_AUTOMATIC)
list = gtk_tree_view_new_with_model(model)
call gtk_container_add(scroll, list)
.
.
.
And in the calculator itself:
! Registers.
jbase = hl_gtk_box_new()
idx = hl_gtk_notebook_add_page(mstabs, jbase, &
& label="Registers"//c_null_char)
fmemory = hl_gtk_listn_new(smemory, changed=c_funloc(memsel), &
& height=300, titles= (/ "Index"//c_null_char, "Value"//c_null_char
/), &
& types = (/ g_type_int, g_type_double /))
call hl_gtk_listn_set_cell_data_func(fmemory, memcol, &
& func=c_funloc(show_list), data=c_loc(memcol))
call hl_gtk_box_pack(jbase, smemory)
I hope that this will at least give some clues as to how the bits fit
together.
P.S. hl_gtk_* routines are Fortran routines that bundle settings together
and use Fortran's optional argument system to hide much of the complexity
of the raw gtk_* calls.
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
