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]