Re: newbie question concerning drawing/signals



my question is - am i stoopid coding this way? using
configure_event to call the appropriate (re)drawing
routine saves a seperate redraw() routine.

I wouldn't put it so harshly but I might help to use
gtk_widget_queue_draw() instead. i.e. It might change 
something that the signal was emmited after a mainloop
iteration, maybe something has to be done inside
the event loop first ?

my prepare() is a void routine without parameters -
might that be the source of the problem?

is `prepare' a signal handler ? if so; taking
no arguments is no problem (taking arguments
that aren't passed is a problem when you modify
them or the data they would have pointed to).
but a return value is usually expected from
a signal handler (TRUE means to stop signal emmision
in most cases, void functions return random data
on the stack).


did you `gdb' this ? if not ... try to
its amazing what a little stack trace can
do for your debugging.

Cheers,
                -Tristan


zebster wrote:

hi y'all!

i'm developing an application which uses a pixmap
to draw on which is then "copied" to a drawing_area,
as suggested by the tutorial. far as that, everything
works fine.

now, the crucial part is that i have *two* drawing
routines for the job, a scaled and an unscaled one;
i.e. the "scaled" routine calculates all graphical
elements to fit the allocation.width/height while
the "unscaled" one uses fixed sizes for its elements.
my drawing_area is within a scrolled window, so that
scrollbars appear when i'm using "unscaled".
furthermore, i've assembled a menu with a
check_menu_item that is to trigger which of the
drawing routines is used. this of course gives the
need to redraw the pixmap when this button was
activated and that's where my problem is:

when my app starts, it

1) draws all widgets & assigns all handlers
2) calls a prepare() function which calculates
    the needed space (depending on "scaled"/"unscaled"
    and the actual content of the pixmap of course)
    and then gtk_widget_size_requests the drawing_area.
3) on gtk_main, the configure_event handler calls
    the corresponding drawing function, which is
    "unscaled" by default. the graphics appear OK.

now, i hooked that check_menu_item (c_m_i) to another
handler which is to

1) call prepare() again to resize the drawing_area (DA)
    (eg. "unscaled" gives DA dimensions of 2000x3000,
    while the scrolled window is only about 400x400 -
    and those 400x400 is the space to use for the
    "scaled" routine" - gtk_widget_set_size again.)
2) then i emit the configure_event signal on the DA
    to have the appropriate drawing routine do it's
    job: "scaled" on the 1st activation of the c_m_i.
3) return to gtk_main()

when i activate the button, that handler is called, but
unfortunately it segfaults when returning from
prepare(). i have really worked around with this
problem a lot and it seems to me the problem is not
what i'm doing within prepare() but the call
itself. when i tell prepare() to do NOTHING on the
first redraw but to immediately return, the crash
still happens. and if i omit the call on the 1st
redraw, everything runs perfectly (but the c_m_i's
functionality is lost due to the structure of the
code described above).

my question is - am i stoopid coding this way? using
configure_event to call the appropriate (re)drawing
routine saves a seperate redraw() routine.

my prepare() is a void routine without parameters -
might that be the source of the problem?

any suggestions? i'd be really grateful!

zebster

_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]