Lars Fosdal

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.

I think you missed the point of my suggested changes. The point was only to be able to read the 32-bit stream. I think you will need to rewrite the code that loads the data from the old-32 bit structures. I don't see a clean easy way to avoid that, f.x. by using my example record struct to read the old stream, and then move it to a 64-bit version with actual pointers.. You say Element sequence is important - is the order of the loaded double linked list supposed to be different from the streamed order? I have a feeling that your records are more complex than your example, and I certainly don't understand the reason for the untyped pointer. Are the actual records fixed in size or do they vary in size? Are you writing new 32-bit and 64-bit apps, so this is not a transition thing - but a need for a future shared format? In that case, I would rethink the structure and replace the pointers with stream offsets.

Does the stream consist only of ptr_rec2 elements? Is it simply a double linked list? Is the element sequence in the stream of importance? Are the pointers relative positions in the stream or are they original memory positions in the old win32 app and discarded/replaced when loading in the receiving app? Do you need to keep it in the same linked list format in the new 64-bit app? Both ptr_rec1 and pointer are 8 bytes in 64-bit - so to read the stream in 64-bit, you would have to replace the pointer types with a 32-bit variable type Fake32bitPtr = UInt32; ptr_rec1=Fake32bitPtr; rec1=record i1:integer; p1:Fake32bitPtr; end; ActualPtr_rec2 = ^ptr_rec2; ptr_rec2=record rec:ptr_rec1; i:integer; p2:Fake32bitPtr; end; If the stream is not incredibly large, you could create a shadow structure that basically is an array of ActualPtr_rec2 and point to the ptr_rec2 elements without caring about the pointers?

Why would you stream the pointers? They only have any meaning inside each application as a reference to a memory position.

Nope. I bought a license, though. Invaluable for sorting out the authentication protocol issues I had.

I use reg.ex search/replace and/or macros for that kind of stuff.

I didn't realize that VSCode had it. It defaulted to Alt+Click, while I expected Ctrl+Click.

Another thought - would it not be just as convenient to search the Windows Eventlog for the various events for start/logon/logoff/sleep/reboot/shutdown?

I was also thinking about a service, but it might be more trouble (rights wise) to get one installed than a simple standalone app. Isn't there messages to respond to that can prevent/postpone the sleep?