GET PICTURE "calculator style" for numbers

[Yakano]

Hello guys. Can someone help me ...

I have some new users (the old school never complained), who are very unhappy with the way the numerical data is entered on the screen and I don't know how to modify it, to try to satisfy everyone.

When we GET a number, with PICTURE "999,999.99", initially it shows correct (for example 1,234.56) but when we start typing, we start from the left and the number loses its format (example 123 4.  ) And until we press the decimal point is not returned to the expected format (example 1,234.  ).

As far as I remember, this behavior was the same as Clipper 5.2 had, but ... Is there an easy way to make the numbers appear in "calculator style", that is, from right to left in the integer part of the number and from left to the right in the decimal part.

Sorry if this question is out of line, but I never thought I'd end up asking this in a group ...

Thank you!

harbour3.2 + mingw + console

[cod...@outlook.com]

Hi Yakano,

I will not solve your problem, but give you some suggestion. In GET system I never used PICTURE with thousands separator, PICTURE "999,999.99", only with decimal separator, PICTURE "999999.99". Of course, in printed reports I use PICTURE with thousands separator. Users do not complain about that. I think it is cleaner when entering numbers.

Best Regards,

Simo.

[fdaniele]

ciao

in clipper the grunfish lib did it

perhaps with some modifications .....

[Yakano]

Hi Simo.

The application uses a lot of numerical data on the screen and it is really more comfortable to display those numbers with the thousands separator when they do not have the focus.  The problem has arisen when editing, because some "need" to hit the decimal point before moving to the next GET. 

Thank you very much for your help. 

Greetings!  

[Yakano]

Hi fdaniele 

I never used that GrumFish functionality, but it's good to know, maybe that library has been ported to 32 bits (I don't know either).  I never modified GETSYS, although I know that some users had good results and those "modifications" would be a real headache, because I would not know where to start ... 

Thank you very much for your help. 

Greetings!  

[Klas Engwall]

Hi Yakano,

> I never used that GrumFish functionality, but it's good to know, maybe
> that library has been ported to 32 bits (I don't know either).  I never
> modified GETSYS, although I know that some users had good results and
> those "modifications" would be a real headache, because I would not know
> where to start ...

Greg Lief put his Grumpfish library at the Oasis when he quit the
Clipper add-on business, and then Viktor put the Oasis files here:
https://harbour.github.io/the-oasis/ftplib.htm

The CALC_PIC.PRG file is what you need. As I understand it, it is not a
get reader but an extension to the picture (!), so I have a feeling it
is rather limited. It comes with this caveat:

By design, CALC_PIC() can only be used with one GET and one READ.
For example, if you are GETting ten variables on the same READ, and
one of those variables uses CALC_PIC() as the PICTURE clause, the
cursor will jump to that variable no matter where it is in the
list. This is unavoidable because, unlike a VALID clause which
is processed only after passing through the corresponding GET, all
PICTURE clauses are processed before control is passed to the READ
statement.

A better solution seems to be the get reader called CalcReader() that
was published in the 7/8 1994 issue of Clipper Advisor. I have not used
it, but it looks pretty good. I have put the article and the source file
temporarily here: http://temp.engwall.com/calcget.zip

It is not guaranteed to stay there forever, so pick it up as soon as
possible if you want to try it.

Regards,
Klas

[Yakano]

Hello Klass, nice to greet you again.

Something similar to the solution you provide is in the application that they ask to modify and, although I was not its initial developer, I have taken care of its maintenance and added some improvements.

Attached is a .prg of a fully operational calculator ...

Before starting, it can be moved to the right or left and, after a first Enter, it allows collecting the data if activated (via set key) from a numeric GET and performing operations with it and, optionally, returning the value to said numeric GET (with F7). If the GET is a date type, it also allows adding or subtracting days from that date. I really think it's a pretty good calculator, although I don't remember its origin, I think it was adapted from a Clipper magazine, but I'm not sure.

What I have tried of the CalcReader () option has not totally convinced me, but I will try to see if it can be adapted with what is described above. In that case, I will post the results.

Thank you very much again and best regards.

Yakano

[Klas Engwall]

Hi Yakano,

Well, you said you wanted to enter numerical values from right to left,
and that is what the CalcReader() get reader does. Now apparently you
want an entire calculator, and that is a totally different ballgame.

Regards,
Klas

[Yakano]

Hi Klass

No, I don't need a calculator, I already have that. Maybe I have expressed myself wrong, I include the calculator as an example and in case it can be useful to someone.

I have tried CalcReader () and it doesn't work right. When entering the numbers, some are lost and others change their order. The image below is the result of writing 12, which makes it 21. And if you keep writing the mess is even greater.

That code doesn't work, however the idea of using the SEND clause within the GET may be interesting to explore a possible solution.

As always, thank you very much.

Best regards!

[Yakano]

[Klas Engwall]

Hi Yakano,

> No, I don't need a calculator, I already have that. Maybe I have
> expressed myself wrong, I include the calculator as an example and in
> case it can be useful to someone.

OK, I see :-)

