>>>Al,
>>>
>>>I haven't checked the code above (yet), but I will. I'm wondering if this isn't really a Windows (OS) problem. I know of at least one instance where VFP doesn't perform as it should because of an OS problem. Since this is Win2K, I'll check this on my XP home box.
>>
>>In the earlier thread Jos Pols reported that the problem was present in VFP7 SP1 on XP SP1.
>
>Well, that saves me the trouble.< s >
>
>>Just out of interest, what's the problem you refer to?
>
>Use LOADPICTURE() to get an object reference to a 16x16 16 color icon. Next, save it under a different file name using SAVEPICTURE(). Finally open the new picture using whatever tool suits you. You'll find that the icon has been corrupted. If you compare the file sizes, you'll find that the new one is 128 bytes larger.
>
>In writing my IconMaker program (in the download section) I discovered this, and wrote code to fix it. I confirmed this by calling the underlying API call (OleSavePicture, I think) and getting the exact same results as SAVEPICTURE().

Interesting - you plainly encountered an OS bug. I'm glad you were able to find a workaround, but that might not always be the case.

What interests me with this bug is that I can see 3 possibilities:

1. OS file-system bug
2. Problem with VFP's calling of file-system functions
3. "Problem" with how a VFP file is "opened" "non-exclusively"

If it's #1 it'll probably be a long, hard slog by the OS Group to get it fixed, the file system is a critical part of the OS. If it's #2 it would be within the power of the VFP Team to fix it but would, I suspect, be non-trivial.

#3 is an interesting case. I'd like to find out if file overwriting is possible with shared access from other languages - maybe I'll noodle around and see what I find. Personally I don't believe it should be possible to overwrite a file someone else has opened non-exclusively but maybe I'm wrong. If it is possible, we might just get a PRB article in the MSKB describing the issue, but I believe that leaves a security issue - the file can be changed wholesale, bypassing any database triggers etc. or causing a VFP error or crash if the file was replaced with something that wasn't a table, for example.

I just get the feeling this one could be a can of worms MS or the VFP Team would rather not open <g>