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.
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
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.
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.
Run an adapted version of the original Desktop app to inventory to a database with used media, dimensions, some properties etc.
Run a special app that uses this database to (re)write parts of master source.
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).
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)
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.