Tracy Pearson wrote:
Mike,
You could try to clean out the FoxUser for updated < gomonth(date(), -2)
Then I'm looking at the Id field and seeing WINDSNIP. It seems to match up to places I've copied code from recently. Perhaps you can delete those Id's from the table, then pack it.
HTH, Tracy
Tracy,
So far, so good. For anyone else interested...
I first tried putting a CONFIG.FPW file containing the line "resource=off" in the startup folder where VFP9.exe is located. Sure enough, the copy command now worked fine but VFP was brain-dead, not offering any help...like all the settings that I have grown to depend having it remember. Not a good option. So I removed the config.fpw file and everything went back to previous behavior (including the lock up on copy to clipboard.)
Next, on Win 7 Pro, I fired up VFP and used the SYS(2005) function to find the correct, actively-in-use FOXUSER file. It was in the hidden User AppData Roaming folder. c:\users\username\AppData\Roaming\Microsoft\Visual Foxpro 9 I started up VFP, and issued the command "set resource off" from the command line (otherwise the FOXUSER file is locked.) Use/Opened the table use "c:\users\username\AppData\Roaming\Microsoft\Visual Foxpro 9\foxuser.dbf" in 0 exclu Deleted all rows with ID field matching "WINDSNIP" or "SNIPLAST" (there were over 100 out of a total of 300) Packed the table. Exited VFP and restarted VFP.
Now, all my good stuff is remembered between sessions, and when I use the COPY to CLIPBOARD it doesn't lock up.
BTW, before the above 'fix' I had tried clicking the menu copy button on the toolbar, using the right-click copy option, and using CTRL+C on the keyboard....all of them produced the same problem.
Hopefully this will resolve the "COPY OUT TO LUNCH" problem.
Thanks again, Tracy!
Mike Copeland