> I have tried CalcReader () and it doesn't work right. When entering the
> numbers, some are lost and others change their order. The image below is
> the result of writing 12, which makes it 21. And if you keep writing the
> mess is even greater.
>
> That code doesn't work, however the idea of using the SEND clause within
> the GET may be interesting to explore a possible solution.

The SEND clause is just a preprocessor command to tell the get system to
use a separate get reader for this get. This is what the get setup for
<nTestData3> is peprocessed into:

SetPos( Row(), Col() + 1 ) ;
AAdd( GetList, _GET_( nTestData3, "nTestData3", padl("#",15),, ) ) ;
ATail( GetList ):reader:={|oGet|CalcReader(oGet)} ;
ATail( GetList ):Display()

As I said, I had not used CalcReader(), but I thought it looked good. I
have made a quick test now, and I don't get your misplaced digit, but I
noticed that the first digit entered was displayed in the second to last
position instead of the last and was then lost when I entered the second
digit. But when I press <Home> before the first digit, it works. So
there seems to be a little glitch that needs fixing. I don't have the
time for that right now but will test the assembling of the picture ASAP
to see if I can figure it out. I suggest you try the samt trick in the
meantime so we can compare notes later.

Regards,
Klas

[Klas Engwall]

Hi again Yakano,

>> I have tried CalcReader () and it doesn't work right. When entering
>> the numbers, some are lost and others change their order. The image
>> below is the result of writing 12, which makes it 21. And if you keep
>> writing the mess is even greater.
>>
>> That code doesn't work, however the idea of using the SEND clause
>> within the GET may be interesting to explore a possible solution.

I fired up XP mode and tried it with Clipper ... and it worked like a
charm, so we shouldn't blame the author from 1994 :-). There seems to be
a slight difference in how Clipper and Harbour handle the initial "0"
buffer when the first digit is entered and how they handle the empty
buffer created when deleting all digits.

So I experimented with those and came up with a solution that seems to
work. I have attached it to this message and also replaced the file I
put on the web earlier in the thread. Let me know if it works for you too.

There are some other things you might want to do, like maybe limiting
the number of decimals allowed efter the "." ... everything is possible :-)

Regards,
Klas

[Gary L Williams]

I use xHarbour, rather than Harbour, so this may not work for you

@ 2, 5 GET nresult PICTURE '@KL 9,999.99'

Calculator style input, in xharbour, there used to be display issues if someone tries to delete and correct entry errors,

under some conditions, I don't know if this issue still exists

[Yakano]

Hi gary

Unfortunately it seems that it does not work.

@K function seems to be implicit in a numeric GET, and it works the same as without it.

However @L or @KL (both work the same) is an undocumented surprise, it compiles and links correctly, but does not perform the calculator style in harbour.

Thanks a lot.

Best regards.

[Yakano]

Hello Klass

Yes, friend friend. You did it again! That works now!

For a moment I thought, if it was published in a magazine, it should work and maybe it was a compatibility problem (as you have discovered), but I did not have that old XP or x32 handy to try.

