DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current I looked to the older FLTK code, and the one thing that seemed different is that fl_i_own_selection[clipboard] was being set to 1, whether OpenClipboard() worked or not. In the new FLTK code, fl_i_own_selection[clipboard] is set to zero if OpenClipboard() works (which it does in my case). So I found I could 'fix' the problem by setting it to 1 in both cases, eg. this one line change to Fl::copy() in Fl_win32.cxx: ---- if (clipboard) { // set up for "delayed rendering": if (OpenClipboard(fl_xid(Fl::first_window()))) { // if the system clipboard works, use it EmptyClipboard(); SetClipboardData(CF_TEXT, NULL); CloseClipboard(); - fl_i_own_selection[clipboard] = 0; + fl_i_own_selection[clipboard] = 1; } else { // only if it fails, instruct paste() to use the internal buffers fl_i_own_selection[clipboard] = 1; } ---- This restores the old behavior, but seems wrong the way I read the intention of the code. But given the above described behavior of the Microsoft clipboard stuff failing without error codes, it seems like something might be wrong in fltk's handling of the MS clipboard functions for 'delayed rendering'. HTH. Link: http://www.fltk.org/str.php?L2104 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
