Leaderboard

The best open source Delphi parser I know is DelphiAST. It is the foundation https://www.tmssoftware.com/site/fixinsight.asp which catches way more code issues than the Delphi compiler itself does. DelphiAST gets you an abstract syntax tree. Code is at https://github.com/RomanYankovsky/DelphiAST

Having worked in Delphi since D1, and twice having had to deal with the issue of components without source, I would say that the value without source is essentially zero, as the risk factor is not worth any benefits in the short term. So I would suggest that the question as you ask it is simply wrong.

As Jeroen already mentioned: use DelphiAST - that is based on the Castalia parser code which was based on Martin Waldenburgs code. It is used and maintained by the author of FixInsight and many others and can handle any Delphi code out there. It had a lot of fixes due to it being used in FixInsight which is widely used by numerous people. It even supports inline variables (hello Error Insight!)

Kick those lazy bastards into the ass! 😉 As a workaround you could add a {$warnings off} and {$hints off} into theses 3rd party units.

Hi developers, Have you ever encountered problems because your interface changes with high DPI but your images remains on the same size? Have you ever wanted to add incredible animations to your interface, but have been frustrated by the limited possibilities of the proposed image formats? So there is a library for you. SVG Magic brings the support of the Scalable Vector Graphics (SVG) image format to the C++ and Delphi VCL. Please visit: https://svgmagic.io/

Hi to the Community Manager, There seems to still be an active interest in the TurboPower component sets. Is there a chance of a TurboPower Tools sub forum under Delphi Third-Party which then subsets into the various TurboPower Component Packs.? Regards & Tks for considering. Ian

In some piece of code somewhere, a pointer was set to $DEADBEEF, most likely after the object it was pointing to had been freed, and then that same pointer was used afterwards by code running at address $0040CEEC trying to access a data member at offset -8 ($DEADBEE7) via that pointer. Magic addresses like $DEADBEEF are commonly used for debugging such mistakes. In this case, the code at address $0040CEEC is the System._UStrAsg() function, which is used to assign a UnicodeString to another UnicodeString. Offset -8 is the StrRec.refCount field in the UnicodeString data header, which makes sense as UStrAsg() does increment that field. In other words, some piece of code tried to assign a UnicodeString value to a dead UnicodeString variable. UStrAsg() was called by TFieldValue.SetValue(), so SetValue() was likely called on an invalid TFieldValue object inside of TGridSet.CopyRow(), which was called by TDeliverySet.UpdateFromDeliverySet() inside of TDeliveryGrid.RefreshByRouteList(). So, start in RefreshByRouteList() and work your way into UpdateFromDeliverySet() and try to figure out how it may be accessing an invalid TFieldValue object. The Operation System, when the invalid memory address $DEADBEE7 is accessed. Delphi's RTL catches that error from the OS, creates an EAccessViolation object for it, and then raises it.

No, the debugger can only show fields in a class that exist. That FItems field you see in 10.3 is not part of TList<T>, but of TListHelper and declared as FItems: Pointer; So what other than that pointer address should the debugger show here? It is a complete different thing to argue about that code change in the first place, but that is out of scope here. There have already been some other issues following up this change.

Is that before or after hell freezes over or easter and christmas are on the same day?

There would be quite a lot of useful things that could be done if there was an up to date parser for Delphi code. Unfortunately there apparently isn't. I tried to update Martin Waldenburg's parser, which is used in GExperts, but it's just not easy to do. The Castalia parser, which is based on MW's parser unfortunately is incompatible in too many places to use as a replacement without too many changes. But by the look of it, it supports more recent language constructs. It's still not complete though, and definitely doesn't support the latest additions.

"Sometimes" is a word I can relate to. So please consider this post a "consoled face" 😉 This is the essence: Don't we all have the feeling that Emborcagear is not really dogfooding? This gets obvious when the (FMX) example projects wont compile...something an automated script should pick up in the pre beta phase. The needed changes there could easily be expanded to a "How to cope with our latest breaking changes". And if that is not possible something is rotten in the state of Denmark.

