Jump to content

Chris Pim

Members
 View Profile  See their activity

  • Content Count

    59

  • Joined

  • Last visited

Posts posted by Chris Pim

  1. Posted

    The TBannerAd component creates a native control. Because of the way FireMonkey renders everything to a canvas, native components will always render on top of FireMonkey components. It’s a side-effect of the way it works.

     

    The way I got round this is to hide and show the banner component when in other screens (e.g. tabs of a page control or frames which display as screens depending on your UI architecture), so it doesn’t get it the way when I don’t want it to.

    I also suggest including a bottom padding to your multi view menus to push the contents above the banner.

     

    I hope this helps

    • Like 1

  3. Posted

    1 hour ago, Clément said:

    Given the scenario, wouldn't it be better to skip 10.3.2 and go straight to 10.4?
    I suppose the necessary workforce spent to release an updated such as 10.3.2, could be used to make 10.4 time to market shorter.
    I guess most of us understand the difficulties Delphi is trying to get out of  (a lot of bugs and bugossaurs must be dealt with while keeping up with a very dynamic market).

     

    I wouldn't mind skipping 10.3.2 if that would allow a more stable and anticipated 10.4 release. To be honest, if both releases are so close to each other, I would probably wait to install 10.4 anyway, since I need at least a week to proper test a Delphi version before migration.

    I wondered the same thing but I guess as the NDA exclusion only mentions allowing Android updates from 10.4 beta not iOS, you’d still be better using 10.3.2 for iOS, Windows and Mac builds while they get 10.4 released if you’re already using 10.3 anyway. 10.3.1 is really buggy so if 10.3.2 is more stable then it may be worth upgrading.

  6. Posted

    Has anyone heard any more about this yet? The dreaded 1st August deadline is 3 weeks away after which we won't be able to give our Android users app updates should we need to.

    If things are running according to the last roadmap at EMB, then they're behind and haven't even released 10.3.2 yet let alone the sorely needed 10.4 which is supposed to contain the Android 64 bit work.

     

    I'm getting very worried that we might not be able to support our Android users for 3 months while they get a 10.4 beta out. We have 220,000 of them and the thought of not being able to get even an emergency bug fix to them should we need to terrifies me! Surely EMB must be taking this deadline seriously?

    • Like 3

  7. Posted

    1 minute ago, dummzeuch said:

    I guess everybody in the Beta test is used to turning off error insight so nobody noticed the new bug.

    (I wasn't in the Beta test, but I might have done the same.)

    It may seem so, but that’s not true - they just weren’t fixed before the release...

  9. Posted

    I have strange problem occurring when parsing a JSON string on iOS using the System.JSON library in Berlin.

     

    I call TJSONObject.ParseJSONValue() to get a value from the start of a JSON string which has worked fine if I run under Windows.

     

    As soon as I run under iOS, the same JSON string causes a null pointer exception. When debugging through, the null pointer is the TJSONObject class itself which is odd as ParseJSONValue() is a class function so don’t know why that would ever happen.

     

    I suspect this isn’t really the case and is just what the debugger is interpreting (the iOS debugger in Berlin isn’t great).

     

    I suspect the JSON string is too large for the parser as it’s a huge string.

     

    My question is whether anyone is aware of a size limit for parsing a JSON string or whether there’s a known issue in the Berlin JSON libraries which might cause this?

     

    Unfortunately I can’t provide a sample JSON string as it’s a client’s backup data but hopefully someone will be able to help.

×