I have a client xplatform Mac/Win project I added Kaju to.
After fixing the different behaviour of internal windows where Windows always wanted to bring a hidden window to the front, everything looked fine. Updates are found, and the Mac client updates and restarts perfectly.
Not so on Windows where after a fresh installation of the app, where everything looks fine only at first glance. The update is found, unzipped and processed, but the app does not restart (it’s a 32 bit app still because of some of the external libraries I am using)
When I restart the app manually, update checker never returns. There is no timeout and no sign of error. What’s more: the version number is still the original build, not the updated.
If I don’t update, close the app and restart it, the same: No result of UpdateChecker anymore.
Any ideas what might be the cause?
After some investigations and customer feedback it turns out the new files are copied and decompressed but will stay in a subfolder containing the app name and “- decompressed”.
I had forgotten to set UpdateInitiater to Nil in app.Close, but that still does not help.
What might make the copy action fail? I tried running the app with admin privileges too, but obviously that’s not the reason.
Did it used to work, but no longer does? Or has it never worked for this app?
I guess it never worked on Windows. Customer forgot to check that version, so there is some chance a working state has been missed, but rather a low one.
Maybe something in the name of the file? It’s hard to say without seeing your source code.
What part of code would you have to see? It’s a pretty big project with a lot of depencies and console helpers.
This is what the update folder looks like after a failed update.
I struggled with Windows and the folder permissions inside Program Files, so I now simply pop up a dialog telling the user an upgrade is available and a button that takes them them there in the browser. Mac, it works a treat. Windows just seems to get harder and harder!
I wonder if spaces in the app name are causing issues. I don’t recall if I tested that.
Also, it should have created a log file that might provide more insight. That would appear next to the existing executable.
How would that be named? But it does not seem to exist:
Could you please tell me where the logging code is located? Maybe I can trace why it fails; but I did not find the right place to debug.
There would be an Update Log.txt file next to the original executable. If it isn’t there, the script is likely not running.
Your best course would be to create a version with debug code in it, both in the app and the platform script to see what might be going on.
Initiator.ReplacementAppFolder and Executable are set correctly on Decompression.
When Initiator.Destructor runs, ReplacementAppFolder is Nil.
Do you have a hint what (and where) might be happening in between Decompression and hitting “Install” that sets the folder to Nil?
I don’t have time to look back at the code now, but based on memory, this shouldn’t matter. The script should be written with the correct values before then, and will take care of doing the replacement. Add some lines to the script that will confirm that it’s actually launching.
I think it does matter. Here’s the beginning of RunScript:
if ReplacementAppFolder is nil or not ReplacementAppFolder.Exists then
ReplacementAppFolder = Nil
return
end if
Are you calling Cancel in any of your Close or CancelClose events, or maybe somewhere else?
No. Just the UpdateInitiaiter = Nil in App.Close as suggested.
And as I wrote, on macOS it’s working perfectly.
I wonder where the Initiator might lose its Path. Think I’ll try to debug that property.
Think I found it. I was following your advice to do a CancelUpdate when I return true in CancelClose, which I have to do in order to quit the started helper apps and give them time to do so. I removed that code now and it seems to work.
Sorry for the hassle.
1 Like
