png file not displaying in image control

[ravicoder]

Hi all

I have a form with an image control on it with the picture property set to a png image in the picture property ... the image is available in the defined path
the issue is the image does not display when the form runs. I have tried converting the image to .jpg and .bmp but still no go
Attached is the image. can anyone suggest or advise what is wrong? i have tried different parameters of the stretch property but still no results

 

[Shane_SixOne]

Try setting the image file name and full path in form load event.
Is the picture box visible on the form?

 

[dylim]

Hi ravicoder,

Is the image control Visible set to True? Or maybe is the Image control "on top" or "under" some other control?

 

[EinTerraner]

the Image control "on top" or "under" some other control

also check the "Anchor"-property

Just create a plain form with the image in it to check your image

 

[Chriss Miller]

You put an image control on the form, you open the property window, double click on the picture property, get a file open dialog for picking the image file, pick the PNG and it displays immediately already at design time.

Then you build an EXE the image will be included into the EXE and will display without it being in the path and as a separate file. It's as simple as that and your image has nothing that doesn't work in VFP9.

VFP8 or earlier didn't support the PNG format, but JPG or BMP. If you really convert it to that format and not just change the file extension, then the image will work in exactly the same way in any VFP version.

It's really astonishing how you can fail with this at all, I have no idea how to fail. Oh, one idea: If you only specify the name without path to it, then that could fail, but you talk about the defined path.

What the image control will not do is you specify beautysalon-13.png and want VFP, the runtime, the form, the image control - want it to look in all your defined paths in SET PATH. No, that doesn't work. But then before you even can save the scx or vcx this will error with "File .... does not exist". Maybe not, if you haven't configured compile before saving in options. Then that's what you should do right away and make it persistent to be warned as early as possible about such errors.

So, in essence for the direct problem: You simply pick the picture in a file open dialog from the property window for the picture property of the image control and be done with it.

 

[ravicoder]

Hi all

there is a defined path in the config.fpw file and all other images are displaying except the one mentioned above
I then added as so:
imgpath = fullpath(curdir()) + 'images\<filename>
thisform.image1.picture = imgpath
Its displaying now

the path images is defined in the config.fpw. Don't understand why some images are displaying and some are not

I will now in the startup file of my application include as
set path to fullpath(curdir()) + 'images\' additive. That I think will take care of things

Thanks for all the advice and suggestions
Regards
Ravi

 

[Paul Gibson]

I know you've said it now works but when I see code that is directly referencing paths then I wonder if it is necessary. I try to stay away from referencing paths as much as possible and only go there when it really is unavoidable. That can depend on what kind of resource you are referencing.

When it comes to images in applications I generally put them into one of two categories and for some applications/developers it might be that only one category applies:

1. Static/known images - i.e. images that are known at develop-time and compile-time and likely will never change unless you rebrand your application or give it a visual refresh
2. Variable/external/unknown images - i.e. if your application manages external images in any way, having a robust solution to ensure the images/locations are correctly recorded, references are consistent and therefore never lost

As said, if you have an application that doesn't manage external images at all, you may only have a single category, that being #1. If so, that is great because managing images in category #1 is pretty much as simple as you get. As others have said.

Category #1 is generally for your company logo, your application logo, maybe logos of a customer or third-party, any images/icons that your application displays on command buttons, menu bar, popup menus, the exe icon etc. These are KNOWN images/files that sit on your dev machine(s), your network, whatever your development environment is. The key thing being that the image is in a known location that is the same for all developers (if you have multiple developers). So let's say you have a Help -> About screen and you put your company logo and your application logo on that screen with other information. You probably have a form and you drop an image control on it and you set the image location in the picture property of the image control. Let's say your development start folder is c:\projects\MyApplication and all your images are in the sub-folder called images. On your company logo image control your picture property may simply say... c:\projects\MyApplication\images\CompanyLogo.png, that's it. In fact, in the table for the form/class, the property might only be stored as "images\CompanyLogo.png" or whatever referential path works. Even if you don't manually open your project and include that image file, as long as you see it in design, as long as the project can see it at compile-time the image file will automatically be pulled into the project if it is not already there and then when you application is executed, it'll have the image file embedded within itself so it'll have no issues displaying the image. It really is WYSIWYG. In summary, for category #1 images, you can set things at design time and it's extremely simple. I can think of maybe one complication but I'll address that after I mention category #2

