Anders Melander

Yes: Install v23.2.3 There is no "workaround". To support Delphi 12 with an older version you would have to replicate the things they've done in 23.2 and then you might as well just install 23.2

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Overview_of_Generics#Dynamic_instantiation

Yes, you are right - and you couldn't do it with polymorphism.

Format would like a word with you about that.

I tHiNk YoU NeEd To DeBoUnCe YoUr ShIfT KeYs... I think you can get something to compile but even then I have a feeling that, whatever it is you are trying to do, isn't possible. FWIW, this one compiles: type IMyInterface<T> = interface function GetValue: T; function Clone: IMyInterface<T>; end; TMyClass<T> = class(TInterfacedObject, IMyInterface<T>) private FValue: T; private // IMyInterface<T> function GetValue: T; function Clone: IMyInterface<T>; public constructor Create(const AValue: T); virtual; function CloneObject: TMyClass<T>; end; function TMyClass<T>.Clone: IMyInterface<T>; begin Result := CloneObject; end; function TMyClass<T>.CloneObject: TMyClass<T>; begin Result := TMyClass<T>.Create(FValue); end; constructor TMyClass<T>.Create(const AValue: T); begin FValue := AValue; end; function TMyClass<T>.GetValue: T; begin Result := FValue; end;

I don't, but I know how to let the remote work find you: Answer questions on stackoverflow. Answer questions here. Participate in open-source projects. Of course, it helps immensely if you can do that within a narrow field of expertise (to minimize the competition) - or better than most. If you can stomach the self-promoting nonsense in the LinkedIn Delphi group you can also try posting there. I don't use it myself (as I wouldn't be able to behave). ...and start by changing your screen name. I assume your last name isn't 23668... If I wanted to I could live off the remote & freelance offers I get because my name comes up when clients google for info on some special tech they need help with.

You don't need to copy data from one FireDAC dataset to a TFDMemTable; All FireDAC datasets are mem-tables and can work in offline/briefcase mode. All you need to do is make sure you fetch all data from the server. Do a FetchAll like it said in the other thread posted.

AFAIK nowadays the ODBC driver is the native driver.

Check ResourceOptions.CmdExecMode; It should not be amAsync. Sorry. You already checked that. If you can, monitor the activity on the SQL Server to see if there is activity on your connection that you can't account for. I still think it's MARS (I've been bitten by that one many times). I can't remember if it can be disabled on the server, but that's one thing to try (just to rule it out).

You are not a serious person, are you? Uselessness is not defined by the existence of some newer - unless, of course, that's your only criterion.

Did you Google the error message? As the error message hints at, it's a concurrency issue; Your application attempted to call the DB server with a request while the connection was busy with a prior request. This happens if you are executing statements asynchronously. If you have MARS enabled I believe that can also cause the problem. Disable it in your connection string.

2022? It's useless!

Your code makes no sense. Instead of: value2 := random(500) + 1; while value2 < 251 do value2 := random(500) + 1; why don't you just: // Values from 251 to 500 value2 := 251 + random(250);

I have a client who wants to use DWScript to do structural load analysis of large models (thousands to millions of nodes). Since DWScript compiles to an AST (Abstract Syntax Tree) and then executes the objects in that tree, he was a bit concerned about performance. He had tried various other scripting systems and they were just too slow. So we did some benchmarking of a sequence of typical calculations in Delphi vs DWScript. As expected the Delphi compiled code was about 4 times faster than DWScript. The client thought that that was acceptable but I decided to try out the DWScript jitter anyway... As it turns out there might just be something to David's complaints about Delphi's math performance 😉 because with the jitter enabled DWScript was now more than twice as fast as the native Delphi code. Also, Delphi 64-bit was about 25% slower than 32-bit and 64-bit "optimized" was slower than "unoptimized". Not to take anything away from Eric Grange's amazing work on DWScript, but I would be embarrassed if my native code compiler was outperformed by a scripting system.

This place isn't representative. Most developers don't participate in communities and don't even know they exist. I've worked at a lot of different places and with a lot of different developers in my career and I think I've only ever met one other developer IRL that participated in communities. Not that I can see. My experience with Lazarus/FPC is limited to using it to make some open-source projects FPC compatible but from my POW they are constantly playing catch up with Delphi. And I think Lazarus sucks as an IDE.

Yes, you probably need to use a custom renderer to get control over the formats used. https://github.com/microsoft/Windows-universal-samples/blob/main/Samples/DWriteColorGlyph/cpp/CustomTextRenderer.cpp

Probably because of its size. Most Noto fonts are huuuge. Noto Color Emoji contains both COLR and SVG data. The COLR data is ~1Mb while the SVG data is ~18Mb... I'm not sure what you are saying here. Microsoft is the primary author of the COLR format and DirectWrite supports all the common color glyph formats: https://learn.microsoft.com/en-us/windows/win32/directwrite/color-fonts However, the client has to specify what format to use during Shaping and if the client asks for SVG glyphs then that is what it will use. https://learn.microsoft.com/en-us/windows/win32/api/dcommon/ne-dcommon-dwrite_glyph_image_formats You can try subsetting the font to exclude the SVG data and see if that makes a difference (apart from the 18 Mb data saved 🙂)

SVG color fonts are probably slow. All the other color font types (COLR, SBIX, CBDT) should perform more or less on par with regular OpenType fonts.

Beware of unqualified statements involving always and never. Unless the advice is to never put pineapple on pizza. That one is just a fundamental law of nature. As you've discovered it depends on the type of the variable. Local variables are declared on the stack and such doesn't involve the heap (i.e. the memory manager). Allocating a variable on the stack is basically free of cost. However, managed types need initialization and that initialization can be costly. TSearchRec contains a string and is therefore a managed type (i.e. slow). Integer is not a managed type (i.e. fast). Additionally, managed types are wrapped in an implicit try..finally block to ensure that they're also finalized. The help probably has more info on this. If you want to limit the scope just put a begin...end around the whole thing: begin var FileRec : TSearchRec; while not StopSearch do begin ... GetData (FileRec); UseData; ... end; end; Apart from that, in this particular case, you are touching the file system so the performance of inside vs outside will be dwarfed by that. ...and so the lesson here is: You don't get more useful insight by asking first.

What? Are you saying that this wasn't a good idea?

And how many articles have there been on TForm, TStringList, or TBitmap? Blog posts are just them doing marketing. It's hardly an indication of anything other than how much they want you to buy the product.

That's nonsense; RAD Server is not a replacement for DataSnap and DataSnap is not being discontinued. Actually, IMO it is more likely that RAD Server will be discontinued before DataSnap is.

I miss it every single time I need to install/update. Apparently, there are no UXers left at Embarcadero. Left-aligning the button would likely solve the problem but ideally, it should not be placed on the EULA page where one habitually just clicks through.

Looks interesting but then I went to the SonarQube site to see what their commercial terms were like and... Of course, given that they don't even list prices and that I had to Google for them, I guessed that much. OpenSource only then, I guess.