Lars Fosdal

I assumed any unmatched on-events would have been silenced. If E is nil - logging will be incomplete in some cases, since I pass the exception object to Eurekalog to capture a callstack for the log. It probably would be quite rare, though.

Not from the top of my head. I would definitively check the monitor to see if there is something enlightening in there?

With TCP/UDP/Serial, JsonRPC, REST, Databases and conversions and partial data transfers possible - you tend to accumulate a number of these.

When dealing with live data, there is no end to what can go wrong - so no - I do not have a small number of top level exception handlers.

That is extremely significant. I have countless numbers of these and I am starting to wonder if they should be rewritten to try // ... except on E: Exception do begin end else raise; end; and then have a general handler for those further out. Or.... just log "An unidentified terrible event happened."

FDQuery.FetchOptions - Does changing Unidirectional to True have any effect? FDQuery.FormatOptions have a TON of settings, including map rules - which may solve encoding issues if the ODBC doesn't provide all the info that FireDAC wants. I.e. you can explicity specify the type of value that the db field should be translated to. From the Delphi Tools menu: FireDAC Explorer can help with experimenting with Format/Fetch options. FireDAC Monitor can also give good insight into the low level goings on when your application is running. Edit: I also wrote this a few years back: .

I was thinking along the lines of eliminating the way the 32-bit ODBC is used as the core problem for the Delphi app. The next thing I'd look at, would be encoding, language, locale issues.

@Jasonjac2 Do you get the same problems with the 64-bit ODBC and a 64-bit Delphi app?

Regular TCP telegrams are low cost, event oriented, cross platform, cross tool. The only hassle is identifying the port of the server, which typically would be a config setting.

@milurt As timfrost wrote Your exception happens because you go from 0 to 70000 instead of 0 to 69999.

I do 🙂 Both to deliver tasks to worker threads, and to collect the updates and results.

or ... GetMem(ballnumber, 7000); FillChar(ballnumber[0], 7000, 5);

Datasnap is intended for serving applications with data, not for being a custom Web UI. Not sure if you can customize any html part of it?

Personally, I'd sacrifice build speed over code speed, and there are ways to reduce the impacts of slower build speeds, like continous background builds, etc.

Please note that since it still is marked as beta - there may be issues. If you find something, please report it.

The version resource of the default installed XMLMapper says 28.0.47991.2819 which only indicates it was built at the same time as the IDE. It still can't handle a recursive .xsd definition file. But, in GetIt - you'll find and that can handle my recursive .xsd - so that version appears to be the one with the new features!

The What's New presentation made a point of the number of issues that were fixed for 11.x versions - nearly 3k of them. The amount of issues highlights the need for a change in their development process. The marketing driven release process needs to come to an end, and a quality driven release process to replace it. There are many good developers in the team, but there is not enough time/resource to ensure that quality is the primary goal. There also seems to be developers that write code that really is sub par, but no process that corrects it. Instead, it seems to be, "let's add this cool new feature for the sales guys and release it on this pre-determined date to make sure marketing can maximize their campaigns". That needs to change.

I recommend strongly EITHER using the web installer OR using the ISO - never both. Did you connect an Android device? and read these? https://docwiki.embarcadero.com/RADStudio/Alexandria/en/FireMonkey_Platform_Prerequisites https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Android_Mobile_Application_Development https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Creating_an_Android_App We are unable to guess which ones.

@havrlisan Report it. Make a video. Describe what we see vs what you expect.

I wonder why I can't access that issue! And... now it works. Make sure to re-enter your creds after time-out 😛

Not sure why the colors for this are not one single color entry, but two. Foreground - Sync edit highlight (it appears only the foreground color is used) Background - Sync edit background (it appears only the foreground color is used) Edit: But no - I don't know why the template "helper" goes away when you switch focus, but the behaviour is the same in 11.1.

No, no, @David Heffernan - What I mean is that I keep the new version away from my regular work cycle until the new unintended features have been discovered - and if those affect our apps, until the first service update arrives. When I am happy that 11.3 is ready to use, having built our apps with it, and gone through the tests, we migrate everything. All of the devs switch version, and the build environment is upgraded. So far, that approach has worked well. As an example, we never upgraded to 11.2, f.x. as it didn't really fix the issues we had with 11.1, and offered little new of use to us. We went from 10.4 to 11.1 as well. We have the luxury of being able to do that, since our software is corporate and not shelf-ware.

@Vandrovnik - Tools | Options | User Interface | Editor - Don't highlight keywords - is checked by default. Also, Highlight words setting offers None, When selected, By cursor. I prefer By cursor.

I just noticed that my 11.3 in the VM compiled my 1.1MLOC project in 36 seconds, while 11.1 in the main OS used 1 min 5 seconds. The main OS has a corporate straight jacket and a ton more processes, though.

I have the new version in a VM until I am satisfied that it won't cause me problems. Only then do I upgrade my "production enviroments".