Any good reason why Xojo deletes images?

Can someone explain why it’s necessary for Xojo to delete images from Canvases, ImageViewers etc. when the Picture itself is deleted from a project?
Why can’t it leave the Picture names and just throw an error if they are missing when building the app?

Why I ask this is: I am creating dozens of apps basically with the same structure. Pictures change per app, but not their names in the IDE. Doing so, the source can keep names like ‘imgPlayfield’ or ‘imgBackglass’ consistent in every new model.
I can not choose another file for the Canvas Picture (in good old Real Studio it was possible though…) without deleting it first from the project. At the same moment all references are lost in Canvases etc., while a few secs later I drag the new Picture file to the project, and change it to the exact same name. But now I have to update all Canvases etc. because Xojo erased all references.

So I repeat my question: is there any good reason why Xojo can’t leave the Picture names, and just throw an error if they are missing when building the app?
This would be a great help, without changing a lot to existing behavior.

1 Like

This isnt clear.

I can not choose another file for the Canvas Picture (in good old Real Studio it was possible though…) without deleting it first from the project.

What Xojo version ?
OS ?

How do you choose another image file ?

How do you fill the Canvas ?
In Graphics Event or in Canvas1.Backdrop ?

You wrote: This isn’t clear.
The quoted sentence however is an explanation of my current workflow.

The problem exists only in the IDE with each control that can have a Picture loaded, like a Canvas etc.
It’s not that in a running app suddenly Pictures are deleted.

In the IDE the picture Name in a Canvas is deleted as soon as I delete the Picture from the project. That’s my problem. Why not keep the Name in the Canvas?

I write in Xojo on a Mac. But my issue has nothing to do with that.

Simply because it is NOT just a name. You are selecting an OBJECT in the proyect, if you delete that object, it is the right thing to delete all the properties that point to it.

Well, than you are doing it wrong. If what you want is a “name”, do it in code. On the open event:

Dim picFile As FolderItem = New FolderItem("THE_PICTURE_NAME")
If picFile <> Nil And picFile.Exists Then
  Dim pic As Picture = Picture.Open(picFile)
  myCanvas.Backdrop = pic
End If

You can use build settings to copy the image file to your app folder


If you have the pictures on the IDE as “IMAGE”, you can select it and drag and drop a new picture in the image content to replace the content without having to delete it and replace all the references.

1 Like

It will confuse me if this would be the case.

I still have troubles to understand.

Close your project,
replace the support folder (where your images are stored) with the new folder (who holds the new images with the same names),
load the project

You certainly get the new images.

The solution you suggested is exactly something I would like to avoid.

And the name is just a name. You may see it as an object but I’m sure by just keeping the name in the Name-field it must be possible to link it to the correct object, as soon if it exists again.

Consider this: how would you react if you trashed “existingSound.mp3” from your project, and immediately all references in your code are erased, like:

mySound = existingSound.Clone

After trashing changed to:
mySound = .Clone

I see no difference?

Sorry Emile, I don’t think I can explain it better as I did already. Maybe read it again?

Sorry, completely overlooked your last remark. This is a pretty good solution. Thank you!

I will try another approach.

In an old project, I set a preference for the company logos.

THe user is able to select the image “set” he want based on the file name. The program load the user choice and dsplay it in all windows. Of course, I only had two images, so they were loaded in memory at application run time and the program display these images.
Think Logo_Square and Logo_Rect as Picture are used in the application.
At load time, I load what the user select once in the Preferences, and set them in Logo_Square and Logo_Rect. The program display Logo_Square and Logo_Rect as needed and ignore what is really inside.

Of course, if you have a ton of images, you have to search another way.

May I assume your 10s applications are generated from the same and unique project ?

If so, I imagine 10 folders full of images. At compile time, you have a script who set the master image folder that goes to the generated applcation. Say:
you generate application1, the script set image_folder1 as the master_image.
same goes to other applications (2 to 10).

You only have to change the master folder Reference according to the build application.


Thank you for sharing your thoughts. The first part of your answer would be OK for a project with just a few pictures.

The second part of your answer reflects more my situation. If it interests you:
I have 78 apps with dozens of images. All working, written in Xojo and compiled for both OSX and Windows.
Now porting to iOS. Indeed I work from 1 master project which contains shared items and code. Saved as Xojo-Project (text).
From there it’s 3 steps, where 80% of the work is done in step 1 and 2.

  1. Run an adapted version of the original Desktop app to inventory to a database with used media, dimensions, some properties etc.
  2. Run a special app that uses this database to (re)write parts of master source.
  3. Final step is porting unique methods from the original Desktop app to iOS. This must be done by hand.

iOS in Xojo is very limited. But it looks like I managed to overcome all hurdles as my first app is 95% finished. Next big hurdle is to get it in the AppStore - my first attempt ever (I have published the Desktop versions on my own website).

1 Like

That is why I expanded it a bit (the idea comes to mind while was writing the first part).

Sometimes the difficult comes from the development environment, sometimes it is hard to think differently (find a work-around or a different way to achieve the desired feature).

i use the same solution with drag and drop over the current image.
but your idea to let the object names untouched is also good if xojo would change that. (you have to fill a feature request at feedback tool)

I think drag and drop is a good solution too. And if we leave it like it is make use of existing behavior remains possible as well.

Glad to see that you can use the option of replacing the content of the Image

Lets say that the fact that you can modify the contents inside without removing it is proof that it is not JUST a name.

This is just what I said, use code because code dont change. But the instances of a object does, just like when you change the name of a super or delete one, all of the instances you have, change.

Consider this: you have a IMAGE called XYZ, with hundreds of “instances” in lots of controls. You have to use a encripted control but it already have a object called XYZ, what is more logic? Change the name of your object and let the IDE update all the instances? or Change the name and do ALL the hundreds of name updates by hand?

In your first reply you gave the perfect solution: drag and drop a new picture. Silly I didn’t think of that before I started the discussion. Must be because I used Real Basic/Studio a long time, and this was not possible back then. RB/RS offered the possibility to relink a media file, which was a really good feature. But removed from Xojo.

Things can stay as they are now. Drag/drop works, no need to change behavior.

Of course you’re right that I delete an object if I remove an image from the navigator. But my initial idea was to handle sounds and images equally: if an Image object is removed, dont’t erase the names where they appear, just as when you delete a sound object. Instead, check the reference when building the app and throw only an error if an object with that name no longer exists in the navigator. No extra code as you suggested is needed.
As I said, no need for this, now I know about drag/drop.