All that remains is, as you say, to be able to make CalcReader () take the original PICTURE from the GET (which has the desired length and the desired number of decimal places). In that case <nSize> would no longer be necessary and a standard CALCULATOR clause would have been achieved within Harbour (sounds good!) ... :-)))

Again, thank you very much!!!

Best regards

[Klas Engwall]

Hi Yakano,

> Yes, friend friend. You did it again! That works now!

Great :-)

> For a moment I thought, if it was published in a magazine, it should
> work and maybe it was a compatibility problem (as you have discovered),
> but I did not have that old XP or x32 handy to try.
>
> All that remains is, as you say, to be able to make CalcReader () take
> the original PICTURE from the GET (which has the desired length and the
> desired number of decimal places). In that case <nSize> would no longer
> be necessary and a standard CALCULATOR clause would have been achieved
> within Harbour (sounds good!) ... :-)))

No, <nSize> is needed, and using the "original PICTURE" is not the way
to go. Instead, to limit the number of decimals, you need to pass that
number to the reader. It should be possible to do that using the cargo
variable so the reader can then check <oGet:cargo>. Take another look at
the preprocessor output:

SetPos( Row(), Col() + 1 ) ;
AAdd( GetList, _GET_( nTestData3, "nTestData3", padl("#",15),, ) ) ;
ATail( GetList ):reader:={|oGet|CalcReader(oGet)} ;
ATail( GetList ):Display()

The picture is just one single # to start with, and it is left padded
with spaces up to the desired length. It is then modified after each
keypress with additional picture characters at the end and spaces
chopped off at the beginning. To limit the number of decimals you would
have to count the current number of digits after the dot and compare
that number with the cargo value before allowing another digit to be
added at the end - with a safety net in place in case there is no
cargo specified.

Regards,
Klas

[Klas Engwall]

Hi Yakano,

Here is a version of CalcReader() that limits the decimals using an
extra <decimals> setting in the get setup (0, 1, 2 or whatever). The
decimals setting is required, or the preprocessor will not understand.

Regards,
Klas

[Yakano]

Hello Klass 

I started to give a solution before seeing your last proposal and I see that we have partially used the same solution to allow any length in the PICTURE and with any number of decimal places, but to show the data I have abandoned the option to change that picture with each press of a key and I have chosen to re-displaing the number in each loop, which allows to work easily with decimals. 

I have tried your method, but something is wrong when you go to the previous get and come back, then the GET becomes unstable and does not show the information pressed. 

 In my case that's solved, the decimal point is used as a key to grab data from right to left or left to right, each time it is pressed. Additionally the delete keys work as they should and the thousands separator can be displayed. 

 But not everything is perfect, when you try to enter a number without an integer part, something goes wrong, it doesn't work well for something less than one "0.X" and I can't find how to get it. 

 Any idea? 

 Best regards  

[Klas Engwall]

Hi Yakano,

> I started to give a solution before seeing your last proposal and I see
> that we have partially used the same solution to allow any length in the
> PICTURE and with any number of decimal places, but to show the data I
> have abandoned the option to change that picture with each press of a
> key and I have chosen to re-displaing the number in each loop, which
> allows to work easily with decimals.
>
> I have tried your method, but something is wrong when you go to the
> previous get and come back, then the GET becomes unstable and does not
> show the information pressed.

Hmm, yes, there is something interesting going on here. I put a debug
display of the <oGet:buffer> before the "do case" and one after the
"endcase", and I have noticed that when entering a dot and then a digit
"0.1" is displayed at the end of the function, and then "1.0" when it
comes back at the top to handle the next key. So the buffer is somehow
flipped when there are only decimals. Some more research required ...

>  In my case that's solved, the decimal point is used as a key to grab
> data from right to left or left to right, each time it is pressed.
> Additionally the delete keys work as they should and the thousands
> separator can be displayed.
>
>  But not everything is perfect, when you try to enter a number without
> an integer part, something goes wrong, it doesn't work well for
> something less than one "0.X" and I can't find how to get it.
>
>  Any idea?

