Sanel, sorry about the long delay of my answer.
I still have the problem.
I don't understand what you mean with "it takes so long to show Windows
dialog", and I can't figure out where I could put the Fl::awake()
Regards,
David
> Hi,
>
> Sorry for a bit delay for reply: have you manage to solve this issue?
>
> I'm not running Windows so it is a bit hard to reproduce exact same
> behavior (on linux FLTK will run FLTK builtin dialog). The first question is
> (after I quickly scanned your previous posts) why it take so long to
> show Windows dialog?
>
> Maybe you can try to inject somewhere 'Fl::awake(p)', so app could
> receive events again...
>
> Regards,
> Sanel
>
>
> On Wed, Jan 30, 2013 at 07:05:59AM -0800, David Lopez wrote:
> > Sanel,
> > Thank you for your help but I couldn't solve the problem.
> > When I try to call start_job () from the dedicated worker thread with the
> > invocation properly protected, that is:
> > Fl::lock ();
> > p->start_job (1);
> > Fl::unlock ();
> >
> > Then start_job () blocks forever at line
> > if (PrintDlg (&pd) != 0) {
> > within Fl_System_Printer::start_job ().
> > Removing the lock /unlock I was able to make it work using your second
> > strategy but, it works only sometimes, and sometimes the job appear as
> > "spooling" in the printer queue and the FLTLK app blocks.
> > May be you or someone else could give me some clue...
> > Thank you very much
> > David
> >
> > > Two strategies comes to my mind (maybe others with more experience will
> > > have better ideas):
> > >
> > > * put both start_job()/end_job() in different thread, protect them with
> > > Fl::lock()/Fl::unlock(), and after it gets completed, call
> > > Fl::awake(NULL) to notify the main thread
> > >
> > > * the second one is to put start_job() (with lock/unlock) protection in
> > > separate thread and when it gets completed, let it call
> > > Fl::awake(cleanup_cb), where 'cleanup_cb' is your callback (in the main
> > > thread) with end_job() call; something like:
> > >
> > > void cleanup_cb(void *o) {
> > > Fl_Printer *p = (Fl_Printer*)o;
> > > p->end_job();
> > > }
> > >
> > > void* thread_func(void *o) {
> > > Fl_Printer *p = (Fl_Printer*)o;
> > > p->start_job();
> > > Fl::awake(cleanup_cb, p);
> > > }
> > >
> > > /* rest of the code */
> > >
> > > Sanel
> > >
> > > On 01/29/2013 02:10 PM, David Lopez wrote:
> > > > Thanks, but then what should I do to avoid the blocking?
> > > >
> > > >> Have you tried to use locking described at:
> > > >> http://www.fltk.org/doc-1.3/advanced.html?
> > > >>
> > > >> AFAIK, end_job() will access FLTK drawing facility again, which is
> > > >> probably the cause why you are getting blocked UI again.
> > > >>
> > > >> Sanel
> > > >>
> > > >> On 01/28/2013 07:51 PM, David Lopez wrote:
> > > >>> Hi everybody,
> > > >>> I have a multi-thread FLTK 1.3 application on Win XP. The problem is
> > > >>> that when the application tries to print (using Fl_Printer) all
> > > >>> threads get blocked while the Windows printer selection dialog is
> > > >>> open. In that case the method Fl_Printer::start_job() was called from
> > > >>> a callback (from main thread).
> > > >>> So to prevent the application from blocking I decided to create a
> > > >>> working thread that calls Fl_Printer::start_job() â¦
> > > >>> Fl_Printer::end_job().
> > > >>> With this change, the application doesnât block itself while the
> > > >>> dialog is open but blocks forever after printing.
> > > >>> I suspect that Iâm doing something wrong since I know that no
> > > >>> window should be open or close from threads other than the main one,
> > > >>> but I don´t know what would be the right way to implement this.
> > > >>> Thank you very much.
> > > >>> David
> > > >>>
> > > >>
> > > >
> > >
> >
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
