>>>>ISTR there was some command that needed to be run when putting image files in reports on the fly, so that the correct image would actually appear for each detail band rather than just the first image loaded being cached and repeated endlessly. Ah - remembered it - CLEAR RESOURCES. If it turns out to be a GDI resource issue you might want to issue that command before/after loading each new image.
>>>
>>>Actually no, I stopped the GDI and am using a simple image control with
>>>
>>>

	lcpic=Filetostr(lcFullp)
>>>	loFrm.img.PictureVal=lcpic
>>>	Release lcpic

>>>
>>>At some point the GDI was too unwieldy, had too many errors with various .png encodings and I abandoned it. Went for the simplest instead.
>>
>>My limited understanding is using images at all in VFP causes them to be cached and to thereby use up GDI resources (don't need to process them via GDI for this to occur (?)).
>>
>>Might be interesting to preface your code above with CLEAR RESOURCES, see if it makes any difference.
>
>Testing as we speak. Just to note that the memory consumption was flipping between 18 and 20 M when it launched. But then I don't remember what it used to be - should perhaps run the old version for a while. Last I remember it displayed about 40000 images before I stopped it, and then the next day the system was unstable. We'll see. I'll run this to a similar number and see what happens.

One W7 laptop with normal HD sometimes becomes unresponsive, showing HD performance ~10MB, which is not really fun.
Rebooting fixes it - guesstimate is that disc interface downscales from SATA to PIO (which I saw a desktop machine do reguöarly under XP, but there the "new" classification stayed over reboot and had to be corrected manually)...