I've seen today, that I've chosen the wrong group. Should I ask in fltk.general instead? Sorry for that...
On Thu, 03 May 2007 17:10:45 -0400 Greg Ercolano <[EMAIL PROTECTED]> wrote: > I would think you'd want to lock to avoid a situation where both > FLTK and your BitBlt thread contend for accessing the same window. So I must use lock even if the thread don't use fltk to draw to the window!? Is that right? > > Which parts to I have to overwrite if I subclass Fl_Box? There is > > nothing to draw, because the thread must draw it asynchronous. Should > > I overwrite draw and call the parents draw only if the "video thread" > > is not running? > > Just curious; if there's nothing to draw(), then maybe it makes > sense to just use regular Windows code to open/maintain just your > video window? First of all, I've never subclassed a fltk widget before. So please excuse my stupid questions. ;-) Maybe my question was not that clear, sorry. I need to subclass a Fl_Box to get a HWND to draw to. My question is, how to handle the call to draw if the application window have to redraw (for example if it was previuosly covered by something). If no live video is enabled, the thread is not running and so it doesn't draw into that HWND. In this case, the "subclassed box" has to (re)draw an "empty box" (by calling draw of the superclass?). In the case the thread is running, the redraw is done automatically with the next frame. As I mentioned before, I've never subclasses a widget before, so I have no experience. > If you open your own window, I'm not sure how this impacts > the need to handle thread locking. I don't want to have a separate window. The video widget must be part of the mainwindow. So subclassing is the only way I think. -- Email: Joerg Desch <jd DOT vvd AT web DOT de> _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