Category #2 is for images that you don't know at design/compile time. I'll give an example of a piece of auction software, where the assets are items for sale. The developer doesn't know what the assets are going to be, the user wants to list the assets for sale with images. As the developer you'd come up with a robust way that is appropriate for your application and database for how to reference the images. An important aside here would be that it is generally not a good idea to store images in a database table as the tables can get extremely large extremely quickly, so you'd probably store references to the images or have some reliable rules that the application can replay to ensure it can see the images. In that auction example, the users may store all the images for an asset into a folder that means something to the application, for that asset. In this case the applications ability to reference, access, display those images are based on reliable rules. Some applications may never have need for category #2

When thinking of potential complications with the simple category #1, the only thing I could really think of is if you have any locations in your application where it needs to decide at runtime whether to show one of a number of images, so you decide to have code to pick the appropriate image at runtime. In that case, the route I would generally take is to write the code to only reference the different image files by the filename, so let's say GoOkay.png, GoWarning.png, GoError.png. Write the code only referencing the image by filename and then manually ensure that those known images are correctly referenced in the project so that all three are already in the project, therefore embedded in the exe/app so can be pulled out by Fox when required. In short, if it's a known image file and that image file is in the project, you can reference it by filename only and not have to concern yourself with paths at all. If you reference a filename and a file of that name is in the exe/app then Fox will be able to use it.

The only additional complication there is if it's an unknown image that needs to be determined at runtime. Then it all comes down to your rules for category #2

One last thing, this may not apply to you, but I find this is true for me... even though all my applications known images are in an images sub-folder I NEVER write a single line of code to reference those images that has the path "images", CURDIR(), FULLPATH(), I just never find it necessary. It comes back to the simple Fox rule that if it's a known image filename and that image is in the project, therefore embedded in the exe/app then Fox will be able to use it at runtime.

This corresponds in with another rule I try to obey as much as possible and that is for all resources, not just image files, try to stay away from writing code that references paths as much as possible. If a path isn't necessary then do not write the path into THE CODE. I highlight the CODE bit because if you look at an image control or a command button and it's picture property, it might read as the whole path, I tolerate that as it's fine for known images but also if you look at the form/class table then more often that not the picture property is actually stored using a referential path, if possible, not the full path, Fox knows what is best for itself and having the full path is usually unnecessary.

 

[Chriss Miller]

As said, SET PATH simply doesn't work in conjunction with the Picture property, I just tried it once more and always get the same error.

When using relative paths you will need to ensure it's relative to what you also assume it's relative to. There are always two things relative paths can be based on: The location of a code file and finally, the location of the exe or it can be used relative to the current directory, which isn't necessarily the same as the code file location, even if you currently edit a file or have it open in a designer. And SET PATH also and especially when using it with ADDITIVE to have multiple paths to search along doesn't make VFP or build look into all paths for all types of files. Regarding images it can depend on whether an image is in the currently active project or not, too, which by the way could even be in a third path, neither current/default nor CSX/VCX path.

Then there's the memory cache in play, where VFP may find things, too. So some things sometimes or even very often work, but not always as you assume.

When you want consistent results use absolute paths to images. If you need to specify images data driven, you can store relative paths, as long as you know relative to what, but then - again - for consistent results set the picture property to the absolute path based on the relative path, there's SYS(2014) to help with combining base and relative paths, especially if the relative path is making use of ..\, not just .\