Leaderboard

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.

It‘s from CnPack.

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

YES, backward compatibility matters. But in cases where backward compatibility causes more trouble down the road, then it is not worth the price. In this case, maintaining backward compatibility also opened TStream and descendant classes to subtle bugs when working with streams larger than 2GB.

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

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..."

Collecting from the uses clauses will yield the list of all units referenced in the project modules, but parsing the map file is the simplest way I know to discover which units participate in the finished executable.

In Tools - Options - User Interface - Editor Options - Display uncheck Show Navigation Toolbar

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.

Why are you rebuilding 3rd-party dcus as part of your build process? IMO only the (prebuild) DCUs should be on the IDE library path, the source code folders should only be on the IDE search path and not on the project's search path.

Why would you bother some unused variables if you can live with those warnings? btw. copy paste into a text file and grep

"Backwards compatibility" is the ultimate excuse to pile up garbage in your backyard ... It is used or ignored whenever convenient - moving forward also includes getting a compile error in your face but with a clear guide at hand how to solve it. If you ever inherited from a TDataSet and used one of its method that have TBookmark or TRecordBuffer arguments while writing code for different Delphi versions since 2010 or so you know what I mean. But some developers seem to rather want to save an hour when moving their code to a new version and waste hours or days later hunting down a bug. 😉

That change was not worth while even back then. You had two variants for Seek and it was very easy to use wrong one. If you used 32 bit one on streams that support 64 bit your code would only work for streams smaller than 2GB. Change didn't affected older code, but it had permanent negative effect on new code. I encountered such bugs myself, and also have seen others bumping into it on numerous occasions. Yes, at the end our code was at fault, but it was really easy mistake to make. There was several bug reports around that issue at the time in old Quality Central.

You're missing the point. The purpose was to provide backward compatibility for existing descendants of TStream - not existing code using TStream.

Perhaps. It was so long ago, we don't know what their actual thinking was. Such a change would break existing implementations, forcing rewrites. It was probably the lesser of two evils at the time to introduce the overload to maintain compatibility rather than force people to update their code. Of course, the issue wasn't helped when a 3rd Seek overload was added in XE4, causing ambiguity errors under OSX/iOS 64bit for user code that was never updated to use the original overload added in D6. Speaking from experience, I'm in a similar boat right now, where I have to update a legacy product with a huge codebase to migrate it from using 32bit ints to 64bit ints, and it is going to be a MAJOR undertaking, affecting databases and external APIs, and requiring rewrites of internal logic in various places. Who would have thought 20 years ago that our customer data would ever need to exceed the limits of 10 digit integers, but it has for some time now and we have worked around the problem over the years by truncating data in various ways to maintain compatibility, instead of redesign the system. We finally looked at a redesign awhile ago, but all of our team members have been let go or moved to other teams before it was viable. Now a redesign is being looked at again and I'm the only one left to work on it. So, it is not always an easy task to replace code rather than overload code.

If it's not available with full source code, I'm not going to buy it. I have been burned twice with buying components / libraries in binary form only where the company went bust a few years later. Apart from that I like the idea of using SVG for graphics a lot. It would solve several problems I am currently facing.

It was done this way for backwards compatibility when TStream was first updated to support 64bit streams. Since all implementations and uses of TStream were based on 32bit operations at the time (to this day, some TStream implementations are still 32bit only - ahem, TMemoryStream), when the new 64bit Seek was added, nobody overrode it yet, so it would call the 32bit Seek by default so existing implementations would still work. Once a stream class was updated to override the 64bit Seek instead of the 32bit Seek, the 32bit Seek would then call the 64bit Seek by default, thus still maintaining compatibility with existing code. The 32bit Seek checking if the 64bit Seek is overriden before calling it is just a safety catch to avoid a recursive loop should an implementation make the mistake of not overriding either version of Seek correctly.

As I said: those two icons are already used elsewhere to mark the interface and implementation section and should thus be immediately recognized. Why should I introduce alternative icons here?

The Plus and Minus signs are taken from the UML specification for public and private. The colors are just a visual enhancement. These icons are used all over the place, especially for the Delphi class visibility: They are not related to expanding or collapsing the tree structure (spot the down arrow in front of the Module node in the content tree screenshot above).

Well, you have been given some examples, but my question is: WHY do you want to know this? The whole point of polymorphism is that in the base class you do not need to know whether a descendant has overriden the method or not. In fact the base class does not even know whether there are descendents of it, and neither should it care. If you think you need to know whether a method has been overridden in descendents something is wrong with your class design, IMO.

What about showing symbols as used in the contents tree? They can be placed somewhere between the Match, Line or Source column. The Yellow Plus symbol signals interface while the Blue Minus stands for implementation. That would waste only a little bit of real estate. Not sure what you refer to with "other scopes". Can you name some?

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;

Yes, definitely! It is just quite some work to do.

This is actually an error in the Navigation Toolbar Keybindings that are integrated in the IDE since Delphi 10 Seattle. It happens when these bindings are not the first in the bindings queue. This error does exist for quite a while when MMX and Castalia are installed side by side in the IDE. As a workaround, make sure that MMX Code Explorer is uninstalled. Start the IDE, disable the Navigation Toolbar Keybindings and install MMX again. Another approach avoiding the uninstall/install cycle requires a bit of fiddling around with the registry: Open the registry and locate the appropriate BDS key. Open Editor -> Options -> Known Editor Enhancements -> MMX.CodeExplorer and set the Enabled value to 0. That will prohibit the MMX keybindings to be registered. Now the IDE should start. When the IDE is running go to Tools -> Options -> User Interface -> Editor Options -> Key Mappings. In the list Enhancement Modules move MMX Code Explorer to the last (bottom) position and enable it again. Hope that helps. The next release will have a fix that assures MMX not overtaking the Navigation Toolbar Keybindings in the first place.

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