I'm working on using the win32 print dialog (PrintDlgEx) behind the highlevel printing API I've been posting about. I've stumbled on an issue though. PrintDlgEx is a blocking call, so if you call it the mainloop won't execute until it returns. This means your other windows won't even repaint.
One obvious solution is to create a thread and run PrintDlgEx from that thread. We can't in general use glib threads, as the application might not have called g_threads_init(), and even less likely gdk_threads_init(). (Not to mention that gtk-win32 has generic threading issues.) However, if we create the thread using the native win32 thread APIs and make sure we isolate that thread from any gdk/gtk code we should be fine. Of course, if we use a solution like that we can never ever mix Gtk+ widgets with the print dialog, so any extensibility of the print dialog has to be done some other way. I talked a bit to tor, and he said John Ehresman was using the native commdlg file selection dialog in his app, and he might be using some other trick to solve the blocking issue. John? And tricks up your sleeve? For now i'll use the native threading approach to try to get something running. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [EMAIL PROTECTED] [EMAIL PROTECTED] He's an oversexed amnesiac shaman who hides his scarred face behind a mask. She's a brilliant bisexual mermaid with the power to bend men's minds. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list