Uwe Raabe

You can, but only when creating the TJSONMarshal instance yourself. The convenient class methods ObjectToJsonString and ObjectToJsonObject abstract this away, so by using these methods you lose the flexibility. Actually I prefer registering converters per instance instead of globally, so I think in principle it is done right. It definitely lacks documentation and sometimes I wish they had avoided private methods in favor of protected virtual ones.

AFAIK there is none.

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;

and often more readable. It also has the ability to adapt to different situations or even use a better approach without the need for adjusting a plethora of code. Of course you can wrap that in a function, but that is also somehow using classes or records from a famework.

Are you sure that the bug report actually describes your problem and it really is a show stopper? According to the bug report it is something about the compiler not being able to infer the type, but explicitly mentioning the type works. How can that be a show stopper? Nevertheless, as long as you are on an active subscription you have three support incidents per year included. You can burn one of them to ask for an individual fix for that issue, although there is no guarantee that this will succeed.

Probably yes. In that case it would override any other setting and looking for those would be senseless. That would be the only option I can think of implementing. You shouldn't hold your breath for it, though. The theme support involves a complete re-architecture of the toolbar system and may force fixed toolbars in the first iterations anyway - possibly staying that way if there are not too much complaints. That doesn't forbid a toolbar customization of course. Well, I don't and I cannot see anything justifying to handle this tool different than any other tool - which is simply: As long as there are no incompatibilities caused by MMX I don't care about it being installed or not.

In that case they sometimes have to live with the drawbacks then.

No chance! It is difficult enough for MMX to adhere to its own settings and in some cases MMX even tries to adhere to the IDE settings. Why should I take the burden to look after some settings from any other 3rd party tool, especially one that I don't use by myself nor am planning to do so? What if several plugins offer such a functionality, which one to prefer? What if none of these is installed at all? Should MMX provide a similar setting for its own?

Well, we don't like the code change either - not only for the lack of FItems being inspected during debugging. The point is that the debugger is not the right place to put the finger on. I wonder how the debugger could figure out that the fields FItems, FCount and FTypeInfo have to be merged into something like TArray<T>. On the other hand: TList<T> already provides a property List which has all things necessary in one place. If the evaluation were not restricted to variables and fields only, but could be extended to properties and functions, that would have much more value than just inspecting those TList items.

That has nothing to do with the IDE. It is a change in the RTL sources and the field you are trying to inspect is a Pointer, which the debugger correctly shows as a hex address. Since your report suggests an error in the "Debugger, Delphi Compiler, IDE (Development Environment)" it simply targets the wrong people and will correctly be closed. There simply is no bug in the debugger, compiler or IDE in this case.

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.

The debugger is just doing fine here. Since 10.3 there is no FItems field anymore, so there is nothing the debugger can show. You can inspect the property List, though. Unfortunately that will not work using the hint window.

Are people still using that old component pallet? Why don't you just file a QP report for that? What makes you think that I would do something different?

This option is not available in my Delphi. Perhaps a 3rd party plugin?

That Lock Toolbar option is probably not standard, is it?

Well, we still have IDE Insight. Press F6 or Strg-<dot> and enter navi: You will get a list where one element is the mentioned one (it is the last one in my case). Select and press enter and you are at the right place.

Exactly! But as you asked for it: The RiverSoftAVG SVG Component Library, which also includes some SVG image list, comes with source for a price of $66. I didn't compare the feature list, though.

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

Me too! And full source includes not only the library itself, but also things like the design time editors.

Perhaps I overlooked something, but does the library come with full source code?

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

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?

How is this supposed to work when the number of visible lines is less than the number of lines in the interface/implementation section? A simple marker line (I would suggest something like a plain horizontal line to avoid wasting a full text line) will scroll out of view. I was thinking of different text and/or background colors for interface and implementation, but the styling system doesn't really like custom coloring. It often looks pretty poor in at least one of the standard themes. Perhaps we can adopt some of the syntax highlighter settings? This would honor the fact that the editor can have a different color scheme than the IDE itself.

Your original request has been At the moment you are ranting about button colors, images and image sizes. I am out now.