Picture in GET problem

Picture in GET problem

Postby Patrick Mast » Fri Apr 13, 2007 1:04 pm

Hi,

Consider this:

Code: Select all  Expand view
#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:
Image

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
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby Antonio Linares » Fri Apr 13, 2007 2:48 pm

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"
Image
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Antonio Linares
Site Admin
 
Posts: 42078
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain

Postby Patrick Mast » Fri Apr 13, 2007 2:59 pm

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. :D

Patrick
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby James Bott » Fri Apr 13, 2007 7:30 pm

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
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA

Postby Patrick Mast » Fri Apr 13, 2007 8:10 pm

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
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby James Bott » Fri Apr 13, 2007 8:17 pm

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
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA

Postby Patrick Mast » Tue Apr 17, 2007 5:07 am

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
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby Antonio Linares » Tue Apr 17, 2007 6:59 am

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
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Antonio Linares
Site Admin
 
Posts: 42078
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain

Postby Patrick Mast » Tue Apr 17, 2007 7:32 am

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
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby Antonio Linares » Tue Apr 17, 2007 8:00 am

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
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Antonio Linares
Site Admin
 
Posts: 42078
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain

Postby James Bott » Tue Apr 17, 2007 2:25 pm

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
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA

Postby Patrick Mast » Tue Apr 17, 2007 6:36 pm

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! :D

Patrick
User avatar
Patrick Mast
 
Posts: 246
Joined: Sat Mar 03, 2007 8:42 pm

Postby James Bott » Tue Apr 17, 2007 7:44 pm

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
User avatar
James Bott
 
Posts: 4840
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA


Return to FiveWin for Harbour/xHarbour

Who is online

Users browsing this forum: Google [Bot] and 60 guests

cron