Lars Fosdal

Which causes problems for RTTI.

A pitfall with Enums is that they are so easy to change. Add another member in the middle of the list, and you have changed the ordinal value of the rest. This is fine if you only use the enumerated reference inside your application, but if you use the ordinal - f.x. when saving to/retrieving from a database, or when transmitting to another system - you get into trouble.

Changing NA to Nada gives same result. But - adding the "unit scope" works. CommandType := ScopedEnumsWithoutT.CommandType.NA;

Dropping the T for types in Delphi doesn't quite work for scoped types. program ScopedEnumsWithoutT; {$APPTYPE CONSOLE} {$R *.res} {$ScopedEnums ON} uses System.SysUtils; type CommandType = (NA, Whatever); type TClass = class private FCommandType: CommandType; public constructor Create; property CommandType: CommandType read FCommandType write FCommandType; end; procedure Test; begin var Instance := TClass.Create; try Instance.CommandType := CommandType.Whatever; // This is fine finally Instance.Free; end; end; { TClass } constructor TClass.Create; begin CommandType := ScopedEnumsWithoutT.CommandType.NA; // When using "unit name space" - this is fine CommandType := CommandType.NA; // [dcc32 Error] : E2018 Record, object or class type required end; begin try Test; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

All my method arguments start with a - regardless of if they are const, var or out.

A minor bug in Error Insight / Compiler messages Passing an unknown class as type parameter to a method gives multiple and slightly confusing error messages that doesn't identify the actual problem. https://quality.embarcadero.com/browse/RSP-31327

https://blogs.embarcadero.com/new-getit-web-portal The portal https://getitnow.embarcadero.com/

We could, but we have our reasons for not doing so.

There are a number of libs, such as TMS, that still do not use fully qualified unit names. We removed as many aliases as possible, but could not remove them all. As for the problem being discussed - is it the same as this one: https://quality.embarcadero.com/browse/RSP-18130?filter=-2 ? Edit: We use 10.4.1 now, and although the compilation still is sluggish - we wait a lot longer for the EurekaLog linker to complete its task than we do for the actual compiling.

Well, we have thousands of meaningful and reasonably obvious names (within their context) - but yeah - remembering them gets harder every year. Age takes its toll. 😛 But - Code Insight should work whether you are assigning or passing as a parameter. Unfortunately, it has often put the enumerated values a long way down the list of candidates. We've only started using 10.4.1, so the jury is still out on this issue, but the LSP has been less than rock solid so far.

Are we talking about MS SQL Server T-SQL - or is there a TSQL class somewhere? Regardless of which - I'd say go for FireDAC.

IMO, the > 2Gb 32-bit trick is an errorprone kludge. We are also dependent on 32-bit DLLs - but are considering going the extra length to isolate them behind an API of some sort.

@limelect Press to insert code without having the editor destroying it.

@Anders Melander - Would you need to clone that SVG imagelist if you need to use different sizes of icons at the same time?

Related: A good source of SVG icons: https://www.flaticon.com/

Absolutely. But nevertheless a goal. You need to KNOW the challenges with each component, and know how to work around them. Restarting is an option, but it should be a choice, not a result of a crash. As for "A network socket that couldn't connect" - Do you have to restart your services for that reconnect to happen?

In this case - you just may have to. The mechanisms are so completely different from Paradox to SQL, especially for large tables. You could in theory write a wrapper that can emulate locate and SetRange - but that would be a stumbling block.

Back before 2006, I had literally terabytes of data in Paradox tables on client sites. It initially used local tables on the client, the moved to shared tables on a file server, before I wrote a client/server middleware type of access method that got rid of a LOT of sharing/concurrency issues. I was very happy to leave that in the back mirror. If you want to keep the Paradox tables but change the access method - I'd question if it is worth the hassle. If you are going to migrate, why not do it properly?

I'd have a TBytes buffer and a list/array on the side where the parser breaks down the offset, "type" and method for extracting the buffer content in the appropriate form. If you use a circular buffer - it is slightly more complex - but not exceedingly so. The list/array on the side could also be circular.

Another factor for your choice: TBytes - zero based indexes AnsiString/RawByteString - one based indexes So - doing over will be a pain.

o.0 - I have it running on several machines, and haven't seen that trick yet. Auto-upgrade, yes, but not auto uninstall.

How are the strings delimited in the buffer? IMO, if you need to copy the strings out of the buffer to work with them anyways, you might as well future-proof for non-ascii and copy to a regular string with the appropriate routine. That can allow you to sanity check the string in context of format, and handle abnormalities.

What format is the string source? UTF-8? Ansi? How are string buffers measured? Byte/word length? Character length? Zero terminated?

TBytes.

GitHub. We are moving world+dog to the cloud. Current SVN is on-site, and requires maintenance.