Page 1 of 1
Picture in GET problem
Posted: Fri Apr 13, 2007 1:04 pm
by Patrick Mast
Hi,
Consider this:
Code: Select all
#include "FiveWin.ch"
Function wfMain()
LOCAL oDlg
LOCAL oGet1, oGet2, oGet3
LOCAL nGet1:=0, nGet2:=9999.999, nGet3:=9999999.999
DEFINE DIALOG oDlg TITLE "Picture problem" FROM 0,0 TO 200,500 PIXEL
@ 10, 10 SAY 'The picture of the 3 GET objects is: "9 999 999.999"' OF oDlg SIZE 500,10 PIXEL
@ 20, 10 SAY 'All 3 GET objects are RIGHT aligned.' OF oDlg SIZE 500,10 PIXEL
@ 40, 10 GET oGet1 VAR nGet1 OF oDlg SIZE 20, 10 PIXEL RIGHT PICTURE "9 999 999.999"
@ 50, 10 GET oGet2 VAR nGet2 OF oDlg SIZE 30, 10 PIXEL RIGHT PICTURE "9 999 999.999"
@ 60, 10 GET oGet3 VAR nGet3 OF oDlg SIZE 40, 10 PIXEL RIGHT PICTURE "9 999 999.999"
@ 40, 55 SAY '-> Value is 0.000, but the decimals are not visible' OF oDlg SIZE 500,10 PIXEL
@ 50, 55 SAY '-> Value is 9 999.999, but the last decimal is not visible' OF oDlg SIZE 500,10 PIXEL
@ 60, 55 SAY '-> Value is 9 999 999.999, everything is visible' OF oDlg SIZE 500,10 PIXEL
ACTIVATE DIALOG oDlg CENTERED
RETURN NIL
This code results in this:
How can we get the spaces in FRONT of the picture removed, so the full value of the get is displayed in the get?
Thank you.
--
Patrick Mast,
http://www.WinFakt.com
Posted: Fri Apr 13, 2007 2:48 pm
by Antonio Linares
Patrick,
You may use the same SIZE for the three GETs:
@ 40, 10 GET oGet1 VAR nGet1 OF oDlg SIZE 40, 10 PIXEL RIGHT PICTURE "9 999 999.999"
@ 50, 10 GET oGet2 VAR nGet2 OF oDlg SIZE 40, 10 PIXEL RIGHT PICTURE "9 999 999.999"
@ 60, 10 GET oGet3 VAR nGet3 OF oDlg SIZE 40, 10 PIXEL RIGHT PICTURE "9 999 999.999"
Posted: Fri Apr 13, 2007 2:59 pm
by Patrick Mast
Antonio Linares wrote:You may use the same SIZE for the three GETs:
Ok, but that's the problem. If the GET field is width enough, it fits, that's OK.
But I want to get rid of the left spaces in the GET, so, the picture fits into the GET. So, even if I have a picture of "999999999.99", and the GET fits only 3 digits, the startvalue of 0.00 is still vissable in the GET.
Why has the value in the GET spaces on the left side? If we can delete those, we are OK.
Patrick
Posted: Fri Apr 13, 2007 7:30 pm
by James Bott
Patrick,
>Ok, but that's the problem. If the GET field is width enough, it fits, that's OK.
>But I want to get rid of the left spaces in the GET, so, the picture fits into the GET. So, even if I have a picture of "999999999.99", and the GET fits only 3 digits, the startvalue of 0.00 is still vissable in the GET.
The problem is that two of the GETs are not wide enough for the picture. So if the code was changed to what you want, some of the data would not be visible if a large number was entered. So, either way sometimes data would not be visible. The GET must be wide enough for the picture for everything to work properly.
Why not just either change the picture to a smaller one, or change the size of the GET to be larger? Is there something special about your situation where these options would not work?
James
Posted: Fri Apr 13, 2007 8:10 pm
by Patrick Mast
James Bott wrote:Patrick,
>Ok, but that's the problem. If the GET field is width enough, it fits, that's OK.
>But I want to get rid of the left spaces in the GET, so, the picture fits into the GET. So, even if I have a picture of "999999999.99", and the GET fits only 3 digits, the startvalue of 0.00 is still vissable in the GET.
The problem is that two of the GETs are not wide enough for the picture. So if the code was changed to what you want, some of the data would not be visible if a large number was entered. So, either way sometimes data would not be visible. The GET must be wide enough for the picture for everything to work properly.
Why not just either change the picture to a smaller one, or change the size of the GET to be larger? Is there something special about your situation where these options would not work?
Yes, I want to have a picture of "9999999.99999" in a narrow GET. So, if we can get rid of the spaces in from of the get, I'm saved.
In FiveWin 1.9 I did not have that problem.
Patrick
Posted: Fri Apr 13, 2007 8:17 pm
by James Bott
Patrick,
>Yes, I want to have a picture of "9999999.99999" in a narrow GET.
Why?
>So, if we can get rid of the spaces in from of the get, I'm saved.
As I mentioned, changing TGET will just create another problem.
James
Posted: Tue Apr 17, 2007 5:07 am
by Patrick Mast
James Bott wrote:>Yes, I want to have a picture of "9999999.99999" in a narrow GET.
Why?
Don't wanne be rude, but, does it matter?
James Bott wrote:
>So, if we can get rid of the spaces in from of the get, I'm saved.
As I mentioned, changing TGET will just create another problem.
So, is it posible?
We had this in Fivewin 1.9.2.
Antonio?
Patrick
Posted: Tue Apr 17, 2007 6:59 am
by Antonio Linares
Patrick,
> We had this in Fivewin 1.9.2.
It has rained a lot since then
FWH GET PICTUREs support is much more complete by now but as a side effect it looks that there is the problem that you describe
Anyhow you may use the workaround of the size or a reduced picture
Posted: Tue Apr 17, 2007 7:32 am
by Patrick Mast
Antonio Linares wrote:FWH GET PICTUREs support is much more complete by now but as a side effect it looks that there is the problem that you describe.
Is there a simple LTrim() somewhere we can do in TGet to get this fixed?
Patrick
Posted: Tue Apr 17, 2007 8:00 am
by Antonio Linares
Patrick,
In METHOD DispText() CLASS TGet there is a call to SetWindowText(). You can try a LTrim() there:
SetWindowText( ::hWnd, LTrim( ::oGet:buffer ) )
but the caret position should be tested to see if it matches the right location
Posted: Tue Apr 17, 2007 2:25 pm
by James Bott
Patrick,
>>Yes, I want to have a picture of "9999999.99999" in a narrow GET.
>Why?
>Don't wanne be rude, but, does it matter?
Yes. If you want someone else to donate their time to help with a problem that only seems to be a problem for you and will create more problems for others, I would say that you do need to give us a reason why.
>>So, if we can get rid of the spaces in from of the get, I'm saved.
>As I mentioned, changing TGET will just create another problem.
>So, is it posible?
Sure, but you are going to have to do it yourself. Since you are asking everyone else to suffer with a new bug without reason, so you can have what you want, I don't think you are going to get much help.
>We had this in Fivewin 1.9.2.
Why not just use the TGET.PRG from 1.9.2 then?
James
Posted: Tue Apr 17, 2007 6:36 pm
by Patrick Mast
James Bott wrote:>>Yes, I want to have a picture of "9999999.99999" in a narrow GET.
>Why?
>Don't wanne be rude, but, does it matter?
Yes. If you want someone else to donate their time to help with a problem that only seems to be a problem for you and will create more problems for others, I would say that you do need to give us a reason why.
Sorry James, you are correct. Let me explain.
We are converting an app from Clipper/FW1.9.2 to xHarbour/FWH-April2007. In FW1.9.2 it worked like I discribed. And we have TONS of RC's that needs to be changed if we can not get the same behaviour in latest FWH.
Antonio's proposal seems to do something, though, the carret is not correct via this way.
Sorry for being rude to you James. I must have had a very bad day. I'm normally a very gentle guy!
Patrick
Posted: Tue Apr 17, 2007 7:44 pm
by James Bott
Patrick,
>We are converting an app from Clipper/FW1.9.2 to xHarbour/FWH-April2007. In FW1.9.2 it worked like I discribed. And we have TONS of RC's that needs to be changed if we can not get the same behaviour in latest FWH.
It seems you do have a dilemma.
I wonder if you couldn't do a search and replace on the picture clause you are using. Apparently, the picture clause is larger than any of the data, or you would have had a problem with it also.
If you do change the source of TGet you are going to have to change it again each time a new FWH version is released. So, there is still some incentive to change your program either by changing the picture clause or the get size in the resource file. At least you would only have to do it once.
If you still wish to modify TGET then I suggest using a file compare program to find all the changes between 1.9.2 and the latest version. This should help you find the solution. If you don't already have one, there is a good file compare program (free) here:
http://winmerge.org
James