I have a problem with numeric pictures. With N6`2 the c2j compiler would complain, with N6.2 it's OK. Is the c2j supporting the grave accent for numeric places?
thanks
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated the numberformat.java and cwin.java.
It's still not working. I have also tried to do mvn clean on runtime and compiler.
This is my window
QuickWindow WINDOW('Form gloparam'),AT(,,355,180),FONT('Tahoma',,,,CHARSET:EASTEUROPE),CENTER,IMM,HLP('UpdGlp'),SYSTEM,GRAY,DOUBLE,MDI
SHEET,AT(4,4,350,158),USE(?CurrentTab)
TAB,USE(?Tab:1)
PROMPT('matična firma:'),AT(8,21,113,10),USE(?glp:matfirma:Prompt),TRN
ENTRY(@s100),AT(148,21,202,12),USE(glp:matfirma),LEFT(2),MSG('naziv matične firme'),TIP('naziv matične firme'),REQ
PROMPT('oib:'),AT(8,35,113,10),USE(?glp:oib:Prompt),TRN
ENTRY(@s20),AT(148,35,111,12),USE(glp:oib),LEFT(2),MSG('oib'),TIP('oib'),REQ
PROMPT('banka:'),AT(8,49,113,10),USE(?glp:banka:Prompt),TRN
ENTRY(@s100),AT(148,49,202,12),USE(glp:banka),LEFT(2),MSG('naziv banke'),TIP('naziv banke'),REQ
PROMPT('domaća valuta:'),AT(8,63,113,10),USE(?glp:dom_valuta:Prompt),TRN
ENTRY(@s3),AT(148,63,40,12),USE(glp:dom_valuta),LEFT(2),MSG('domaća valuta'),TIP('domaća valuta'),REQ
OPTION('mjenjački poslovi'),AT(148,77,91,36),USE(glp:mjenjacki_poslovi),BOXED,TRN,MSG('tip mjenjačkih poslova'),TIP('tip mjenjačkih poslova')
RADIO('Otkup i prodaja'),AT(152,88),USE(?glp:mjenjacki_poslovi:Radio1),TRN,VALUE('1')
RADIO('Otkup'),AT(152,99),USE(?glp:mjenjacki_poslovi:Radio2),TRN,VALUE('2')
END
PROMPT('<154>ifra:'),AT(21,86),USE(?glp:sifra:Prompt),TRN,HIDE
STRING(@n14),AT(45,85,60,10),USE(glp:sifra),TRN,HIDE,RIGHT(1)
PROMPT('defaultni postotak provizije:'),AT(8,115,113,10),USE(?glp:def_pst_provizije:Prompt)
ENTRY(@n6`2),AT(148,114,41,12),USE(glp:def_postotak_provizije),RIGHT(2),MSG('defaultni postotak provizije'),TIP('defaultni postotak provizije')
PROMPT('defaultna vrsta čekova:'),AT(8,131,113,10),USE(?glp:def_vrsta_cekova:Prompt),TRN
ENTRY(@n14),AT(148,131,41,12),USE(glp:def_vrsta_cekova),RIGHT(2),MSG('defaultna vrsta čekova'),TIP('defaultna vrsta čekova'),REQ
PROMPT('port number za komunikaciju sa IQ:'),AT(8,146,129,10),USE(?glp:portNum:Prompt),TRN
ENTRY(@n14),AT(148,146,41,12),USE(glp:portNum),RIGHT(2),MSG('port number za komunikaciju sa IQ'),TIP('port number za komunikaciju sa IQ')
END
END
BUTTON('&Prihvati'),AT(209,164,70,14),USE(?OK),LEFT,MSG('Prihvati unesene podatke'),TIP('Prihvati unesene podatke'),ICON('tick.png'),DEFAULT
BUTTON('&Odustani'),AT(284,164,70,14),USE(?Cancel),LEFT,MSG('Odustani od operacije'),TIP('Odustani od operacije'),ICON('cross.png')
END
The glp:def_postotak_provizije has the grave accent. The exact error is lang.ClarionCompileError: expected ')' near line:40
where line 40 is the ENTRY(@n6`2),AT(148,114,41,12),USE(glp:def_postotak_provizije)
glp:def_postotak_provizije is DECIMAL(5,2)
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apologies, I fixed the runtime processing of number pictures, but not compile time. They are in two separate locations.
Just checked in a new fix into runtime. Recompile runtime.
Also make sure that you recompile compiler and plugin. And update your pom to refer to newest plugin : 1.21-SNAPSHOT. I justed checked in new poms for these to make sure they refer to latest runtime.
I tested it with following program: it works as expected.
programcodemessage(format(100.4,@n6`2))
c2j handling of decimals with ',' as separator is poorly tested because it is not something I use myself. I just discovered one bug with it which I just fixed. Keep an eye out for others. Particularly I am not sure if my implementation of deformat is correct. i.e. currently in tests is the following test:
These tests imply that 123.45 should not deformat, but 123,45 should. I am uncertain as to what correct behaviour should be. Changing code is simple though should it be necessary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's still not good. Now it compiles but when i type in sequence 12345,67 i get on screen 12,345,67 while i should get 12.345,67
I have tried this with REAL variable and picture @n-17`2
However the value of the variable is correct i.e it is 12345 integer parts and 67decimal part
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Checked in new fix. Try updating runtime and try now.
I have a slight concern with how c2j code approaches formatting and deformatting numerics; considering Euro style money formatting. format() function in c2j accepts a string and is supposed to be able to cope with either deformatted number or formatted number. It achieves this by calling deformat first. But euro money throws a spanner in the works, because output of deformat is going to be different depending on whether or not the input is already deformatted.
i.e. the following for UK/Aus/US style money formatting works as expected:
deformat(deformat('1,234.56',@n6.2),@n6.2) = 1234.56
But not with euro style:
deformat(deformat('1.234,56',@n6`2),@n6`2) = 123456
I have hacked around the problem by modifying format() for numerics, if the number string passes ClartionString.isNumeric() test, then assume it is already deformatted and do not call deformat().
Maybe calling deformat is superfluous, but removing it entirely is a big change that requires extensive testing. Lets try this one first.
Maybe the isNumeric test should be located in deformat? Would need to do some extensive testing by compiling up some clarion 5.5/6 programs and experiment with how deformat/format behave in context of using euro style formatting.
Here is some code I used for manual testing to support above changes to try and fix this.
I have started to look formatting. The first i have noted in my test application is the following:
lr REAL
ENTRY(@n-17`2),AT(243,138,94,12),USE(lr),RIGHT(2)
ENTRY(@n-17.2),AT(240,118,94,12),USE(lr,,?lr:2),RIGHT(2)
When i enter 12345,67 in ?lr i get correctly 12.345,67 but the ?lr:2 displays ####### while i expect it to stamp 12,345.67 i.e. every control field uses it's formatting rules for the same variable.
When I then enter 12345.67 in ?lr:2 both controls displays good.
But when I then enter 23456.78 in ?lr:2 the ?lr:2 is OK and it is the ?lr not good.
I suppose you have implemented, or maybe is the ABC, that when the variable value does not change, the control is not redisplayed.
I will check now your test window; there is just one thing strange to me:
('1,234.56',@n6.2),@n6.2) the picture 6.2 is not enough to display the 1,234.56 i.e. you should use 8.2, at least i think so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problem is that 12345.67 internally represented inside a REAL is internally stringified as -12345.670000000000072759576141834259033203125
My number picture implementation, would assume that decimal part had 9 decimal places, but picture is only 17.2, so it would not format properly. in c2j pictures work in strict or loose mode. In loose mode system would round the number before formatting. Strict fails formatting. Now for entry controls at the moment, formatting data applies strict mode.
Maybe need to modify Entry, so that if use variable is a REAL then it should use loose mode pictures.
c2j implements REAL/floating point support but it is not heavily tested. I do not use reals in business programming. You should only use reals for scientific/high level statistical stuff. Most of my coding in clarion deals with percentages, money and basic statistics, so I always use decimal. If you used decimal instead, it would of worked.
Let me know if you really must use REAL USE vars on ENTRY. I will tweak entrycontrol to switch to loose mode in these circumstances.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To clarify, I did commit a change to runtime, but it will not fix the above example. You need to switch to decimal. Or, if you have a legitimate reason for wanting to use REAL, let me know and I will commit fix to Entry control to be non strict when dealing with REALs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Follows what i have found in clarion test app:
message(':' & deformat('1.234,56',@n-10`2) & ':') returns :12345.:
message(':' & deformat(deformat('1.234,56',@n-10`2),@n-10`2) & ':') returns :12345:
Adding one leading space:
message(':' & deformat(' 1.234,56',@n-10`2) & ':') returns :1234.6:
message(':' & deformat(deformat(' 1.234,56',@n-10`2),@n-10`2) & ':') returns :12346:
Adding one more leading space:
message(':' & deformat(' 1.234,56',@n-10`2) & ':') returns :01234.56:
message(':' & deformat(deformat(' 1.234,56',@n-10`2),@n-10`2) & ':') returns :012345.:
I know also from previous experiences that clarion format/deformat is difficult to use/understand. Clearly clarion returns the correct deformat just for the third case (two leading spaces). So now it is debatable if the other cases are bugs or not because clarion does:
message(':' & format('1234.56',@n-10`2) & ':') returns : 1.234,56:
message(':' & format('-1234.56',@n-10`2) & ':') returns : -1.234,56:
If instead i use pictures for LONG things are better:
message(':' & format(123456,@n-10) & ':') returns : 123,456:
message(':' & deformat('123456',@n-10) & ':') returns :123456:
message(':' & deformat(' 123456',@n-10) & ':') returns :123456:
message(':' & deformat(' 123,456',@n-10) & ':') returns :123456:
message(':' & deformat(deformat('123456',@n-10),@n-10) & ':') returns :123456:
message(':' & deformat(deformat(' 123,456',@n-10),@n-10) & ':') returns :123456:
I do not think you should implement c2j to follow strictly the clarion behaviour, as it is impossible/difficult to find all scenarios. But it is up to you. My suggestion would be that c2j deformat, in all above cases for REAL picture, returns the STRING 01234.56, and obviously that string should convert to REAL 1234.56; i.e. if i do lreal=deformat(etc.
Since in this c2j application i do not intend to use REALs, i am OK, and format/deformat as it is now is enough good for me.
During testing i have noted that the following two cases will not compile in c2j:
1. message(numeric('1234.56'))
In clarion it would return 1. I
str string(5)
llong long
code
str=l
Both cases compile in clarion. I think you miss some automatic conversion code from numeric variable types to STRING.
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Numeric in c2j behaves slightly differently to clarion. c2j has an explicit concept of a boolean, clarion does not. In clarion a boolean is just an integer with value 0 or 1 (or ~0 ?) . I implemented numeric() in c2j so it returns a boolean not an integer: because 99% of the time when calling numeric it is in a boolean test. i.e. if numeric(this) and that then do thing. But this means when you convert to string, the result will not be '1' (true) or '0' false. It will be '1' (true) or '' (false). So slightly different behaviour to clarion, but I think it is okay.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Results of test above are very interesting. I tried them in my copy of clarion 6 myself and got the same result. I am surprised how poorly Clarion handles deformatting of Euro style. I definitely will not be replicating this!
I added a test into runtime. In:
src/test/java/org/jclarion/clarion/runtime/format/NumberFormatTest.java
Called : testEuroFormatsFromSourceForgeComment4867236
It tests all of the above posted examples in c2j.
The issue with nested deformats. Nested deformats will work with US style formatting, but not Euro. I think that this is the way we want it actually.
Consider this firstly to explain the problem:
Input is : 1.234,56 Picture @n10`2
On first deformat our output is this: 1234.56
Now when we feed this into second deformat. Deformat treats the '.' as a grouping separator. It expects to find a ',' as decimal separator. Because there is no decimal separator it's output is this : 123456
Now you could in theory modify deformat so if input already looks like a deformatted number, (i.e. a numeric() test), then do not deformat again. Just pass the output. And this is similar to changes I made to c2j format. Previously format() in c2j will accept formatted or deformatted data. I recently modified this so it does not call deformat if number already looks deformatted. i.e. by doing a numeric() test. But this is alot harder than it sounds.
Consider the following: 123.456. Is this really 123456 or is it 123.456? You could take clues from the picture, i.e. size of decimal places, but this is starting to get too complex, pushing into areas of heuristics I feel a function like this should not go into. deformat() should expect formatted input only, and if you feed it deformatted input, you may not get the result you expect. Format() on the other hand, in c2j at least is more intelligent. i.e. in c2j the following works format('123.456,78',@n-10`2), but in my clarion 6 at least it does not. I guess I should consider modifying format() so it does not deformat first. But not sure if this is a good idea. Will wait and see if any cases come up where format() in it's current form breaks down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with you: let it stay as it is. It would be nice though that the c2j deformats the values always in the same manner, i.e. that it does not depend of the missing leading zeros. This really has no logic in Clarion implementation. I will try this Monday when I return to work.
I never use format on already formatted values, and generally speaking, for me format/deformat is one of the areas in Clarion where there is no clear logic and so no certain implementation.
If the Euro fails as currency, we could also drop the Euro formatting and the world would be easier:)
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked:
message(':' & deformat('1.234,56',@n-10`2) & ':') returns 1234.56 regardlessof missingleading space. Excellent!
But message(numeric('12345')) still does not compile : missing newString(boolean)
Nenad
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a problem with numeric pictures. With N6`2 the c2j compiler would complain, with N6.2 it's OK. Is the c2j supporting the grave accent for numeric places?
thanks
Nenad
Hi
I did implement this in c9, but I think that I misread the help file. I assumed single quote ('), not grave accent (`).
I have added a simple commit to sub version that will accept either quote (') or grave accent (`)
I have updated the numberformat.java and cwin.java.
It's still not working. I have also tried to do mvn clean on runtime and compiler.
This is my window
QuickWindow WINDOW('Form gloparam'),AT(,,355,180),FONT('Tahoma',,,,CHARSET:EASTEUROPE),CENTER,IMM,HLP('UpdGlp'),SYSTEM,GRAY,DOUBLE,MDI
SHEET,AT(4,4,350,158),USE(?CurrentTab)
TAB,USE(?Tab:1)
PROMPT('matična firma:'),AT(8,21,113,10),USE(?glp:matfirma:Prompt),TRN
ENTRY(@s100),AT(148,21,202,12),USE(glp:matfirma),LEFT(2),MSG('naziv matične firme'),TIP('naziv matične firme'),REQ
PROMPT('oib:'),AT(8,35,113,10),USE(?glp:oib:Prompt),TRN
ENTRY(@s20),AT(148,35,111,12),USE(glp:oib),LEFT(2),MSG('oib'),TIP('oib'),REQ
PROMPT('banka:'),AT(8,49,113,10),USE(?glp:banka:Prompt),TRN
ENTRY(@s100),AT(148,49,202,12),USE(glp:banka),LEFT(2),MSG('naziv banke'),TIP('naziv banke'),REQ
PROMPT('domaća valuta:'),AT(8,63,113,10),USE(?glp:dom_valuta:Prompt),TRN
ENTRY(@s3),AT(148,63,40,12),USE(glp:dom_valuta),LEFT(2),MSG('domaća valuta'),TIP('domaća valuta'),REQ
OPTION('mjenjački poslovi'),AT(148,77,91,36),USE(glp:mjenjacki_poslovi),BOXED,TRN,MSG('tip mjenjačkih poslova'),TIP('tip mjenjačkih poslova')
RADIO('Otkup i prodaja'),AT(152,88),USE(?glp:mjenjacki_poslovi:Radio1),TRN,VALUE('1')
RADIO('Otkup'),AT(152,99),USE(?glp:mjenjacki_poslovi:Radio2),TRN,VALUE('2')
END
PROMPT('<154>ifra:'),AT(21,86),USE(?glp:sifra:Prompt),TRN,HIDE
STRING(@n14),AT(45,85,60,10),USE(glp:sifra),TRN,HIDE,RIGHT(1)
PROMPT('defaultni postotak provizije:'),AT(8,115,113,10),USE(?glp:def_pst_provizije:Prompt)
ENTRY(@n6`2),AT(148,114,41,12),USE(glp:def_postotak_provizije),RIGHT(2),MSG('defaultni postotak provizije'),TIP('defaultni postotak provizije')
PROMPT('defaultna vrsta čekova:'),AT(8,131,113,10),USE(?glp:def_vrsta_cekova:Prompt),TRN
ENTRY(@n14),AT(148,131,41,12),USE(glp:def_vrsta_cekova),RIGHT(2),MSG('defaultna vrsta čekova'),TIP('defaultna vrsta čekova'),REQ
PROMPT('port number za komunikaciju sa IQ:'),AT(8,146,129,10),USE(?glp:portNum:Prompt),TRN
ENTRY(@n14),AT(148,146,41,12),USE(glp:portNum),RIGHT(2),MSG('port number za komunikaciju sa IQ'),TIP('port number za komunikaciju sa IQ')
END
END
BUTTON('&Prihvati'),AT(209,164,70,14),USE(?OK),LEFT,MSG('Prihvati unesene podatke'),TIP('Prihvati unesene podatke'),ICON('tick.png'),DEFAULT
BUTTON('&Odustani'),AT(284,164,70,14),USE(?Cancel),LEFT,MSG('Odustani od operacije'),TIP('Odustani od operacije'),ICON('cross.png')
END
The glp:def_postotak_provizije has the grave accent. The exact error is lang.ClarionCompileError: expected ')' near line:40
where line 40 is the ENTRY(@n6`2),AT(148,114,41,12),USE(glp:def_postotak_provizije)
glp:def_postotak_provizije is DECIMAL(5,2)
Nenad
Apologies, I fixed the runtime processing of number pictures, but not compile time. They are in two separate locations.
Just checked in a new fix into runtime. Recompile runtime.
Also make sure that you recompile compiler and plugin. And update your pom to refer to newest plugin : 1.21-SNAPSHOT. I justed checked in new poms for these to make sure they refer to latest runtime.
I tested it with following program: it works as expected.
c2j handling of decimals with ',' as separator is poorly tested because it is not something I use myself. I just discovered one bug with it which I just fixed. Keep an eye out for others. Particularly I am not sure if my implementation of deformat is correct. i.e. currently in tests is the following test:
assertEquals("123.45",nf.deformat("123,45"));
assertEquals("############",nf.deformat("123.45"));
These tests imply that 123.45 should not deformat, but 123,45 should. I am uncertain as to what correct behaviour should be. Changing code is simple though should it be necessary.
It's still not good. Now it compiles but when i type in sequence 12345,67 i get on screen 12,345,67 while i should get 12.345,67
I have tried this with REAL variable and picture @n-17`2
However the value of the variable is correct i.e it is 12345 integer parts and 67decimal part
Checked in new fix. Try updating runtime and try now.
I have a slight concern with how c2j code approaches formatting and deformatting numerics; considering Euro style money formatting. format() function in c2j accepts a string and is supposed to be able to cope with either deformatted number or formatted number. It achieves this by calling deformat first. But euro money throws a spanner in the works, because output of deformat is going to be different depending on whether or not the input is already deformatted.
i.e. the following for UK/Aus/US style money formatting works as expected:
deformat(deformat('1,234.56',@n6.2),@n6.2) = 1234.56
But not with euro style:
deformat(deformat('1.234,56',@n6`2),@n6`2) = 123456
I have hacked around the problem by modifying format() for numerics, if the number string passes ClartionString.isNumeric() test, then assume it is already deformatted and do not call deformat().
Maybe calling deformat is superfluous, but removing it entirely is a big change that requires extensive testing. Lets try this one first.
Maybe the isNumeric test should be located in deformat? Would need to do some extensive testing by compiling up some clarion 5.5/6 programs and experiment with how deformat/format behave in context of using euro style formatting.
Here is some code I used for manual testing to support above changes to try and fix this.
I have started to look formatting. The first i have noted in my test application is the following:
lr REAL
ENTRY(@n-17`2),AT(243,138,94,12),USE(lr),RIGHT(2)
ENTRY(@n-17.2),AT(240,118,94,12),USE(lr,,?lr:2),RIGHT(2)
When i enter 12345,67 in ?lr i get correctly 12.345,67 but the ?lr:2 displays ####### while i expect it to stamp 12,345.67 i.e. every control field uses it's formatting rules for the same variable.
When I then enter 12345.67 in ?lr:2 both controls displays good.
But when I then enter 23456.78 in ?lr:2 the ?lr:2 is OK and it is the ?lr not good.
I suppose you have implemented, or maybe is the ABC, that when the variable value does not change, the control is not redisplayed.
I will check now your test window; there is just one thing strange to me:
('1,234.56',@n6.2),@n6.2) the picture 6.2 is not enough to display the 1,234.56 i.e. you should use 8.2, at least i think so.
Committed fix to runtime
Problem is that 12345.67 internally represented inside a REAL is internally stringified as -12345.670000000000072759576141834259033203125
My number picture implementation, would assume that decimal part had 9 decimal places, but picture is only 17.2, so it would not format properly. in c2j pictures work in strict or loose mode. In loose mode system would round the number before formatting. Strict fails formatting. Now for entry controls at the moment, formatting data applies strict mode.
Maybe need to modify Entry, so that if use variable is a REAL then it should use loose mode pictures.
c2j implements REAL/floating point support but it is not heavily tested. I do not use reals in business programming. You should only use reals for scientific/high level statistical stuff. Most of my coding in clarion deals with percentages, money and basic statistics, so I always use decimal. If you used decimal instead, it would of worked.
Let me know if you really must use REAL USE vars on ENTRY. I will tweak entrycontrol to switch to loose mode in these circumstances.
To clarify, I did commit a change to runtime, but it will not fix the above example. You need to switch to decimal. Or, if you have a legitimate reason for wanting to use REAL, let me know and I will commit fix to Entry control to be non strict when dealing with REALs.
It's ok. I do not need REAL. I have used REAL only by chance.
Thanks
Nenad
I have made some tests.
message(deformat('1.234,56',@n-10`2)) returns correctly 1234.56
message(deformat(deformat('1.234,56',@n-10`2),@n-10`2)) returns INCORRECTLY 123456
numeric(deformat('1.234,56',@n-10`2)) returns correctly true
Follows what i have found in clarion test app:
message(':' & deformat('1.234,56',@n-10`2) & ':') returns :12345.:
message(':' & deformat(deformat('1.234,56',@n-10`2),@n-10`2) & ':') returns :12345:
Adding one leading space:
message(':' & deformat(' 1.234,56',@n-10`2) & ':') returns :1234.6:
message(':' & deformat(deformat(' 1.234,56',@n-10`2),@n-10`2) & ':') returns :12346:
Adding one more leading space:
message(':' & deformat(' 1.234,56',@n-10`2) & ':') returns :01234.56:
message(':' & deformat(deformat(' 1.234,56',@n-10`2),@n-10`2) & ':') returns :012345.:
I know also from previous experiences that clarion format/deformat is difficult to use/understand. Clearly clarion returns the correct deformat just for the third case (two leading spaces). So now it is debatable if the other cases are bugs or not because clarion does:
message(':' & format('1234.56',@n-10`2) & ':') returns : 1.234,56:
message(':' & format('-1234.56',@n-10`2) & ':') returns : -1.234,56:
If instead i use pictures for LONG things are better:
message(':' & format(123456,@n-10) & ':') returns : 123,456:
message(':' & deformat('123456',@n-10) & ':') returns :123456:
message(':' & deformat(' 123456',@n-10) & ':') returns :123456:
message(':' & deformat(' 123,456',@n-10) & ':') returns :123456:
message(':' & deformat(deformat('123456',@n-10),@n-10) & ':') returns :123456:
message(':' & deformat(deformat(' 123,456',@n-10),@n-10) & ':') returns :123456:
I do not think you should implement c2j to follow strictly the clarion behaviour, as it is impossible/difficult to find all scenarios. But it is up to you. My suggestion would be that c2j deformat, in all above cases for REAL picture, returns the STRING 01234.56, and obviously that string should convert to REAL 1234.56; i.e. if i do lreal=deformat(etc.
Since in this c2j application i do not intend to use REALs, i am OK, and format/deformat as it is now is enough good for me.
During testing i have noted that the following two cases will not compile in c2j:
1. message(numeric('1234.56'))
In clarion it would return 1. I
llong long
code
str=l
Both cases compile in clarion. I think you miss some automatic conversion code from numeric variable types to STRING.
Nenad
I have made mistake.
str string(5)
llong long
code
str=llong
is OK.
But message(numeric('1234.56')) is not and c2j return not suitable method for newString(boolean)
Added a fix to runtime for message(numeric).
Numeric in c2j behaves slightly differently to clarion. c2j has an explicit concept of a boolean, clarion does not. In clarion a boolean is just an integer with value 0 or 1 (or ~0 ?) . I implemented numeric() in c2j so it returns a boolean not an integer: because 99% of the time when calling numeric it is in a boolean test. i.e. if numeric(this) and that then do thing. But this means when you convert to string, the result will not be '1' (true) or '0' false. It will be '1' (true) or '' (false). So slightly different behaviour to clarion, but I think it is okay.
Results of test above are very interesting. I tried them in my copy of clarion 6 myself and got the same result. I am surprised how poorly Clarion handles deformatting of Euro style. I definitely will not be replicating this!
I added a test into runtime. In:
src/test/java/org/jclarion/clarion/runtime/format/NumberFormatTest.java
Called : testEuroFormatsFromSourceForgeComment4867236
It tests all of the above posted examples in c2j.
The issue with nested deformats. Nested deformats will work with US style formatting, but not Euro. I think that this is the way we want it actually.
Consider this firstly to explain the problem:
Input is : 1.234,56 Picture @n10`2
On first deformat our output is this: 1234.56
Now when we feed this into second deformat. Deformat treats the '.' as a grouping separator. It expects to find a ',' as decimal separator. Because there is no decimal separator it's output is this : 123456
Now you could in theory modify deformat so if input already looks like a deformatted number, (i.e. a numeric() test), then do not deformat again. Just pass the output. And this is similar to changes I made to c2j format. Previously format() in c2j will accept formatted or deformatted data. I recently modified this so it does not call deformat if number already looks deformatted. i.e. by doing a numeric() test. But this is alot harder than it sounds.
Consider the following: 123.456. Is this really 123456 or is it 123.456? You could take clues from the picture, i.e. size of decimal places, but this is starting to get too complex, pushing into areas of heuristics I feel a function like this should not go into. deformat() should expect formatted input only, and if you feed it deformatted input, you may not get the result you expect. Format() on the other hand, in c2j at least is more intelligent. i.e. in c2j the following works format('123.456,78',@n-10`2), but in my clarion 6 at least it does not. I guess I should consider modifying format() so it does not deformat first. But not sure if this is a good idea. Will wait and see if any cases come up where format() in it's current form breaks down.
I agree with you: let it stay as it is. It would be nice though that the c2j deformats the values always in the same manner, i.e. that it does not depend of the missing leading zeros. This really has no logic in Clarion implementation. I will try this Monday when I return to work.
I never use format on already formatted values, and generally speaking, for me format/deformat is one of the areas in Clarion where there is no clear logic and so no certain implementation.
If the Euro fails as currency, we could also drop the Euro formatting and the world would be easier:)
Nenad
I have checked:
message(':' & deformat('1.234,56',@n-10`2) & ':') returns 1234.56 regardlessof missingleading space. Excellent!
But message(numeric('12345')) still does not compile : missing newString(boolean)
Nenad