OK. So if I generate a new file with the new admin app, will the old 2.0 versions I have in the field be able to read it?
I’ll try generating a new file tomorrow. Time to get some shut-eye.
Yes Jon, I wrote and released an open source project so you can help yourself. I am not your tech support, and now I’m done. Good luck.
Kem,
If you notice, I felt my reply was inappropriate and deleted it. You are correct that you are not my tech support. I’m simply looking for help from someone that knows my about the code than I do. I appreciate you taking the time to help me and I am sorry that I offended you.
I was able to get it working with the file from the new admin app and the old 2.0 code still seems to read it fine. I’m seeing everything I should now.
Jon
Accepted, moving on.
Kaju was designed to ignore keys it didn’t recognize knowing that future versions might add stuff. Backwards compatibility for each update is a requirement.
That’s excellent to know. I have it working now with my site using HTTPS. Since I’m using AsyncUpdate, I have to add some more event handlers in the one case where my check was depending on synchronous operation, but that is easy enough to do.
If it doesn’t work now, then I must be doing something else wrong, but all the handling of when to bring up the update window, etc. is all done inside the Kaju code which I’ve not touched. So I’m hoping this fixes it. I don’t know if Windows 10 requires HTTPS like OS X now does (I’m still on Win 7), but it’s all secure now.
Thank you for your help.
I thought about this some more last night and took a little different perspective. Perhaps it’s not so much that anything anyone is doing on a site needs to be encrypted or secured, but knowledge that the site you are going to is the site you want and not something hijacked. The signed security certificate ensures that if someone visits my site, that they can be confident that they are on my site and not some hacked redirect to it. Therefore the software they download from it is valid and not some form of malware.
Looking at it that way, I can understand why HTTPS everyone can be a good or desired thing.
Hey all,
I’ve come across a hiccup in Windows with Kaju and using an secure Async socket. It seems that the PageReceived event is being fired multiple times until there’s a stack overflow and the program crashes. This seems possibly to be a Xojo.Net.HTTPSocket thing as opposed to a Kaju thing because the error is happening in the PageReceived event HTTPSocketAsync object which is a Xojo.Net.HTTPSocket object.
Has anyone else seen this happen and know a workaround or cause?
What’s really odd is that, when I first fire up the program, I have Kaju check for an update in the background. It’s if I initiate a manual update that this socket seems to go nuts. Again, in OS X, it’s fine. I don’t have a problem. Just Windows.
[quote=431866:@Jon Ogden]This seems possibly to be a Xojo.Net.HTTPSocket thing as opposed to a Kaju thing because the error is happening in the PageReceived event HTTPSocketAsync object which is a Xojo.Net.HTTPSocket object.
Has anyone else seen this happen and know a workaround or cause?[/quote]
I saw that behavior on a project, but I did not have time to stop and investigate whether it was the Kaju implementation or a Xojo framework issue. It did not happen in 2018r4 or earlier.
Thanks, Tim. I’ve figured out how to “stop” the behavior from crashing my app, and I found a couple of spots where I don’t think I was coding some things properly. When I was operating synchronously, I created my Kaju.Updater object locally in a method. Then I waited for and returned the result. When I moved to an Async connection, I added handlers to handle the async events, but I messed up by still using just a locally scoped Kaju.Updater object. So the object technically goes out of scope when the method completes, but it’s held in memory because of the events still existing. I’m not sure if this was feeding the problem, but it certainly isn’t good coding form!
So I’m still going through and trying to figure if there’s something I’m doing or the Xojo.Net.HTTPSocket is doing. Ideally, I’d like to update things to URLConnections and I know Kem wants to do that too, but right now, I don’t know if I have time to do it myself.
There are known bugs in HTTP socket in 2018r4 on Windows, so that might be what you’re seeing.
OK. I have a feeling it might be. While my “out of scope” object was not good coding form, there’s nothing with anything that I am doing (that I can see) that would cause the PageReceived event to fire non-stop.
Indeed I have same issue, I’m using the Xojo.net.HTTPSocket for a simple app that controls a device to open a door and I do have another socket that checks the status of it , like a heartbeat but the problem is that some times the socket goes nuts and it kills the app after max 30 min, on Mac so far it is stable .
OK. Well, what I have ended up doing is make sure that I remove the event handler for the socket as soon as I am done with it. This is most easily done setting up delegate methods and having a set method that you can just use to set the delegate to NIL. AddHandler and RemoveHandler work fine as well, but you have to be a little more specific with how you use them and wrap them in try/catch blocks so that you don’t throw an exception if you’ve already removed the handler, etc.
I’ve tested removing the event handlers and then adding them right back in to see if the socket is still going crazy. It isn’t. Seems like as soon as the event handler is removed, the socket starts behaving itself.
[quote=431952:@Jon Ogden]OK. Well, what I have ended up doing is make sure that I remove the event handler for the socket as soon as I am done with it. This is most easily done setting up delegate methods and having a set method that you can just use to set the delegate to NIL. AddHandler and RemoveHandler work fine as well, but you have to be a little more specific with how you use them and wrap them in try/catch blocks so that you don’t throw an exception if you’ve already removed the handler, etc.
I’ve tested removing the event handlers and then adding them right back in to see if the socket is still going crazy. It isn’t. Seems like as soon as the event handler is removed, the socket starts behaving itself.[/quote]
Hi Jon,
Can you please provide an example for that ?
I will see tomorrow the project and maybe put it somewhere , so far works nice on Mac but windows it’s a nightmare .
Thanks .
1.) In whatever object you have that calls the updater code, create a Delegate with the same signature as the event you want to handle (just like add handler):
Private Sub delAsyncUpdateComplete(sender as UpdateCheckClass, result as Kaju.UpdateChecker.ResultType)2.) Create a property in this object of that type of delegate:
Private Property AsyncUpdateCompleteCallBack as delAsyncUpdateComplete3.) Create a Handler Method for your Delegate:
Private Sub HandleAsyncUpdateComplete(sender as UpdateCheckClass, result as Kaju.UpdateChecker.ResultType)
If AsyncUpdateCompleteCallBack <> Nil Then
AsyncUpdateCompleteCallBack.Invoke(Self,result)
End If
End Sub
4.) Create a Set Method to set the callback for the delegate:
Sub SetAsyncUpdateCompleteHandler(theCallback as delAsyncUpdateComplete)
mUpdateCheckInstance.AsyncUpdateCompleteCallBack = theCallback
End Sub
5.) Set an initial AddHandler for the event in the constructor of your object:
AddHandler AsyncUpdateComplete, AddressOf HandleAsyncUpdateCompleteBe sure to set a remove handler in your close event for the object.
Now, wherever you want to use this update object, you can easily create a method, and set that method to be the event handler. No need to worry if AddHandler or RemoveHandler has been called. You can call do this anywhere you want:
UpdateCheckClass.SetAsyncUpdateCompleteHandler(AddressOf UpdateCheckCompleteEvent)So my object that does all the checking is called UpdateCheckClass and it’s actually a Singleton so I can call it anywhere in the app and I don’t have to worry about instantiating it (and in the case of a Singleton, the method in step 4 is actually a Shared Method.
My UpdateCheckComplete event has the following singature/code:
Public Sub UpdateCheckCompleteEvent(u as UpdateCheckClass, UpdateResult as Kaju.UpdateChecker.ResultType)
UpdateCheckClass.SetAsyncUpdateCompleteHandler(Nil) // HERE IS WHERE I REMOVE THE HANDLER
Select Case UpdateResult
Case Kaju.UpdateChecker.ResultType.Error
MsgBox "There was an updater error."
Case Kaju.UpdateChecker.ResultType.IgnoredUpdateAvailable
MsgBox "There is an update available but you have chosen to ignore it."
Case Kaju.UpdateChecker.ResultType.NoUpdateAvailable
MsgBox "No update is available at this time."+EndOfLine+EndOfLine+"You have the most current version."
Case Kaju.UpdateChecker.ResultType.UpdateAlreadyInProgress
MsgBox "There is an update already in progress."
End Select
End SubSo basically as soon as the event handler method is called, I then remove it.
I’ve got one more layer of an event in here from the socket that uses a traditional Add/Remove Handler directive, but I’m going to skip that. This should be enough to get you going. If not, I can try to throw my code into a project for you.
So this is specifically for the Kaju Updater object I am working with. Your case may be a different class, but the same principles still apply. The PageReceived event of the Xojo.Net.HTTPSocket is the offending event. So I would use what I do above for that event in your HTTPSocket. It’s signature is:
Event PageReceived(url As String, httpStatus As Integer, content As String)So create the Delegate and necessary handler methods and callbacks with this signature and then you can add/remove the event at will in code. It’s pretty cool.
This looks like the problem I saw, so it doesn’t look like it’s a Kaju problem 
https://forum.xojo.com/53353-net-httpsocket-pagereceived-problem
Yeah, I don’t think it’s a Kaju thing. I posted wondering if others had seen the same or if my implementation was causing an issue. Looks like others have seen the same thing. Dale is definitely correct.
Hi,
I am trying to use Kaju in my first Xojo project, but ran into a problem, I can’t solve…
Environment:
Xojo 2019R1 on macOS 10.14.4
Kaju 2.1
Implemention is done completly, version set to “0.5.0” under ““Build Settings > Shared > Version” (Major Version: 0, Minor Version: 5, Bug Version: 0, Stage Code: Development, Non Release Code: 1”. plist in build app shows 0.5.0 as versionstring.
Kaju Admin is set up with correct App Name, version “0.5.1”, with releasenotes, a Mac binary and a windows 64-bit binary. HTML file and binaries are uploaded to website and path and RAS Key are put into app.
Checking for updates works fine in debug mode - Kaju finds the update from 0.5.0 to 0.5.1 and displays its update window.
But in the build app it does not find any update. Even testing with the “WndTst” Window and manually entering all neccessary infos (URL and RSA Key) it checks the html file and says: “no update available”.
Any tips, how to solve this?
Regards,
Thomas
Just for testing, try changing the Major Version to 1 instead of 0 and see if that makes a difference. I mean in both the compiled app and the update info.
Perfect - I don’t know why, but with a version number beginning with 1 the update is found in the compiled app.
Thanks!