Kaju self-updater talk (v.2.x)

  1. ‹ Older
  2. 2 years ago

    Kem T

    2 May 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I could use some advice for the next version...

    Right now, you can create a background image in one of two ways: you can specify it within the app, or you can specify a URL to download the image for a version, but this was done in the days before hi-res was common.

    Modifying the former is easy. Instead of giving Kaju an image, you can give it an image set and Xojo will do the right thing. I'm updating the test app accordingly.

    The latter is trickier because you don't know if the user is using hi-res or not, so here are the choices:

    1. Allow you to specify an ImageURL (same as now) and Image2xURL, which will be optional. If only ImageURL is specified, the behavior won't change. If only Image2xURL is specified, it will be scaled. If both are specified, the ImageURL dimensions will be used and an image set created.
    2. Keep just ImageURL and specify a Scale key, assumed to be 1 for backwards compatibility. You can specify any number and the image dimensions will be calculated within Kaju.

    The advantage of (1) is that you might get better looking images on each type of screen, but the software will have to download each image whether it needs it or not.

    The advantage of (2) is simplicity but you are relying on Xojo to scale the image where needed.

    Thoughts? Preferences?

  3. Kem T

    2 May 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I was given the advice "do the simplest thing", and I think that's sound. The simplest is to introduce the "Scale" key. Eventually most people will be on hi-res and we won't have to worry about it anyway.

  4. scott b

    6 May 2018 Pre-Release Testers, Xojo Pro local coffee shop

    @Kem T I was given the advice "do the simplest thing", and I think that's sound. The simplest is to introduce the "Scale" key. Eventually most people will be on hi-res and we won't have to worry about it anyway.

    simplest and most straight forward path is the best way to go.

  5. Beatrix W

    17 May 2018 Pre-Release Testers, Third Party Store Europe (Germany)

    So I've finally gotten an SSL certificate for my main websites. Now Kaju (I think the current version still uses 1.x) complains about an incorrect packet marker on this code here:

    dim sig as string = firstLine.Left( Kaju.kUpdatePacketMarker.Len )
      if StrComp( sig, Kaju.kUpdatePacketMarker, 0 ) <> 0 then
        if HandleError( KajuLocale.kErrorIncorrectPacketMarker ) then
          continue do
        else
          exit do
        end if
      end if

    When checking the result there is a 301 redirect. The problem is that all old versions now will have the same hissy fit. Is there something I can do on my website to fix this?

  6. Kem T

    17 May 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Just so I understand the situation...

    Your app points to http://path/to/update which returned the update information. Now it wants to redirect to https://path/to/update but AllowRedirect is set to false in the app so it's not following it. Is that it?

    The only thing you can do is make sure the current url returns the update information and put a new url into the new version that uses the certificate. Also turn on AllowRedirect to prevent this in the future.

  7. Beatrix W

    17 May 2018 Pre-Release Testers, Third Party Store Europe (Germany)

    Yes, you understood correctly. AllowRedirect is set to false. Most likely I never thought I would have to use this property.

    The support from my hosting company told me to remove the automatic redirect from http to https and then muck around with the htaccess file myself and then exclude the update file. Perhaps I'll try this tomorrow.

  8. Kem T

    17 May 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I'm curious because I'm thinking of changing that default to True instead...

    Did you intentionally set it to false, or did you just let it use the default? If the latter, was that intentional, or did you just ignore it?

    My original thinking was about security, but now I see that this situation can become common if users didn't know or think about that property.

    BTW, the develop branch contains new code around the new framework HTTPSocket, and that does not give you the option, it will always follow redirects.

  9. Beatrix W

    17 May 2018 Pre-Release Testers, Third Party Store Europe (Germany)

    I just never noticed this property.

  10. Kem T

    17 May 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I think I will change it, then add a #pragma warning to the project, at least for the next version.

  11. Beatrix W

    24 Jun 2018 Pre-Release Testers, Third Party Store Europe (Germany)
    Edited 2 years ago

    I'm getting an unhandled exception when clicking cancel in the update window:

    2018-06-20, 14:01:00 unhandled exception!!!
    2018-06-20, 14:01:00 Buffer:
    2018-06-20, 14:01:01 --------------------------
    2018-06-20, 14:01:01 An error happened:
    2018-06-20, 14:01:01 Window/Class:
    2018-06-20, 14:01:01 Method/Event:
    2018-06-20, 14:01:01 Error Message: A really unexpected error occurred!
    2018-06-20, 14:01:01 Time: Mittwoch, 20. Juni 2018 14:01:00 32685458
    2018-06-20, 14:01:01 Type of Error: NilObjectException
    2018-06-20, 14:01:01 --------------------------
    2018-06-20, 14:01:01 Stack:
    2018-06-20, 14:01:01
    Sub Delegate.IM_Invoke(KajuHTTPSSocket, string, int32, InternetHeaders, FolderItem)
    Sub AddHandler.Stub.12(string, int32, InternetHeaders, FolderItem)
    Sub HTTPSecureSocket._ProcessPage()
    Sub HTTPSecureSocket.Event_Error()
    Sub SSLSocket._Poll()
    Sub Delegate.Invoke()
    Sub Application._CallFunctionWithExceptionHandling()
    2018-06-20, 14:01:01 Stack done
    2018-06-20, 14:01:01 ErrorReportWindow.Constructor
    2018-06-20, 14:01:04 ErrorReportWindow.Constructor done

    I've tried to step through the code but the exception happens a while afterwards.

    Happens both in Kaju 1 and Kaju 2 for Xojo 2017r1 and 2018r1, both 32bit and 64bit. I could guess that the window is closed before the socket is finished with cancelling.

    I've tried to add an App.SleepCurrentThread(1000) before closing the window. I've also added my exception handler to some events in the socket.

    Any ideas?

  12. Kem T

    24 Jun 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    What platform? Can you reproduce this in the test app that comes with the project?

  13. Beatrix W

    24 Jun 2018 Pre-Release Testers, Third Party Store Europe (Germany)

    MacOS. I'll try to reproduce the problem with the test app.

    I'm pretty sure that I tested the cancel button before. Could this be related to https?

  14. Kem T

    24 Jun 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    I suppose. You can also try ExecuteAsync in the latest develop branch of the project. It uses the new framework socket and will require some refactoring of your code, but will bring greater compatibility.

  15. Beatrix W

    24 Jun 2018 Pre-Release Testers, Third Party Store Europe (Germany)

    Not reproducible. Bummer. I've got a customized version that is sort-of updated to version 2. Back to Arbed.

  16. Kem T

    24 Jun 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Please try the new code and let me know. If it solves it, I might just deprecate Execute for the next release.

  17. Aurelian N

    9 Jul 2018 Pre-Release Testers, Xojo Pro

    @Kem T Please try the new code and let me know. If it solves it, I might just deprecate Execute for the next release.

    Hello Kem,

    So, I just did a pull of the latest git and I have some funny things on the admin part of the app, it seems that the TabPanel becomes transparent and you cannot distinct at all the option on the other tabs , maybe it's just me but is weird, I adapted the code from the old one to the new release and unfortunately I keep on getting the

    The RSA signature of the update packet cannot be verified.

    even if I check the keys and all , it simply does not work.

    So no idea why on the Binaries and 64-Bit Binaries it goes nuts, and the controls are like loosing background and all together so you cannot see them properly .

    Compiled here please have a look and let me know, I will try as well to delete all the git and pull a fresh one . I'll keep you updated .

  18. Aurelian N

    9 Jul 2018 Pre-Release Testers, Xojo Pro

    SO, just did a fresh clone and same thing, in the Zip I posted earlier you have the snapshots, and I hope that the builded app will show the issues on your side as well, that is first time when I see that on TabPanels acting like this, I have no idea if it's because of XOJO or something in the code.

    As a reference I use XOJO 2018R1.1 and MacOS High Sierra 1.013.5, hope it helps .

    Thanks .

  19. Kem T

    9 Jul 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Thanks for bringing this to my attention. It looks like some change to that window that the latest Xojo is not liking as it doesn't happen in the master branch. I'll push a fix out soon.

  20. Kem T

    9 Jul 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Please try now.

    It turns out that setting a ContainerControl's Transparent to True is a bad thing. All the controls within it or within a Window can be Transparent, but not the CC itself.

  21. Kem T

    9 Jul 2018 Pre-Release Testers, Xojo Pro, XDC Speakers, MVP Connecticut

    Naturally what I said was exactly the opposite of what I did, so let me try again...

    Under the new guidelines, it's recommended to turn off Transparent on all the controls, so I did, including the ContainerControl, but that caused the problem you saw. Leaving the ContainerControl.Transparent set to True fixed the problem. All the other controls, including ones within the CC, are set to False.

  22. Newer ›

or Sign Up to reply!