Leaderboard

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;

Original post: https://www.thedelphigeek.com/2019/02/design-patterns-with-delphi-book.html Hurrah, hurray, my third book is here! It’s called Hands-On Design Patterns with Delphi and (just like my first book) I wrote it for Packt Publishing. (The second book was self-published and I expect the fourth one to be, too.) As the name says, “Design Patterns with Delphi” deals with design patterns. It is a bit different from most of design pattern books and websites you will find on the Internet. Case in point A: There are no UML diagrams. I don‘t speak UML. Tried to learn it few times but for some reason the whole concept doesn‘t agree with me. If you like diagrams, don’t fear though. Any book on design patterns - and most websites covering that topic - will gladly show how any design pattern can be diagrammed. That, however, is not important and should not govern your decision to buy the book. More important is case in point B: This book speaks Delphi. All the examples are written in Delphi and language features are used to the full. I also covered few less known Delphi idioms in separate sections. You’ll still be able to follow the discussion even though you may program in a different Pascal dialect. There’s also case in point 😄 Examples make sense. I deeply dislike classical design pattern examples of the “And then we want to write this program for different toolkits and it should also be able to draw circles, not only squares” kind. Euch! I tried to find a good example for each design pattern. Admittedly, I ended with few examples that draw triangles and squares on screen (mostly because some patterns were designed specifically for solving such problems), but most of them are of a more practical nature. This book covers all three classical design pattern categories - Creational patterns, Structural patterns, and Behavioral patterns. It also discusses patterns from the newer Concurrency patterns category. At the end I threw in some borderline-pattern(ish) topics and ended with a discussion of few patterns that cannot be strictly classified as “design” patterns. In this book you’ll find: Chapter 1 An introduction to patterns. Exploration of design principles, design patterns, and idioms. A mention of anti-patterns. A short description of most important design principles. Delphi idioms: creating and destroying objects. Chapter 2 Creation patterns part 1. Singleton. Dependency injection. Lazy initialization. Object pool. Chapter 3 Creation patterns part 2. Factory method, Abstract factory, Prototype, Builder. Delphi idioms: Assign and AssignTo. Chapter 4 Structural patterns part 1. Composite. Flyweight. Marker interface. Bridge. Delphi idioms: comparers and hashers. Chapter 5 Structure patterns part 2. Adapter. Proxy. Decorator. Facade. Delphi idioms: replacing components in runtime. Also: helpers. Chapter 6 Behavioral patterns part 1. Null object. Template method. Command. State. Chapter 7 Behavioral patterns part 2. Iterator. Visitor. Observer. Memento. Delphi idioms: for .. in. Chapter 8 Concurrency patterns part 1. Locking. Lock striping. Double-checked locking. Optimistic locking. Readers-writers lock. Delphi idioms: tasks and threads. Also: bitwise operators. Chapter 9 Concurrency patterns part 2. Thread pool. Messaging. Future. Pipeline. Chapter 10 Writing Delphi programs. Event-driven programming. Actions. LiveBindings. Form inheritance. Frames. Data modules. Chapter 11 Wrapping it up. Exceptions. Debugging. Functional programming. I hope you will like this book and learn a lot from it. I know I did during the nine months I spent writing it. And if you find any bug in the code, let me know so I can correct it in the second release!

Hi Developers, Deleaker was created in 2006, and is been support Visual Studio from the very first release. Now it's time to find leaks in Delphi and C++ Builder! Deleaker finds memory leaks, leaks of GDI and USER32 resources, handles and many others. Deleaker fully integrates with RAD Studio. Here the official announcement: https://www.deleaker.com/blog/2019/03/11/integration-with-rad-studio/ Let's look how it works! Download Deleaker and launch it. Now you can select versions of RAD Studio you want Deleaker to integrate with. Of course, RAD Studio Rio 10.3 is supported: Deleaker is installed, let's launch Delphi: Great, Deleaker is here: Let's add some leaks: Start debugging, click the button, exit. Deleaker is taking a snapshot: Two leaks are shown as expected. It's easy to navigate to source of a leak: Happy coding!

...or just see TStream.Seek(Longint, Word) in classes.pas.

It also happend here... but no way to reproduce !

No. I have also noted that in 10.3 toolbars sometimes start jumping from line to line even without layout switching, just by moving mouse somethere. But this is not reproducable. As I don't use 10.3 as a primary IDE, I can only say that 10.1 does not suffer from this problem (and other bugs introduced in later releases).

The MMX Module Analyzer actually uses this approach. In the other hand there is the Unit Dependency Analyzer that actually parses the uses clauses to build the dependency tree.

A word of warning to those (I'm counting 50 since yesterday) that downloaded this version: If your resources contains bitmaps that were created by older versions of Delphi (or rather applications built with older versions of Delphi) then the resource editor might corrupt them on save. It appears that a bug was introduced in TBitmap between Delphi 2009 and 10.2. Here's the short version: The format of a windows bitmap is basically 1) Header, 2) Color table, 3) Pixel data. For bitmaps with PixelFormat>pf8bit the color table is optional. The Header specifies the number of colors in the color table (the TBitmapInfoHeader.biClrUsed field). Older versions of Delphi sometimes saved bitmaps in pf24bit/pf32bit format with a color table and the corresponding value in the biClrUsed field. This was unnecessary but harmless and perfectly legal according to the bitmap specs. Here's an example of what such a bitmap might look like: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] These bitmaps can be read by newer versions of Delphi, but when the bitmaps are written again they become corrupt. Delphi keeps the value in the biClrUsed field but fails to write the corresponding color table. The result is that the pixel data ends up at the wrong file offset. Here's an example of a corrupt bitmap: [File header] [Bitmap header, biClrUsed=16, biBitCount=32] [Pixel data] The reason why this is a problem for the resource editor is that it is built with Delphi 10.2. I have a fix for the problem but I'm not ready to release a new version with the fix. Here's the fix btw: // Fix for bug in TBitmap. // Saving bitmap with PixelFormat>pf8bit with biClrUsed>0 fails to save the color table // leading to a corrupt bitmap. type TBitmapColorTableBugFixer = class helper for TBitmap type TBitmapImageCracker = class(TBitmapImage); public function FixColorTable: boolean; end; function TBitmapColorTableBugFixer.FixColorTable: boolean; begin if (TBitmapImageCracker(FImage).FDIB.dsBmih.biBitCount > 8) and (TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed <> 0) then begin TBitmapImageCracker(FImage).FDIB.dsBmih.biClrUsed := 0; Result := True; end else Result := False; end; The problem appears to be the same one reported here: Setting TBitmap.PixelFormat can lead to later image corruption or EReadError