Re: [gtk-list] Re: Pausing durring widget creation...




Chris Phelps <chicane@reninet.com> writes:

> Havoc Pennington wrote:
> 
> > Chris Phelps <chicane@reninet.com> writes:
> > > Like I said, most of the time, everything works just fine. Unfotunatly,
> > > if i get to clicking the button that causes the switch very quickly, I
> > > start getting errors, and eventually a crash.
> >
> > Maybe if you get a switch and switchback in the same event-processing
> > unit (the queued changes are processed in the same idle handler) a bug
> > in either GTK or your code is triggered.
> >
> > Fixing it would take some investigation into where the crash occurs
> > and why.
> >
> > Havoc
> >
> > --
> > To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
 
> Im sure you are right in this respect...the code must be overlapping
> somewhere, which is what causes the crash (im sure of this because
> of the errors that I get). My question was, is there any way that i
> can make the functions wait untill the mapping of the new widgets is
> done? Notice that I am disableing the button that does the switch
> while the widgets are being moved around...unfortunatly it seems
> that im not waiting long enough. What i need to find is some
> condition that i can wait for before i finish the loop and enable
> the button... Ive tried GTK_IS_WIDGET and GTK_CONSTRUCTED and things
> of that nature...about the best thing so far is a loop that counts
> to 2 million a couple of times :o)

Well, if we knew what was causing the crash, hopefully we
would have fixed it in a past version of GTK+ instead
of adding the ability to work around it.

So, while my guess is that if you connected to "size_allocate"
on one of the widgets and reenabled your button there, 
it might fix the problem, I'd much prefer if you helped
us to track down the problem.

 - What warning messages do you get?

 - Where does the crash occur. (Can you run it in gdb
   and get a backtrace)

 - Can you provide (a preferrably small) test case that
   demonstrates the problem.

Regards,
                                        Owen




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