Anyone who wants to see the code in action, look in the Authentication branch of the GitHub site.
https://github.com/ktekinay/Kaju/tree/feature/Authentication
or you are trying to weed out the licenses/users that are pirating your app. Those “bad” users won’t get updates and the majority (aka good users) get updates.
PS> sorry I am late to respond.
In other words, the app should ask the user for a username/password during the update process, at least during downloads?
I would use part of the “registration” information as the username/password. That way I would have to ask them for it. Now this login/password would only used by the system to authenticate the user to check for updates. All other locations would use a different l/p.
for instance my “reg” info has three pieces of information:
full name (first & last)
email address
serial number.
I would use one of those for the login, and another one for the password.
make sense? or am I still not caffeinated enough today?
Just for update information, right, not the downloads? Because the current process does not contemplate developer interaction once the update information is obtained from the server.
If that’s right, my changes will allow for that in the url.
[quote=166899:@Kem Tekinay]Just for update information, right, not the downloads? Because the current process does not contemplate developer interaction once the update information is obtained from the server.
If that’s right, my changes will allow for that in the url.[/quote]
for the update information and for downloads. I put all of it behind the same “wall”.
but @Kem Tekinay I want to be clear. This is a “nice to have”, I have no requirements for this anytime soon (next 6 months). I don’t have the a crystal ball so I can’t predict farther out than that.
Thanks, for taking the time Kem. I’ll have a look for something I must be doing in our app that’s causing this.
Thanks again for this great project!
Yes!! thank you very much!
I’ve just posted version 1.4.
This version includes a Kaju.Version constant so you can keep track of what version is in your project. The Admin app automatically uses this version as its own at compile time.
More substantively, on Windows, XCOPY gets the /g switch to avoid some issue having to do with encryption on some systems.
After the user initiates an update, either the new version will launch because it succeeded, or the old version will relaunch because it failed. In the former, the app will launch with a command-line switch with the version that it just updated from. In the latter, it will get a switch letting Kaju know it failed. You can use new methods in the Kaju module to check either of these conditions.
Finally, if you need to use an authenticated server, you can specify the username and password in the URL like http://un:pw@example.com:80/path/to/file for either the update info or the binaries.
The project is on GitHub at:
I just released a minor update, 1.4.1.
- Admin app: Lock “From URL” buttons to the right of the window.
- Added Finnish translation.
Kem
This looks great but I’m having some problems with it.
Firstly I had to insert a loop to close all windows prior to your “quit” in the Quit and Install after successful download - for some reason the quit was generating some kind of exception which prevented the app from quitting.
Secondly - having closed all windows and issued the quit - the app quits but the new version is not installed - I see no activity in the Applications Folder (e.g. backup, new app, delete backup).
How can I debug this further?
Kem
Further info - looking at your code - it should be the destruction of the updaterInitiator property that calls the RunScript to effect the backup/install/delete backup process. But, as far as I can tell in my tests, the updateInitiator is not getting destructed on quit.
The “Quit & Install” button will attempt to move the Kaju window the background first so other windows will be closed first. Each window should call Kaju.CancelUpdate if the close is cancelled, so there should be no reason for you to loop through anything.
Perhaps trace through the code starting when the Quit & Install button is pressed to see what’s going wrong?
Kem
The only way I could get it to work in the end was by modifying your code in the Quit & Install button to:
[code] //manually close all windows
while window(0) <> nil
window(0).close
wend
//force the run-script - not working in destructor
app.updateInitiater.RunScript
Quit[/code]
And by making the runScript public.
Now to test fully to ensure other features work.
I wish you had identified why the code was not working unmodified. The way you’ve written that, if a certain window cancels the close, you will get an endless loop.
Kem,
I have been trying to identify the problem - but so far little luck. The best I’ve been able to come up with is the separate thread called Quit not Quitting.
Without the additions to the script, the quit command does not quit the app, but just beeps. Only by manually closing the windows was I able to get the quit to quit.
Similarly, the destructor was not being called on Quit - so without forcing the runScript, it would not update the files.
Thanks for what you say about the continuous loo. I will check into that.
For now I just wanted to ensure the various component parts are working - it just seems to be the Quit command which is getting held up. If I can resolve that then hopefully I can get back to your standard code.
Can you elaborate on this? You have a separate thread running that’s not stopping?
Examining the IDE in debug with a breakpoint on the quit command shows that there are no threads running and that only 2 windows are open - the window that calls your updatechecker (a modal preferences window) and the underlying main window. Neither have a cancelClose event associated with them.
I’ve also looked to see if there are any AddHandlers left lying around - but neither of those windows have them. I don’t think there are any other addHandlers in play.
The quit does cause an EndException which captured and raised per your code on the other conversation, but I still just get a beep on quit, and the app stays running.
Sorry, correct that a bit. If I first close all the windows, then I get an EndException, captured and raised.
If I don’t first close the windows and use your code:
try
quit
catch err as RuntimeException
if err IsA EndException or err IsA ThreadEndException then
raise err
else
msgbox "another type of exception"
end if
end try
Then I just get a Beep and the app stays open. No runtime exceptions are captured.
Now I’m curious. Can I remote into your machine to take a look?