Marco Cantu

FYI, the server outage and the JIRA migration were totally unrelated (they happened at the same time, one scheduled the other not). Atlassian has discontinued the self hosted JIRA servers, the only option is going forward it to use the hosted system (or stay on an old not-secure and not-supported version). I don't want to discuss Atlassian offers and pricing, but given the 20 years of JIRA for our team work and bug tracking we decided to stay on it. This wasn't just one instance of JIRA, it was two separate installations with an extremely complex amount of automation and many plugins not supported by the cloud version. The limitations in JSM (Jira customers portal) are significant. We are going some extra mile around them (like sharing reports among customers). There is a lack of voting, but comments can be added. The UI is odd, but searching is not bad. We kept the system as open as possible and are open to additional suggestions, in the realms of what JSM (https://www.atlassian.com/software/jira/service-management) can do (ie, not much). Also, keep in mind that Embarcadero support comes from our support team, not just the bug reporting system. And PMs are always happy to engage in conversations.

We have received reports for this issue already. We don't have a ETA for the solution, but have been looking into it

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.

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...

Just FYI, I've updated my component for 10.4.2: https://blog.marcocantu.com/blog/2021-august-delphi-objectdebugger-updated.html Contributions are welcome... there is ample room for improvements

Yes, I dwell here from time to time. I'll have a look, I know there are other tools doing the same but I'll update mine, should not be a big deal... time permitting.

That's a hard question to solve without extra information, please feel free to reach me over email...

Announcing the Availability of RAD Studio 10.4.2 Sydney Release 2 https://blogs.embarcadero.com/announcing-the-availability-of-rad-studio-10-4-2-sydney-release-2/

Offers Java files and interfaces, along with steps, for adding Android Firebase client support in FMX apps. http://blog.marcocantu.com/blog/2019-05-android-firebase-patch-blog.html

A new patch for Delphi 10.4.1 is available, addressing iOS 14 and macOS Big Sur issues. Download via GetIt or the new customers porta. For more information see https://blogs.embarcadero.com/apple-platforms-patch-for-rad-studio-10-4-1/

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

Available at https://blogs.embarcadero.com/rad-studio-roadmap-november-2020/ Also, PM commentary at https://blogs.embarcadero.com/rad-studio-november-2020-roadmap-pm-commentary/

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

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

I'm curious are you deploying any additional Java code beside that in core FireMonkey? I wonder what is triggering Google alert...

Just FYI, the new (large) patch is out. https://blog.marcocantu.com/blog/2020-july-radstudio104-patch2.html over 20 Delphi compiler fixes, among a long list of items addressed. Fixed the debugger instability and a few more critical issues, also improved Delphi LSP quite a bit. Quality work will continue, this is a first step.

(and sorry if I don't follow up, I'm out a few days)

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)

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.

See my latest blog post at http://blog.marcocantu.com/blog/2018-nov-vcl-permonitorv2_getsystemmetrics.html

Just wanted to share my last blog post on changes to the Delphi language in 10.3: http://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html Still a bit rough in some details, but a very handy feature overall.

Actually I was imprecise. It doesn't use the parent handle, but walks over the parent hierarchy up to the containing form

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....

Another blog post about coming language changes in 10.3: "Introducing Inline Variables in the Delphi Language" http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

Not sure this fits perfectly in this forum (more of a non-tech let's fight topic, 😉 ) but here it goes. I just blogged about the plans for 10.3 and beyond around ARC in Delphi. See for more info http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments...