Good evening.
I notice on my current builds for Windows after upgrading Xojo, all the imported images in the application are exported to a Resources folder. I have to include this in Advanced Installer when generating the MSI. Is there a way to embed the images with the build so that they are not accessible to the user as it used to be?
Thank you.
SeePicture2Text in https://forum.xojo.com/25414-iosimage-from-sqlite-text-field/0 to encodeBase64 inside a constant, and use Picture.FromData to extract and reconvert it when needed.
[quote=233018:@Dennis Lowe]Good evening.
I notice on my current builds for Windows after upgrading Xojo, all the imported images in the application are exported to a Resources folder. I have to include this in Advanced Installer when generating the MSI. Is there a way to embed the images with the build so that they are not accessible to the user as it used to be?
Thank you.[/quote]
For what it’s worth, in advanced installer, you can just tell it to sync the Resources dir and it’ll copy everything every time you build.
Many thanks for the advice. I have about 250 small image files and have tried converting to Base64 and storing them as constants but that is difficult to maintain and goes against the whole idea of keeping resources separate. After talking to Xojo, who suggested a DB file, I have tried that with a management class that looks after updates etc. That seems to work well. The images are loaded into properties when the app starts and Advanced Installer automatically installs the file in the correct folder on the target machine.
If ultimately the pictures are copied into the Resources folder anyway, pardon me, but I fail to see the point in going through encodeBase64 and a database, plus the installer. Any moderately competent PC user will find them there.
What you could do if you want to prevent unauthorized users to get to the pictures, is to encrypt the files, drag them into the project, and decrypt them for use. So Xojo will find its files, they will be present in the Resource folder but inaccessible to prying eyes.
They’re in the db that gets installed
You could really have a SQLite database file. maybe even encrypted.
Put the pictures there as BLOB in a table, so you can load them dynamically at runtime.
And Base64 is not needed if you use BLOB field. Size of database should be only size of images with maybe a 1% addition for the management of the database.
Sorry, I didn’t make myself clear. I have put the images into an encrypted SQLite DB file as type Picture not Base64. The Base64 experiment was to have embedded strings but that was too clumsy and was discarded. The DB is loaded at run time.
OK. That works.
Think for commercial desktop applications with some branding graphics in it, this is preferable above having these stored just as files. I had one trying tho replace the graphics so in next version I’ve put MD5 check on every file.
For another small Windows desktop project I used BoxedApp to have everything packed in just one 32 bit exe.
Now I am thinking about building a small tool for personal use to have graphics easily packed in blobs.
A possible solution would be to use an encrypted Virtual Volume as container.
Can you explain just a bit more Michel ?
Virtual volumes are like bundles on the Mac but cross platform. See http://documentation.xojo.com/index.php/VirtualVolume .
Oops… never realized Xojo has made virual volumes so simple.
Thanks for the hint.
I would still recommend a SQLite database. Virtual volumes in Xojo are slow and not a public format.
With encrypted SQLite database you can read them with other tools.
Xojo uses Dr. Hipp. Support by other tools seems to be rare.
Does the MBS database-pugin support other algorithms ?
MBS Plugin uses the Hipp Encryption.
But also works with other encryptions if you provide the right sqlite library.
e.g. SQLCipher.
See here:
https://www.mbsplugins.de/archive/2015-01-03/Use_SQLCipher_with_MBS_SQL_Plu