>>> As for Clipper NG, it's seem to be a undocumented feature,
>>> because Clipper's @E formats numbers (not only dates) in British way:
>>> thousand and decimal separator are reversed.
>>>
>>> Typical formatting - 1,000,000.00
>>> British (and Polish) - 1.000.000,00
>> So what is the expect behavior for @RE? Can you
>> show an example. I can't run Clipper or xhb.
> In that case, thank you for your patience ;-)
> Expected behaviour for @RE is just like with @E alone just right now in
> Harbour.
So what is the point of @RE over @E?
(besides strict Clipper compatibility, as far as I
can see Clipper just ignores this flag for numeric
values, but I didn't make deep tests to find out the
exact rules here)
>> @ 3, 1 SAY "Works in Clipper 5.3b& Harbour (@E)"
>> @ 4, 1 GET n PICTURE "@E 99.9999 xx/y" VALID n> 0
>> READ
>
> Which effectively turns 999999 on input into [99,9999 xx/y] on the screen.
> I don't know why non-template characters are rewritten without @R in
> definition, but C5.3b works this way too.
Here is a little less than xhb, but still ugly patch for this:
Index: tget.prg
===================================================================
--- tget.prg (revision 14471)
+++ tget.prg (working copy)
@@ -1769,7 +1769,7 @@
ENDIF
IF ! Empty( ::cPicFunc )
- cChar := Left( Transform( cChar, ::cPicFunc ), 1 ) /* Left needed for @D
*/
+ cChar := Left( Transform( cChar, iif( "E" $ ::cPicFunc, StrTran(
::cPicFunc, "R" ), ::cPicFunc ) ), 1 ) /* Left needed for @D */
ENDIF
IF ! Empty( ::cPicMask )
---
I don't feel comfortable with this in its current form,
so I let someone else develop the proper patch. For me
the original version of the patched line is already a mystery.
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
