Jump to content

Marco Cantu

Embarcadero
 View Profile  See their activity

  • Content Count

    28

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Marco Cantu

  2. Posted

    On 7/24/2022 at 2:47 AM, Nigel Thomas said:

    I seem to recall that this exact issue happened last year, when Embarcadero said it was a glitch. Looks like the glitch is still there?

    It's not exactly a glitch, it's how the CE licenses are set up by definition. They last one year. What we did last year and we did again (should be active now, it was completed earlier today) is to allow CE users to apply for a new license key for their existing version. 

    • Like 1

  3. Posted

    Let me clarify:

     

    Changing the PE format to target newer versions was a design decision. It's the same Visual Studio does. And it does make a difference in the results when invoking some HighDPI related Windows APIs. They FAIL to return the right value if the app is for XP, so if you change the PE setting (doable) you'll ahve some trouble on the latest systems

     

    The introduction of an XP braking issue with GetTickCount64 was not intentional and discussed (while of course GetTickCount64 was a requested feature, and it's called by other libraries) . We don't test on XP by design, no one in the beta did, most likley. While we don't officially support XP, such a simple change is doable -- as long there is zero impact on newer systems and it costs a limited time. I doubt we'll release a patch for it, though... 

  9. Posted

    22 hours ago, RonaldK said:

    On the new Roadmap:

    "Delphi support for the latest iOS Simulator" is now shifted to the Research Areas. :classic_ohmy:

    The issue with "Delphi support for the latest iOS Simulator" is that the iOS simulator technology is undergoing a complete change. In the past, on Intel Macs you had to build an Intel App the simulator could run. The new ARM Mac would require a different binary target -- so in effect a different compiler. Well, it might not require a new compiler, given the binary is the same that iOS runs... but I think you get the point. If we ere to build an Intel simulator (64 bit) in a little time that would be totally useless... So we rather skip it and jump on the ARM future sooner.

     

    I know

    • Like 1
    • Thanks 1

  11. Posted

    4 hours ago, ŁukaszDe said:
    • Compiler.Optimization
    • Compiler.BackgroundCompilerFileExists
    • Compiler.DirectorySearch;
    • Compiler.UnitFindByAlias
    • Compiler.CacheControl
    • Compiler.CompareFileName

    Do you have any actual numbers (compilation time improvement) for any of these. We are gathering some from different developers, and at this point the top one is UnitFindByAlias. Now workaround is stop using unit aliases, but it is our top issue to fix in the compiler. We also have another not in the fix pack that we are rolling out early in a patch, affecting unit cache for large projects and causing compiler time to grow (dramatically!) over successive builds

     

    If any other the fixes above (or any not listed) has a very significant effect, we can prioritize it. We are focused on reducing and eventually removing the need of the fix pack, but it takes time as some of the fixes are fairly direct (and many have been implemented in the past) while others require significant rework and spawn threads to do some of the work -- something valuable but requiring extensive testing

    • Like 7

  12. Posted

    Looking into it. I have the impression the original design assumes a UCS4String to have a null terminator.

    s:= [98,101,114,109,228,223,105,103,0]; // "übermäßig"

     

    Not only If you add 0 to the array everything works, but if you call UnicodeStringToUCS4String this is exactly what you get (an array plus the #0)

     

    s:= UnicodeStringToUCS4String('übermäßig'); //[98,101,114,109,228,223,105,103,0]; // "übermäßig"
    ShowMessage (length(s).ToString);

     

    Honestly, I don't see us putting a lot of effort in UCS4String 

    • Thanks 1

  16. Posted

    We see a lot of recent Android devices with 64-bit CPUs but 32-bit OS. Odd, I know, I wasn't aware is this was so widespread.

     

    As for emulators, the issue is they are mostly Intel-based, so Java apps run fine, but native ones require a ARM emulator like libHoudini (this was an Intel library, but I think they stopped all development since they exit the Android world)

  17. Posted

    This is odd, because what you explain does not match the process that was discussed internally in the company. You should be able to contact your sales contact or partners and ask for an increase of the registration limits. The main difference from the past is this is not automatic, but requires talking with sales (we know, not always what developers love doing). We have given some automatic bumps in registration increases, others are generally provide by sales -- that is unless the numbers become suspiciously high. Feel free to email be directly, if this proves to be an issue -- I mean getting in touch with sales/reseller.

    • Thanks 1

  20. Posted

    AFAIK, StayOnTop works differently from a primary windows or a secondary one, the VCL calls different APIs in different scenarios -- stay on top of everything else or stay on top of other forms of the same app. Worse case scenario, you can still call SetWindowsPos....

  25. Posted

    On 10/26/2018 at 4:12 PM, Dalija Prasnikar said:

    I think most of EMBT customers will see that as a positive move. While I fully understand them, I am not so sure.

     

    More thoughts... ARC is dead, long live ARC

    I think your last line "If we could have fresh start, without having the burden of existing code and frameworks lingering over our heads, ARC would be fine choice for memory management system." is a great summary I fully agree with. I still like ARC and I'm not happy with the decision. But would have been even less happy keeping the status quo (2 different models) forever. And we really cannot afford breaking VCL code (billions of lines of working code form our customers)...

×