STR #722: subversion built fluid 1.1.x (r-4039) loses ability to copy/paste from outside fluid

STR #722

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	2 - Specific to an operating system
Subsystem:	Core Library
Summary:	subversion built fluid 1.1.x (r-4039) loses ability to copy/paste from outside fluid
Version:	1.1-current
Created By:	cable_guy_67
Assigned To:	mike
Fix Version:	1.1-current (SVN: v4387)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	cable_guy_67 07:25 Feb 11, 2005

After a copy paste in a code editor in fluid and closing the code editor fluid no longer can copy text from an external editor. It works when fluid is first opened. Steps to recreate problem: 1. Open a text editor (me, ConTEXT) 2. copy some text 3. open fluid 3a. open a code editor. 3b. CTRL+v the text from external editor. Works. 3c. CTRL+c text from code editor. 3d. CTRL+v to code editor. 3e. close code editor. 4. open code editor. 4a. copy text from external editor. 4b. CTRL+v in code editor. (you should get last code editor copy) Once this occurs it seems that fluid just uses it's own clipboard and does not recognize the system one.

#2	mike 05:24 Feb 14, 2005

Hmm, I wasn't able to reproduce this on Linux (FC3); what OS and compiler are you using?

#3	cable_guy_67 07:07 Feb 14, 2005

I am using Win2K sp4. cygwin 1.5.12 gcc (cygwin special) 3.4.1 (also occured with 3.3.3) Built with : --enable-cygwin --enable-localjpeg --enable-localpng --enable-localzlib fltk-1.1.6/fluid/fluid cygcheck shows reliance on cygwin dll as it should.

#4	mike 13:47 Feb 24, 2005

Will do some more testing with VC++; if that doesn't show the problem, then you are probably seeing a Cygwin bug...

#5	Natevw 15:08 Feb 24, 2005

Here's a similar problem, using input.exe from test directory. (1.1.6 compiled under MinGW, WinXP) Scenario 1: 1.Type/select/copy something from a text box 2.paste it into another program 3.close input.exe >Step 2 succeeds. Scenario 2: 1.Type/select/copy something from a text box 2.close input.exe 3.paste it into another program >Step 3 fails! -nvw

#6	cable_guy_67 15:12 Feb 24, 2005

I just recompiled @4055 with --enable-cygwin and the problem is no longer present. Thank you.

#7	cable_guy_67 18:18 Feb 25, 2005

I must not have followed my own directions to the letter as the copy problem does still exist. As you mention it may be a CygWin issue.

#8	mike 13:06 Mar 25, 2005

I've tested with current 1.1.x code on an XP system, built using VC++.NET, and am unable to duplicate the problem. Can you retest and let me know if the problem persists with Cygwin?

#9	cable_guy_67 14:08 Mar 25, 2005

Ok, I ran it through the paces and it seems to still exist. Maybe this will help. The last cut in fluid survives changing projects. The system clipboard is still operating correctly as I can copy paste between different apps under windows (ConText editor, notepad, bash) but fluid seems to have stopped looking at that info and has resorted to its own internal buffer. If you close fluid and reopen it it then finds the last cut outside fluid and works until you cut/copy - paste close dialog. Actually testing here now shows that a cut only (w/o paste) has the same effect of blocking from the system clipboard.

#10	Portale 23:40 Apr 12, 2005

I sometimes stubled on it in the current fluid. Didn't post an STR# because I thought it could have to do with "ditto cp", the clipboard extension I use. Windows XP Visual Studio 2003 .NET

#11	Natevw 08:54 Apr 16, 2005

This is not just a Fluid issue. After copying text, if any FLTK application (or window??) is closed before the user has pasted it into a *different* application, the buffer is lost. See my post above for how to reproduce. -nvw

#12	matt 00:49 Jun 01, 2005

Fixed in Subversion repository.