Leaderboard

Just in time before April fools day 2019 there is the new GExperts release (it’s still 2019-03-30 so you are safe 😉 ). Please be aware that I mostly work with Delphi 2007, so this version can be regarded as tested quite well, followed by Delphi XE2. The others are only known to compile and new features are usually tested superficially with all versions. This is particularly true for Delphi 6/7 and 2005/2006. If you want to help by testing new versions before I release them, please contact me [...] https://blog.dummzeuch.de/2019/03/30/gexperts-1-3-13-experimental-twm-2019-03-30-released/

My apologies. The toolbar in question is in CnPack, not in GExperts.

fixed

Another thing... you are asking confirmation for some design approach that didn't feel right at the end. If it does not feel right, there is probably something wrong and it is quite likely that composition would be better choice. If composition solved your problem, probably it IS the right choice and the next time you encounter similar situation it will probably be right choice again. But, without seeing actual code and knowing the context in which it will be used, it is really impossible for us to say one way or the other.

Err.... No... You started with prefer, now you have come to always... and you are conditioning yourself to use composition without considering inheritance... you should consider both at the same time. There are always trade offs and you have to take those into account. If you start with composition and say, OK composition can solve this problem, I am all done, at some point you will make wrong choice because sometimes inheritance will be better fit. Now, I could be wrong, I don't know what is in your head... The more skill one has.. the easier is to decide... Sometimes you will just take a glimpse on some problem and you will immediately know what is the proper solution... but just because you are able to decide fast, that does not mean that you didn't fully considered all consequences of particular solution. Again, while rules help you have to be careful with the rules. They cannot save you from thinking and using the best tool for the job. I don't know how many times I used inheritance over composition or vice versa, I am not counting... it is irrelevant... even if 90% of the time composition is better, that still leaves you with 10% where it is not.

Hello Steve, I would be very willing to help. If you need a high grade commercial solution, my UberPDF engine is quite good, and based on 33 years of PostScript and PDF code. I am just one guy and I spend most of my time coding PDF solutions rather than tweaking the web site for product sales. If you need "very good", the UberPDF SDK fits the bill. But please know, It is not some cheap Delphi PDF knockoff solution. We take things very seriously when it comes to PDF, and our goal is to deliver a "quality commercial grade" solution. Delphi support is a "bonus" (I am a former Borland engineer and I love Delphi), so I support Delphi (and Lazarus). The SDK is a "maturing" solution. It has been used for many years under a different name, and has enjoyed many millions of deployments. Currently, we offer the SDK "on the cheap", but the price is quickly is rising as I add features (from a code base of 3 million lines of commercial PDF code) . End user sales is not our primary goal (our market is large commercial customers), so there are currently no "Delphi demos". But if you need "very good", and you like being able to contact the guy writing the engine and getting custom support (and new features tailored to your needs), consider joining our little family of users, and growing with us. We do not have everything plugged in yet, but you can count on a SDK that is written 'by the book", and to exacting PDF specifications (per the reference), by a guy who has three decades of experience. I can be initially reached though our email gateway at https://uberpdf.org/email/

https://stackoverflow.com/a/4497572/505088

I even think that that rule is too strict. It really depends on the situation, and one should not take preference over the other by some rule like that.

There is a bit more to it than simply following a mantra - here is some more food for thought: https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose

Here is an example: https://stackoverflow.com/questions/9906312/delphi-vcl-styles-tutorial-how-to-change-the-style-at-runtime

Little Endian vs Big Endian. Simply swap the bytes around. You don't need to convert anything. TTagResult has a UIDasBytes field to access the raw 8 bytes of the UID. Simply pass that field as-is to the function that wants the bytes.

There is a possibility, but it would be difficult to apply that behavior on any TDateTime field to be converted, which could as well be a pretty unwanted side effect. Instead you can put an attribute to each field being treated this way. What you need here are two classes (well, one would do, but the second one simplifies things a lot). The first one is the interceptor: type TSuppressZeroDateInterceptor = class(TJSONInterceptor) public function StringConverter(Data: TObject; Field: string): string; override; procedure StringReverter(Data: TObject; Field: string; Arg: string); override; end; function TSuppressZeroDateInterceptor.StringConverter(Data: TObject; Field: string): string; var ctx: TRTTIContext; date: TDateTime; begin date := ctx.GetType(Data.ClassType).GetField(Field).GetValue(Data).AsType<TDateTime>; if date = 0 then begin result := EmptyStr; end else begin result := DateToISO8601(date, True); end; end; procedure TSuppressZeroDateInterceptor.StringReverter(Data: TObject; Field, Arg: string); var ctx: TRTTIContext; date: TDateTime; begin if Arg.IsEmpty then begin date := 0; end else begin date := ISO8601ToDate(Arg, True); end; ctx.GetType(Data.ClassType).GetField(Field).SetValue(Data, date); end; The second one is a special attribute: type SuppressZeroAttribute = class(JsonReflectAttribute) public constructor Create; end; constructor SuppressZeroAttribute.Create; begin inherited Create(ctString, rtString, TSuppressZeroDateInterceptor); end; Now you can decorate your class fields like this: type TDateClass = class private [SuppressZero] FHasDate: TDateTime; [SuppressZero] FNoDate: TDateTime; public constructor Create; property HasDate: TDateTime read FHasDate write FHasDate; property NoDate: TDateTime read FNoDate write FNoDate; end; As I mentioned earlier, you can omit the new attribute and use the JsonReflectAttribute directly, but that is a bit cumbersome: type TDateClass = class private [JsonReflect(ctString, rtString, TSuppressZeroDateInterceptor)] FHasDate: TDateTime; [JsonReflect(ctString, rtString, TSuppressZeroDateInterceptor)] FNoDate: TDateTime; public constructor Create; property HasDate: TDateTime read FHasDate write FHasDate; property NoDate: TDateTime read FNoDate write FNoDate; end;

This issue was fixed now, and a new version was released today. Once again, thank you for showing me this error.