Zeoslib Portal

Hi Folks,

This may have already been fixed but it looks like the commit labeled

"fix DateTime representation after Marks updates"

has an issue with time formats containing am/pm (basically the m part is being replaced with n causing some bugs. I'm assuming that the "Mark" in the note is me and if so, note that I didn't write almost any of that original code. I just made some fixes to make it actually work. I also have a version that removes ".0000" fractional values (slightly different than the original that trimmed trailing zeros but didn't trim the '.' and was inconsistent between simple and complex time formats.) I'm not sure if this commit is supposed to help with that or something else.

-Mark

Hello Mark,

there have been some problems with the code. Notably the tickets 482 and 478.
I think the patch tries to remedy these problems.

Best regards,

Jan

Hello Mark,
I'm working on it. I will change the logic again and implement some format-setting classes for the Connection+DataSet+Field. That should make live for user easier. Yet i'm not ready. Just FVI

What I've seen so far looks very good, nice job!

-Mark

MJFShark wrote: ↑03.02.2021, 20:47 What I've seen so far looks very good, nice job!

Thank you. I found some AV's so please update again. I had several approaches ... The committed one was the most simple as possible one for the users, i guess.

Mark as annouced i removed the AdjustSecondFractionsFormat property in the TZTimeField/TZDateTimeField. All the "magic" for the secend fractions has been moved into the TZAbstractSecondFractionFormatSettings.EscapeFractionFormat method in ZFormatSettings pas.

Honestly, your last patch did kill the display strings of the 24H representations whereas my last patch seems to disturb the 12H AM/PM formats again. Sry.

Instead of playing ping pong and always need a DB test with a field having fractions <> 0 we can now simply create a test using the
TZAbstractDateTimeFormatSettings descendant and add it to our testsuites. Yet there is no testing done except on my computer, where i tested the parent->child logic a bit.

Aim of the new classes is a kind of an inheritance model. If there are no format assigned for an Edit/Display-Format of the fields then the format of the DataSets is used. If the DataSets have no Settings the Connection settings are used. Finally if the Connection has no settings we use the non-thread safe formatsettings in SysUtils.pas what delphi/fpc are doing for T(Date/Time/DateTime)Fields.[Get/Set]String.

Now we have a local thread save FormatSettings copy in our fields.

I added an enumator:

For highlighting zeos can now use fields with up until nano fraction precsion, i decided to use the foScaleNormalized for display the values and foSetByFormat for the Field setters and getterns.

Let me know if the trouble continues. Feedback is welcome.

I really like what you've done with the ZFormatSettings stuff! It's very flexible. There are a few things I've found:

#1: In InternalGetFromFormatSettings you're scanning for 'm' and replacing with 'n', which messes up any AMPM or AM/PM formats. I've fixed it by just checking the preceding character to see if it's an a or a p and not replacing the m in those cases. Alternately it may be possible to just not do the conversion at all (I don't see where it causes a problem as long as the library routines are used for the formatting.)

#2: In EscapeFractionFormat there are a couple checks of "if FSecondFractionOption = ". Those should be "if SecondFractionOption =" so that they use the property getter and walk up to get the parent's settings when needed.

#3: There's an issue under certain conditions where the format string is having its trailing #0 char overwritten. This often doesn't cause problems, but some library routines (specifically SysUtils.FormatDateTime()) will return that character in the result if #0 doesn't terminate the Format argument. This occurs somewhere in the move statements in EscapeFractionFormat. I'm looking into this further today, but perhaps this info might help find it quicker than I can. Btw, this is my guess on what's happening, it's a bit hard to debug.

#4: If the format is 12 hour time the fractional time is added at the end instead of the correct position. This is in the same routine as #3, so perhaps they are related. In this case you end up with something like 12:34:56 AM.789.

-Mark

I put a modified version of EscapeFractionFormat into the User Patches forum. I think it fixes the #2, #3 and #4 issues that I mentioned in the last message.

-Mark

There's an issue with the foRightZerosTrimmed option in that leading zeros aren't preserved when it does the math to remove the trailing zeros. Basically it sets the scale to the number of digits left, but if the NanoFractions was 010000000 (.01 second) it gets reduced to 1 with a scale of 1 and so becomes time.1 instead of time.01.

-Mark

P.S. I added a fix for this in user patches.

Thx Mark for the feedback.

The patch is applied see: https://sourceforge.net/p/zeoslib/code-0/7355/

#1: I removed the scan.
#2: Done as suggested.
#3: that should never happen!
#4: Case closed?

Any other remarks,hints or suggestions?

Looks good, thanks! Again, I really like what you did with that whole thing. As you mentioned previously, the ability to separate out the format settings code also made it a lot easier to test in a standalone manner. One very minor thing is that I notice that the classes in ZFormatSettings require a component owner. When I made my test program I initially passed in nil as the owner and that fails with the various "(csDesigning in Owner.ComponentState)" checks. It might be useful to just add an "if Assigned(FOwner)" to those so that Owner becomes optional.

-Mark