Re: newbie question concerning drawing/signals
- From: Tristan Van Berkom <vantr touchtunes com>
- To: zebster <zebster spr at>
- Cc: gtk-list gnome org, gtk-app-devel-list gnome org
- Subject: Re: newbie question concerning drawing/signals
- Date: Thu, 19 Dec 2002 14:00:51 -0500
> 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]