Lars Fosdal

I agree. You can't blame the client facing people. The management needs a good kick in the shins, though.

Well, the blogs were affected too...

I agree. It leaves a really bad impression - especially when it happens over and over.

Or is that the root cause?

EMBT knows and they are working on it. No ETA as of now.

See

See

See

See

You can get rid of the coloring book background in Tools | Options | IDE | Welcome Page, press Clear

They are painfully aware of it. It is not good for their operational reputation.

So, if you intentionally refer to a non-existing custom attribute - you get no warning? This compiler warning setting exists in my D12 project - and it appears to be True by default.

There is nothing unusual with Explorer querying a registry entry that doesn't exist. In this case, it checks for Application Compatibility flags and finds none for bds.exe. Nor is there anything unusual about Explorer reading from the files to extract things like file information resources. In computing like in medicine - it is only when the patience appear sick that you start examining the symptoms in detail.

There are many better alternatives to Sleep. https://learn.microsoft.com/en-us/windows/win32/sync/wait-functions#multiple-object-wait-functions The downside of a single Sleep is that it blocks termination of the thread. The downside of multiple Sleep + time checks to allow termination, consumes more CPU. Signals, WaitForXXXX & Timeouts give you all the tools you need to have low cost and responsive threads - even if it requires a little more scaffolding code.

Same here. I really don't like design time db components.

That is probably an accurate assesment.

@JonRobertson I have no performance comparisons between the ODBC driver and the OLEDB driver, so I'll have to take that at face value. Devart did a a more nuanced comparison between the two. The OLEDB driver was deprecated by MS at one point, then undeprecated in 2018. Not sure why EMBT chose not to create a wrapper for it, but resources may have been an issue? As for ODBC vs Native - In case there are multiple drivers installed, I wrote the following simple code to pick my preferred driver, but these days we stick with the ODBC driver(s) due to the Native Client being too old for some of our databases. class function TPSDFireDatabasePoolMSSQL.FindBestDriver(const Link: TFDPhysMSSQLDriverLink): String; const // Constants copied from implementation section of FireDAC.Phys.MSSQL C_SQL_SERVER = 'SQL Server'; // DO NOT TRANSLATE C_2019_ODBC = 'ODBC DRIVER 19 FOR SQL SERVER'; // DO NOT TRANSLATE C_2018_ODBC = 'ODBC DRIVER 18 FOR SQL SERVER'; // DO NOT TRANSLATE C_2017_ODBC = 'ODBC DRIVER 17 FOR SQL SERVER'; // DO NOT TRANSLATE C_2016_ODBC = 'ODBC DRIVER 13 FOR SQL SERVER'; // DO NOT TRANSLATE C_2012_ODBC = 'ODBC DRIVER 11 FOR SQL SERVER'; // DO NOT TRANSLATE {$IFDEF POSIX} C_FreeTDS = 'FreeTDS'; {$ENDIF} {$IFDEF MSWINDOWS} C_2012_NC = 'SQL SERVER NATIVE CLIENT 11.0'; // DO NOT TRANSLATE {$ENDIF} var DriverList : TStringList; WantedList : TArray<String>; Driver: string; begin Result := ''; // Blank = Default WantedList := {$IFDEF MSWINDOWS} {$IFDEF SQLNative} [C_2012_NC, C_2017_ODBC, C_2016_ODBC, C_2012_ODBC] {$ELSE} [C_2018_ODBC, C_2017_ODBC, C_2016_ODBC, C_2012_NC, C_2012_ODBC] {$ENDIF} {$ENDIF} {$IFDEF POSIX} [C_2018_ODBC, C_2017_ODBC, C_2016_ODBC, C_2012_ODBC, C_FreeTDS] {$ENDIF}; DriverList := TStringList.Create; try Link.GetDrivers(DriverList); DebugOut('Available SQL drivers'); // DO NOT TRANSLATE for Driver in DriverList do DebugOut(' "' + Driver + '"'); for var Wanted in WantedList do for Driver in DriverList do begin if CompareText(Wanted , Driver) = 0 then begin DebugOut('Selected driver: "' + Driver + '"'); // DO NOT TRANSLATE BestDriver := Driver; Exit(Driver); end; end; finally DriverList.Free; end; end;

@Stephanus Kusuma ADO has been succeeded by FireDAC. Although it has not been deprecated like BDE, ADO is quite old and you are more likely to get answers to questions about FireDAC . FireDAC also has a lot better performance, in my experience.

Unfortunately, it seems that the EULA was left there by intent. https://quality.embarcadero.com/browse/RSP-39577 IMO, it is odd that they couldn't add a command line argument like "-AcceptEULA to get rid of the required interaction.

We use a font named Code128.ttf to generate bar codes on Windows. Can that font be loaded for on-screen rendering in an FMX app on Android and/or iOS? Does anyone have an example for loading a custom font and rendering text with it in FMX?

Is there a newer post than this one? I.e. one that suggests using the forums - I could not find one, so using the QP is recommended. https://blog.marcocantu.com/blog/2015-december-feature-requests-quality-portal.html If you decide to post a feature request, it needs to be clear on the technical benefits of using ARMv8, i.e. describe why ARMv7 doesn't cover the need.

Link?

@RDP1974 You should post this as a feature request on quality.embarcadero.com.

I'd use a log broker service, i.e. have log requests from the different apps go through the broker APIs.

Offsets may be helpful if the streamed order is not the same as the desired order, such as for a tree structure. Personally, I'd opt for identities and rebuild the structure after loading the stream. But, since OP doesn't share sufficient info about content and structure, this is all speculation.