Breaking changes always come at a cost, and there will always be complaints. But few of us are prescient, and there comes a time -- as when DevExpress replaced the dxGrid with the cxGrid -- when the need to incur the breakage overpowers the costs. When an architecture proves too limiting, or too brittle, then carrying it forward is no kindness. But as Stefan wrote: "...it then is an important responsibility to document them and if necessary provide some tooling to migrate your code..."

Funny that you bring up that DevExpress change - I remember upgrading our software and it was a non-issue. And in fact the "what's new" for that version explains exactly what to do. Not saying any of us is right or wrong but you can see that something is a huge issue for one and none for another. Yes, there is always some bad code that did not follow best practices or did not properly encapsulate something, leak an implementation detail or does something else making it a chore to move forward. But that is exactly why I wrote what I wrote 2 posts ago. You can always come up with an excuse (valid or not) to damn some breaking change. However sometimes you have to take the bitter pill to move forward painlessly either yourself or the library/framework developer that decided for such a change. I for example will introduce quite some breaking changes for the next version of Spring4D and I experienced them myself when migrating a branch of our software to an early version and experienced all the required work. I even reverted some change because I saw that it was rather painful to find all the places and convert them easily. That means as a developer of a component/library/framework you should use that yourself in more than a toy project to get a feeling what consequences possible changes have to evaluate if they should be taken or not. And it then is an important responsibility to document them and if necessary provide some tooling to migrate your code - I remember more than 10 years ago when moving from QuantumGrid 3 to 4 (I think) DevExpress provided a tool to convert all your code for that heavy breaking changes that came with that version change. If they would not have done that, I guess no existing customer would have done it - however I cannot tell about the problems that still existed, I joined the company when the change was done already.

For once I have to wholeheartedly agree with Rudy - I have to mark that on my calendar.

I always build 3rd party sources with the project. That's the only way I can be sure that the executable is based on the code it is supposed to be. And since compile times in Delphi are really short, it doesn't have any drawbacks in my opinion.

What do you mean by "log filled with various warnings"? Do you really have more than a hand full? That's the first thing I kick a coworker's ass for, if it gehts checked in to SCM. OK, a possible solution would be to configure these hints / warnings you are really interested into be errors in the project configuration -> Building -> Delphi Compiler -> Hints and Warnings. edit: Apparently that's not possible for hints but only for warnings.

Good thing you're not in charge of the RTL then. IRL backward compatibility matters.

The Spring4D approach uses roughly the same principle - comparing the base method and derived method to see if they are located at the same memory address or not - but it goes about doing so in a very different and more intrusive manner. It manually looks for the base method address in the base class's vtable to get the method's index within the vtable, and then it retrieves the address stored in the vtable of the derived class at the same index, and then compares the two addresses. The Seek() approach is cleaner in that it lets the compiler deal with the vtable details.

To expand on Anders' comment - the TStream.Seek() method has two overloads, one for 32-bit seeks and one for 64-bit seeks. By default, the 32-bit Seek() calls the 64-bit Seek() and vice versa. Descendants must override one of the Seek() methods and the override must not call the inherited method. To avoid an endless recursive loop, the 32-bit Seek() validates that the 64-bit Seek() method has been overridden before calling it. This is the technique that it uses for that validation: procedure TAncestor.Do(); type TMethodXType = procedure of object; // must match the signature of MethodX... var Impl: TMethodXType; Base: TMethodXType; ClassTAncestor: TClass; begin Impl := MethodX; // points to descendant's implementation of MethodX... ClassTAncestor := Self.ClassType; // get object's actual class type... while (ClassTAncestor <> nil) and (ClassTAncestor <> TAncestor) do // find the TAncestor base class... ClassTAncestor := ClassTAncestor.ClassParent; Base := TAncestor(@ClassTAncestor).MethodX; // points to TAncestor's implementation of MethodX... if TMethod(Impl).Code = TMethod(Base).Code then // which MethodX implementation is the object actually using? begin // MethodX is NOT overriden... end else begin // MethodX IS overriden... end; end;

IsVirtualMethodOverride from Spring.VirtualClass.pas procedure TAncestor.Do; begin Writeln(IsVirtualMethodOverride(TAncestor, ClassType, @TAncestor.MethodX)); end;

I would not have done that. I would have let the code break.