I’ve had major issues in the past with SpecialFolder.Downloads being non-existent for OneDrive users, FWIW.
I keep getting reports that saving or loading files fail when the target is a OneDrive synched area.
I’m considering doublebuffering every load and save if this goes on… making a file in temp (even though sometimes THAT is invalid too!) , then deleting the target and replacing with the new file.
From what I understand, this process may not be macOS friendly. Sam had a name for this type of save procedure, but I do not recall what it was. I only mention it because I know your app is cross platform.
Yeah, theres some funky Mac file-switching API call.
Not really the same as I understand it.
The real problem with this technique is that you can create or delete a file, and the OS doesn’t wake up to the fact for a second or two.
Atomic file saving. There are APIs on the mac to create the “temporary” file in a location that works for sandbox apps. Another for replacing the original file.
So called because either the whole file is saved or the original still exists.
Bad idea to do it manually for files that OSX maintains a file history for, apparently:
Atomic save’s process of deleting the original file and renaming the .tmp file to the original file name completely wiped out all previous versions of the documents I was editing.
Doesn’t apply for my use, but well worth warning people.
Back to the original query…
More testing shows me this:
Running a 32 bit app compiled with Xojo 2015 works on 32bit and 64bit machines.
Adding MBS plugins dated after 2016, the 32bit Xojo app doesnt work on 64 bit Windows, because the 32bit VC++ runtimes are missing.
Placing the runtimes in with the Xojo app does not solve the issue, because it is the MBS DLLs that need these runtimes, and they are not on the path.
Placing the runtime DLLs in with the MBS DLLs doesn’t work either.
So my final solution was to bundle and run the 32bit runtime installer inside my installer, because that installs these properly into the right location, with version checking too.
Supplying the runtime files with the executable does work as we do it using a 32 bit Xojo 2014 Windows app that uses MBS. However, if you are using recent MBS plugins, the runtime files that Xojo provides don’t support the VC Runtime version that MBS requires.
Yes. I think thats what I said… your 2014 app and 2014 era MBS plugins dont need the runtimes.
Xojo or MBS after 2016 will need them.
But MBS cannot find them if you just put them next to the EXE
I meant that bundling the individual runtime files does work. As long as you have the correct files you don’t need to include the installer.
More support woes.
On my machines, running the installer twice gives me the option to repair or uninstall.
On one of my testers machines, they get this:
So rather than reduce support calls, this is likely to increase them by a lot.
Anyone know how to test whether it needs installing (using Inno)
Does Christian include or list the dependencies his plugins uses?
You could try http://dependencywalker.com/ on your app then include those?
Filename: “{app}\vc_redist.x86.exe”; Description: “Microsoft Support Files”; Parameters: " /install /quiet /norestart"
At least I got it to be quiet… 