Again, that Fl_Window::make_current() gets called when you destroy
your window suggests that FLTK windows are not handled correctly.
> Hello,
>
> Thank you for your quick answer. I tried your suggestion, however, from my
> understanding of this function, it only applies within the context of a
> thread, which is actually not the case in which my program crashes. Alas, it
> did not solve any of my problems :-(
>
> Basically, what I'm trying to do is to implement a new programming language,
> which uses FLTK as its main windows interfacing. I have implemented a
> complete IDE in COCOA to run and debug any programs of that language, which
> implies some level of reentrance. Hence, the interaction between the IDE
> windows and the ones created through FLTK. Basically, what I have discovered,
> is that the problems occur if I run first a FLTK window, and then I load
> another window through a loadNib within the IDE. However, IDE windows loaded
> before any FLTK calls are ok.
>
> I do not understand why it provokes any errors, but it seems that Cocoa
> windows created after any FLTK windows,interferes with the way FLTK windows
> are managed... I guess some of the higher level COCOA methods invoked from
> FLTK find themselves dealing with windows from the IDE, hence the issues.
>
>
>
> > Any info about the suggestion previously made to use the
> > Fl::delete_widget(Fl_Widget*) function ?
> >
> > Another suggestion would be to replace
> > [[i->xid contentView] lockFocus];
> > by
> > if ( ! [[i->xid contentView] lockFocusIfCanDraw] ) return;
> >
> >
> > > Hello,
> > >
> > > I have been using FLTK for quite a while now (about a year), and with
> > > some success. I use the 1.3.2 version, which I have integrated in
> > > projects on Windows, Mac OS and Linux.
> > >
> > > However, I have a real problem on Mac OS, a crash which happens in
> > > certain cases when I mix a (non FLTK) modal window and an FLTK window.
> > > When I destroy the FLTK window, I have a crash...
> > >
> > > I traced the error back to Fl::make_current in Fl_cocoa.mm, with a
> > > lockFocus, which is where the bug is perpetrated...
> > >
> > > For the moment, the only way for me to bypass this problem is to add a
> > > @try/@catch around the lockFocus and I destroy the window...
> > >
> > > void Fl_Window::make_current() {
> > > ...
> > > NSView *current_focus = [NSView focusView];
> > > // sometimes current_focus is set to a non-FLTK view: don't touch that
> > > @try {
> > > if ( [current_focus isKindOfClass:[FLView class]] )
> > > [current_focus unlockFocus];
> > > [[i->xid contentView] lockFocus]; <-- CRASH HERE
> > > }
> > > @catch(NSException* e) {
> > > delete this; <-- VERY HORRIBLE, but it does not seem to matter
> > > return;
> > > }
> > >
> > >
> > > It works, but I do not feel very comfortable to modify the code of a
> > > library which I use on many platform.
> > >
> > > Do you have any idea how I could bypass this error in a more acceptable
> > > way?
> > >
> > > Thank you in advance...
> > >
> >
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
