Search the Community

Hi there, I've got a strange exception, only with Android 32-Bit during Debugging, other platforms including IOS work well. With iOS 64 I had no issue seen, but wouldn't count on it right now. I use a TDateTime variable, and want to compare against NULL.. Since TDateTime is a Double with 8 Bytes, a simple cast to Double( Self ) should make not any harm. Maybe there are special conditions on Android, as Extended is reduced to Double, and maybe there are some conversion side effects with Double as well ? I use a class helper for adding such functionality, which is used in a million other places too. function TDateTime_Helper.ToDouble : Double; begin Result := Double( Self ); // Here it crashes, see images enclosed, they only have 2 ARM assembler lines end; and I already extended my conversion routing to separated local variables: // global variable for storage, only reading var LUNull : TDateTime = TDateTime( 0.0 ); class function TDateTime_Helper.Create_Null : TDateTime; begin Result := LUNull; // Could the global variable cause issues in a Thread ? Buts its readonly. end; function TDateTime_Helper.IsNull : Boolean; var LSelf : Double; LNull : Double; begin LSelf := Self.ToDouble; //11.03.20 added local variables, to check Android crash LNull := Create_Null.ToDouble; if SameValue( LSelf, LNull ) then Result := True else Result := False; end; I check a variable, which is called in a thread if FLastUpdate.IsNull then // called like this begin .... end I must confess that I use above scheme in many thousands of places, also heavily within threads (even higher loded), without an error before. The caller can be debugged very reliable, and the error is very reproducable When the caller comes in first, second, third time, with zero, all is fine When the caller comes in with a real Double value, I can debug and see a valid double value in the watch (e.g. FLastUpdate = 43901.1603147338 ) Inside the conversion ToDouble it crashes When entering with Zero, it looks like the images img. 1 and 2 (see the registers changing) When entering with Date, it looks like img. 3, and immediately it crashes at img. 4 What could cause such error, it sounds a little like failure of JNI Bus, but maybe I'M totally on the wrong track ? Probably there is some genius with a good hint how to fix this nasty bug.

Consider this pseudo code uses Rest.Json; TDateClass = class private FHasDate: TDateTime; FNoDate: TDateTIme; public constructor Create; property HasDate: TDateTime read FHasDate write FHasDate; property NoDate: TDateTime read FNoDate write FNoDate; end; constructor TDateClass.Create; begin HasDate := Now; NoDate := 0; end; var Json: String; DateClass: TDateClass; begin DateClass := TDateClass.Create; Json := TJson.ObjectToJsonString(Self, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601]); which results in the Json string looking like { "HasDate":"2019-02-14T06:09:00.000Z", "NoDate":"1899-12-30T00:00:00.000Z", } while the ideal result would be { "HasDate":"2019-02-14T06:09:00.000Z", } Q:Is there a way to make TDateTime properties with a zero value be output as an empty string - and hence be stripped?