The evaluate step only is necessary as MarKs code sets ImageFileName to a field name, instead of some field value. And there's a good reason for this, as you want each row to display its image, not just one for all rows. EVALUATE(fieldname) results in the field value, the filename.
>Can it reduce the image size?
In comparison with storing images in General fields, the image files are smaller most of the time, much smaller. Cases where this difference is not big are unimportant cases of very small images.
When I used dmusicants method of pasting an image via clipboard I got from snipping tool, vs saving the snipped image to a file, the file size was 5KB, vs the FPT General field size being 175KB, which is becuase it's the uncompressed BMP image in the clipboard. Just one example, you can experiment yourself with how large General field values are, just look at the fpt file size growth per image you paste.
General fields are okay in dmusicants situation of using legacy code he's not maintaining when it is what serves as storing them for him. It's not meaning, there's no alternative. Even @ SAY can display images from files, you're not depending on Generalfields storing and displaying images. I don't know what hinders him from creating a simple char field for an image name and make use of an image control instead. And as he's using something in the VFP9 IDE you could start make use of anything of VFP, like the image control with its Picture property, where you only need to set a filename of an image file to display it. So data would only need to have the filename, as in MarKs sample code.
MarKs code is also already addressing an advanced feature of displaying images in a grid, using a tricky way with the backstyle property, which is accessed by VFP when it paints a grid, so you can define an access method for it that then can set the Picture and you get individual pictures in the grid row. And that's where the magic of this is, not in EVALUATE, in an access method and backstyle and the insider knowledge the backstyle property is accessed by VFP whan painting a grid. The overall construct is a hack to overcome the problem the image control has no controlsource, so MarK did define a controlsourcereplacement with the ImageFilename property he defined And letting this be used like a controlsource via the backstyle mechanism. Backstyle itself is not about the image, but the backstyle. It just matters, that its accessed and thus triggers the backstyle_acess method code.
You usally would only display a single image outside of a grid control, say you have some textboxes about an employee displaying name, etc. and then one image control you set to display a photo. That's just needing an image control created on the _screen, for example, or on any form, with its Picture set to the filename. No need for evaluate, backstyle and a backstyle_access method in that simpler case. From that point of view MarKs sample suggests that working with images is hard to do. It's not at all. In the simplest case you just set the picture property interactively picking a picture file from a file open dialog (which could offer the preview pane to make it a visual selection), when you build the image file will also be embedded into the EXE and the distribution of that wouldn't require providing the images along with the EXE. That's for the simple constant image use case. If you set the picture via code from a char field storing file names, the files will also be necessary later at runtime and after builindg an EXE. But that's not a big deal, is it? Just store all your application images related to the data in one directory and it's all well organized.
What are Gen fields really good for? In reports. You don't have many report controls, there's literally just one for textual, numeric or dates/datetimes of any kind, admittedly with nice features of automatic growth of size, alternatively graceful cut off of display values with "..." and more things, all valuable in reports, but nothing to display an image or RTF text or anything else advanced, but there's the oleboundcontrols within report controls, too. And it works quite like the oleboundcontrol usable on forms, a container for an OLE object, and that's what a general field stores, so general fields are the natural controlsource of an oleboundcontrol. But you use them for that report run and not for permanent storage, it alwas bloats in comparison with the origin of the ole object. Besides the bloat you only store the object, to make use of it, display, work with it, you introduce a dependency to whatever ole host class is necessary to run. I guess it's possible to store an Excel.Worksheet in a Gen field, but you might not only need an Excel version on a computer to show this Gen field in an olebound control, you'd perhaps need the exact version, while a xls or xlsx file is usable in multiple excel versions and automating Excel gives you more options than the OleBound concept.
