Leaderboard

Perhaps you are just expecting something the method isn't intended for. ExecuteAll doesn't execute all scripts in the SQLScripts collection. It only executes the first one (the main script), while the others are meant as subscripts to be called by name from the main script or other subscripts. This is an example from the docs: with FDScript1.SQLScripts do begin Clear; with Add do begin Name := 'root'; SQL.Add('@first'); // explicitly call 'first' script SQL.Add('@second'); // explicitly call 'second' script end; with Add do begin Name := 'first'; SQL.Add('create table t1 (...);'); SQL.Add('create table t2 (...);'); end; with Add do begin Name := 'second'; SQL.Add('create procedure p1 (...);'); SQL.Add('create procedure p2 (...);'); end; end; FDScript1.ValidateAll; FDScript1.ExecuteAll; That said, TFDScript is not a container for scripts to be executed in sequence by calling ExecuteAll. That has to be done by your own code.

We're styling the uses section the following way: uses Windows , SysUtils , Classes , Graphics , Forms ; break after uses break after each unit (but before the comma) only indent the lines not starting with a comma ("Windows" in this example) break before the semi-colon I created a patch and added it to the corresponding ticket: https://sourceforge.net/p/gexperts/feature-requests/154/ It adds two new options to the formatter (line-break page): 'After "uses"' and 'Before the comma'. The latter as a sub-option for 'Between every unit in "uses"' (like 'Except single lines'). 'After "uses"' just adds a break after "uses", to start the "uses"-block. "Before the comma" adds the line feed before the comma in the uses section instead of after it. I also removed the fixme regarding NoIndentUsesComma and FeedEachUnit as it (currently) does exactly what I intended when I submitted the NoIndentUsesComma-patch some time ago. I would like to see this patch merged or at least have some comments if there is something wrong/not as intended.

Yeah, it's a pain because of how bloated the system/sysinit.pas files have become and you cannot recompile them without the command line compiler. Some fun "unrelated" trivia though... Did you know the GetIt package manager used by Delphi/CBuilder can deploy compiler patches? Did you know that the GetIt package manager simply downloads patches from an open/public https server? Did you know that "CompilerLSPHotfixGeneral-20201104" fixed some compiler issues and in doing so needed to deploy a new version of the command line .exe's? Did you know that although CE doesn't need this patch it is still openly available for uses that do need it and is perfectly compatible with the current CE version? Just sayin' =D

Whether this works or not depends on the source image format. TPngImage does not support direct assignment from a TJpegImage, for example. In such a case you have to go through a TBitmap as intermediate. procedure TForm1.Button1Click(Sender: TObject); var png: TPngImage; bmp: TBitmap; begin image1.Picture.LoadFromFile('C:\Users\Peter_2\Pictures\7.5. Stadtführung.jpg'); bmp:= TBitmap.Create; try bmp.Assign(Image1.Picture.Graphic); png:= TPngImage.Create; try png.Assign(bmp); png.SaveToFile('C:\Users\Peter_2\Pictures\test.png'); bmp.SaveToFile('C:\Users\Peter_2\Pictures\test.bmp'); finally png.Free; end; finally bmp.Free; end; ShowMessage('Done'); end;

Their blog site appears to be still alive: https://components4developers.blog ..and Kim is still posting on Twitter (at least less than 2 weeks ago): https://twitter.com/comp4dev

There is no call to exit() in the code you presented. In the code you presented, you have 2 separate object instances of the A class: A a; // <-- here A & AccessA() { static A obj; // <-- here return obj; } The 1st object is being created in global scope during program startup, and the 2nd object is being created in static memory the first time AccessA() is called at runtime. The global object is created before your project's WinMain() function is executed The code presented is not calling AccessA() at all, so the compiler/linker is free to optimize it away, if it wants to. I already explained that in detail in my previous reply. Go re-read it again more carefully. Do you understand the difference between a function-try block and a normal non-function-level try block? No, there is no explicit re-throw statement in the catch block. But the catch block is performing an implicit re-throw, because you are using a function-try block instead of a normal try block: If you really want to swallow the exception, use a normal try block instead of a function-try block, eg: class A { A() noexcept { try { throw std::logic_error("test"); } catch (std::exception const &ex) { std::cout << "Caught an STL exception" << std::endl; } } }; Notice the try-catch is now inside the constructor's body, rather than around the body as in your original example.

That is normal behavior. That is also normal behavior. Calling conventions like cdecl and stdcall simply don't exist in 64bit, and they are ignored completely when used in code. There is only 1 standardized 64bit calling convention, and its behaviors are dictated by the 64bit ABI. And the 64bit calling convention indeed does not use the same name mangling rules that the 32bit cdecl calling convention uses. Use a .DEF file to control how the linker (or IMPLIB tool) formats exported names, and what internal names those exported names map to.

procedure TForm1.SomeControlEvent(Sender: TObject); begin var myLabel: TLabel; if Sender.Supports<TLabel>(myLabel) then myLabel.Caption := 'handled'; end;

I have seen the ticket, but haven't yet found the time to actually look at the code. But I definitely will. I'm grateful for any contribution to GExperts, in particular for patches that fix bugs or improve the tool.