Uwe Raabe

So you want the output of "new way" be the same as in "current way"? Can you provide a small but working example program producing both of the above outputs?

That is why those files have to be copied into the builded_dcu folder. You can see the same issue with the standard library folders of the Delphi DCUs. The DFM and RES files can also be found there.

Why don't you use MultiPaste in the first place and let it add the comma after each line. Then you end up with only one remaining error for the semicolon at the last line.

Will have a look when I am back next week.

The two classes are probably already existing classes derived from TDataSet with only a very little chance to adjust that.

Indeed, when you ask for the date you will get 0 even when the DB field is NULL: function TDateTimeField.GetAsDateTime: TDateTime; begin if not GetValue(Result) then Result := 0; end; Unfortunately you cannot distinguish that from a valid date (unless you narrow the range for those). I would prefer when the above function would actually return a non-valid date in that case, but I guess that would break compatibility. Meanwhile, the trick is not to ask for a date in the first place when the field is NULL. To store such an invalid date into a TDateTime field the NullDate approach is quite valid. Actually any value below -DateDelta ( = 693594) would do, as it results in a non-positive Date part of a TTimeStamp and makes DecodeDateFully return false. The chosen value of NullDate = -700000 ist just a bit easier to remember.

There is a similar constant in Vcl.WinXCalendars.pas, albeit only private. I recently had a case where that 0 DateTime value was used instead of NULL in a database. As long as you are keen to update all your customers databases, you better stay with that value and its meaning.

That is somewhat against the introducing condition ruling that option out in the first place.

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.