It may be related to what I mentioned above. I suggest you put debug
displays in there too and check what the buffer looks like inbetween
keypresses.

Other than that, I must say that you have made it much more complicated
with your new trick functions :-)

Regards,
Klas

[Yakano]

Hi Klass

Yes, I also put this AltD() after the READ and in the CASE and I debug the complete process of each key pressed. Well it seems that is GETAPPLYKEY's responsability,  because the buffer and GETAPPLYKEY are not totally synchronized. It was ... another way to attack the problem and those functions cPictNum and nValNum were already used in my own library for similar purposes via #define, so it was easy for me using it for keeping the original PICTURE ;-). I think it was necessary, but too bad there is no solving the "0.x" problem ...  

There are also a couple more issues that I didn't mention: 1) Numbers can turn negative at any time, but you can't start by pressing "-1" to get to "-0.00" »" - 1.00 " and 2) Where has hidden cursor? It is not shown and the user is sure to want to see where he is writing.  

If I can't solve it, I'll try your solution, but currently it fails when you go back to get CALCULATOR and type a new number (also if 1234.56 is preasigned) and, although I've thought about it, I don't see the possible solution ...  Again  it seems that is GETAPPLYKEY's responsability, but no ideas to solve that behavior that never works, which can be inherited from the original or again some difference between Clipper and Harbour. I try a couple of things, but no results...

I'm starting to think this is not going to be easy. 

Best regards  

[Klas Engwall]

Hi Yakano,

There are a couple of other things I have to focus on over the weekend,
but I will try to return to this problem as soon as I cans ...

Regards,
Klas

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to harbour-user...@googlegroups.com
> <mailto:harbour-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/harbour-users/ee2732b3-1596-44f9-a81c-f1529e9c0300n%40googlegroups.com
> <https://groups.google.com/d/msgid/harbour-users/ee2732b3-1596-44f9-a81c-f1529e9c0300n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[GeoffD]

Hi Yakano

The hidden cursor is easy to fix.

It need to be turned on with 

LOCAL nB4_Curs := SetCursor(SC_NORMAL)

and restored on exit of function

SetCursor( nB4_Curs )  

Geoff

[Yakano]

Hi GeoffD

Set SetCursor was the solution, I thinked GetClass take full control and changes were not allowend, but It works.

Thakns

[Yakano]

Hello guys.

I think I have got!!! 

The result is 99% compliant with the GET class, just a couple of improvements. 

Only '-' and '.' have different behaviour and they don't make implicit @K like harbour does for numbers.

This code adds a CALCULATOR clause to that class via SEND and allows all other options in the class. Hope it's helpful for someone and if any test doesn't work let me know.

Thanks Klass for your great help with this !!! 

Best regards  

[Klas Engwall]

Hi Yakano,

> I think I have got!!!
> The result is 99% compliant with the GET class, just a couple of
> improvements.
> Only '-' and '.' have different behaviour and they don't make implicit
> @K like harbour does for numbers.
>
> This code adds a CALCULATOR clause to that class via SEND and allows all
> other options in the class. Hope it's helpful for someone and if any
> test doesn't work let me know.
>
> Thanks Klass for your great help with this !!!

It sounds like you have solved the remaining problems. I will look
closer at your new version when things slow down a little here.

Regards,
Klas

[Yakano]

Hi Klass

Perhaps, to give the user 100% control over the GET PICTURE, the clause CALCULATOR needs more parameters. Something like...

CALCULATOR <size>, <decimal>, <comma>, <funktion>

to call the cPictNum () trick function with those options. 

It doesn't seem complicated to modify preprocessor, but a get PICTURE was always worth to me with comma (comma = .T.) and without @function in the picture (funktion = nil).

So maybe next version ... ;-)

Regards

[wanst...@gmail.com]

Hi folks,

Did you do anything more on the nice "calc type number get" solution?

I found this thread and I got interested in the solution but for decimal symbol with ',' and thousand separator with '.'

Maybe you already did something about it?

Thanks for any reply!