Grid, TextBox, Character field, when save need right justification

[clyderose]

Hello,
I have a table with a character field that needs to be right justified after a user enters data.
It is displayed in a grid using a textbox. Previously this field was accessed using the @...get routine
with the FUNC "J" clause for right justification. This then saved the data to the table with the right justification.

The FUNC "J" does not work by putting .format="J". Even though the "M" still works for lists of valid entries.
Can't use the valid to modify the data appropriately because of the way this form is used for many different tasks.
The grid is set up using parameter arrays containing the column and button info.
UNLESS there is a way to direct .VALID= to use an external function?

Any thoughts would be appreciated!
Clyde

 

[mjcmkrsr]

Hi Clyderose,

You may want to have a look at the Textbox' Alignment property

hth

M.

 

[clyderose]

It is set to right middle.
As in .text1.alignment=1
So, it displays properly, but is saved with left alignment.
The indexing requires right alignment for proper display.
Thanks,
Clyde

 

[Olaf Doschke]

You can't have right alignment in the dbf field, just because the alignment in the textbox is right. No matter if 'abc' is displayed right or left aligned in a textbox, it's saved as 'abc' and a char field lonoger than 3 chars pads it with spaces to the right.

Replace all field with padl(alltrim(field),fieldlength," ") to pad to the left.

The only reason I can think this makes sense in correct ordering is, you are storing numerical inside a char field. Why? Or what are you doing?

You could also index on padl(alltrim(field),fieldlength," ") and store it normal. To store text left aligned also is better for filtering and querying and finding data beginning with 'a' for example, so storing value right aligned in the char field is very unusual.

With VFP9 you have varchar fields, if you store 'abc' in them, you get 'abc' back, and not 'abc ...'. That would also be a solution in conjunction with right aligned display.

Bye, Olaf.

 

[clyderose]

This data is used in a production operation. The user is creating a custom device with many variations. He enters the guidelines such as measuring range and measuring type. The program then accesses multiple tables to pick the primary device and the components that fit that specific device to manufacture the final product to the specifications required.
The data being entered in these two fields is numeric 95% of the time but can have characters as well. The two fields indicate the range that a part can measure, such as 33.1MM to 36.3MM.
The right formatting makes it much easier for the users to maintain this list of components. With left formatting the indexing would cause the fields to be displayed out of order, such as 133.1MM would be before 4.3. The varchar field would create the same display problem.
I had already considered using the padl() as part of the save or dump routine but was hoping there was a way to implement the old, but faithful, FUNC "J" method.
Oh well.
Thanks for the response.
Clyde

 

[Olaf Doschke]

You only can have "J" in screens, not in forms.

The index on PADL(..) would also solve your problem. You can index on that expression instead of a simple index on the field, and you can display right aligned with alignment on top of that, just the storage would be left aligned, that wouldn't hurt.

Bye, Olaf.

 

[Olaf Doschke]

Besides that, the database desing for a range with different units should be rangelow, rangehigh, unit, then you just have two normal numeric fields for the measure. That would be what I would do, don't mix numeric and unit in one field.

I store ingredients of recipes which can be grams or kilo. I always store them as g and it's easy to transform into any wanted unit, even oz, if you'd like. I's much easier to make calculations, statistics etc. with numerical fields, than such a more descriptive field.

Just a thought for an enhancement of your database.

Bye, Olaf.

 

[clyderose]

Changing the way the data is stored in the field would then require changing the code that uses the data to put together the parts list.
Its been running smoothly since the early 90s and I don't want to screw up a good thing.
Have fun, thanks again.
Clyde

 

[Olaf Doschke]

Well, at least you have to use PADL in your save routine, then. You have to make a change.

Let's take aside the field split, the main solution I consider is a one time effort:
1. set alignment in the grid column to right, as suggested by mjcmkrsr.
2. Index on Padl(alltrim(field),40," ") tag xOrder, for the case you want to order by that field

Two actions. That is all needed and the user won't see any difference in that grid already. I don't know how many places you read and display the field, but if there is so much to change, that also points to the need to do things more reusable.

Bye, Olaf.