What's the best way to impose formatting in a grid that saves the special characters 2

[Booleanist59]

What's the best way to impose formatting in a grid that saves the special characters back to a free table's char field in VFP6.

Let's say I want to use 3 types...
1). Phone number (800) 555-1212
2). Social Security Number 123-45-6789
3). Zip Code 08102-5102

I want the characters to appear in the box so the user doesn't have to type anything but the numbers but I need the special characters to be saved with the data entry into the field. I tried the DynamicInputMask of "@R 99999-9999" at the Column level of a grid and it worked on a zip code but does not save the dash with the data to the field in the table.

I tried the DynamicInputMask of "@R (999) 999-99999" at the Column level of a grid for a phone number field but didn't show any special characters in the field but saves whatever I type into the character field.

Is there a "Best Way" in VFP6 to handle imposing a template on data entry in a grid's cell that saves the special characters into the free table's field?

Any thoughts or suggestions would be appreciated,

Dave



* The 2nd mouse gets the cheese

 

[Mike Lewis]

Hi Dave,

Why are you are using DynamicInputMask? You should be using the plain old InputMask. (Unlesss I am missing something.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Using Inputmask instead of DynamicInputmask will not change anything, or am I missing something, Mike?

The inputmask also is a displaymask, kind of. It's the normal behaviour the value doesn't contain the static mask, this way you save some bytes, your table field only needs to store the digits. There is no way, so there also is not best way to store the value including the mask.

You would need to store the Displayvalue of the textbox, so you would need to have the grid field unbound, which doesn't really work. Not only because of what I said about grids in your last thread, also because you want to display table values and store that back.

I don't really see a problem, you could simply use the input mask is it is intended anyway.

Let's assume you could store the mask combined with the digits. Now you make the second display of the value with an input mask and you'd have the mask character displayed within the mask. This don't works out in any way I could think of.

I understand what you want, but then you'd need a way to stripe off the mask characters when displaying the data in a control with the input mask and put it back, when saving. But both the loaded and the stored value must be the same because of the two way nature of the controlsource.

So take the intended way. To get the value including the mask into reports, you know you can use the TRANSFORM() function with @R. So you have all you need to display data as needed and store only the varying part of the data, the mere digits. I think that is nice, even in the age of petabytes.

Bye, Olaf.

 

[Mike Lewis]

Using Inputmask instead of DynamicInputmask will not change anything, or am I missing something, Mike?

Hmmm. You're right that you can use exactly the same character string in both cases, and get the same result. But surely the purpose of a DynamicxXX property is to evaluate a condition, based on values in the grid's current row. Just putting the mask there won't do that. That's why I was asking Dave why he used the Dynamic property.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Booleanist59]

I'm looking for the path of least resistance (don't want to cause more problems than I'm fixing) while I'm stabilizing and rewriting pre-existing systems. Given the lack of experience this guy had in a multi-user environment, I already have routines to parse tables and standardize mixed data entry formats. It's faster to build them up and store the formatting rather than weed them down - too many exceptions trying to shorten them and plenty of storage room here to justify the time savings.

Thanks Gentlemen,

Dave


* The 2nd mouse gets the cheese

 

[Olaf Doschke]

Well, to "weed them down" is the path of least resistance, even if it's hard. There is no way to have an input mask and save it.

You know, likewise with pie.

? Transform("123456789","@R ###-##-####") && displays 123-45-6789
? Transform(Transform("123456789","@R ###-##-####"),"@R ###-##-####") && displays 123--4-5-67

That's what happens, if you could store the data including the mask and then display that data with the mask for the second time. You get mask character where they should not be.

a Textbox bound to a field "ssn" via it's controlsource and with an inputmask of ###-##-#### will display the number with dashes correctly only, if it's stored in the ssn field without dashes. You can read the value including dashes from the Text property, but the value property will be the value without the dashes, and that's what's saved.

It is that way and there is no way around it no matter how much force you would apply. So as this is impossible to solve without creating some general purpose code to stripe off the mask characters from the data before binding it to a form control, which would be hard to do, I think it's simpler to do with the data once, with each individual case of data and mask.

You know the CHRTRAN() function, don't you? You can use it to filter for digits only, for example, by using it twice:

value = "!! 123-4#5-6789 gallons"
? chrtran(value, chrtran(value,"9876543210",""),"")
The inner chrtran removes digits, all non digits remain and are used as the "array" of characters to remove from the value in the second pass.

So you can also simply stripe off dahes with chrtran(ssn,"-",""). So you could use that expression as the controlsource and then save textbox.text back, but then you can't use the controlsource to save changes and the textbox will be readonly, if your controlsource is an expression.

See? You can turn it, as you like, but in the end you'd have to program something to wheed the data down to the net data without the mask in some way. And if you have your data that way it's simplest to use the inputmask as intended and save net data. You won't need complex expressions and can simply use the controlsource/inputmask combination for data editing and display. The clensing of the data then is a one time job, which always is less error prone than having something complex embedded into your application needing to work for all time, just because you want to enforce something on a programming language against it's concept. So where is your argument about the way of least resistance now? I don't see how it holds true, if you want to go a route of storing data with mask characters.

Bye, Olaf.

 

[DSummZZZ]

The difference is the "@R". Using "@R 99999-9999" tells VFP to display the formatting but not include it. If you want the special characters saved don't use the "R" in the format, just use something like "99999-9999"

Try this:
STORE SPACE(15) TO cx
@ 1,1 GET cx PICTURE "@R 999-99-9999"
READ
?cx

Then try this:
STORE SPACE(15) TO cx
@ 1,1 GET cx PICTURE "999-99-9999"
READ
?cx


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

Inputmask does not make that difference, as far as I know.
So we have to go back to Screens, then?

Bye, Olaf.

 

[Olaf Doschke]

I played a bit with the FORMAT property. Setting Format "R" does remove mask chars. Setting Format to empty (the default), the mask characters are not removed in the textbox.value.

That means I was wrong, sorry. That happens, if you are too sure about something. Sorry for bothering you, bu Dave reminded me the PICTURE equals the TRANSFORM parameter and in visual controls that is split to inputmask and format. Maybe I worked with derived textbox classes for too long. I have to check, but actually I think my base textbox class does not include "R", but rather defaults to "K". "K" makes the textbox select all text when it gets the focus.

Anyway, I still find it neat to remove mask chars from data and also think it's easier to brush off your data than to transform mixed states in your data to always include the mask. A big advantage is, if there is the seldom case of a change in the inputmask, say SSNs now move their dashes, or an additional digit is introduced, which moves one or both dashes. You would need to transform all stored SSNs before being able to set a new inputmask. So the disadvantage of not using R is, that the values now have to have the mask characters in them in sync with the inputmask, otherwise digits are hidden by dashes, eg inputmask = "9-9", format="" and value = "99" displays "9-", the second 9 hides behind the dash, but still is in the value.

Anyway, now it's your choice.

The argument you need code to stripe off mask chars is replaced by the argument you need to keep them in sync with the input mask and format used in the form. In the table designer you can specify format and inputmask for table fields as meta data, so there you even have a way to keep this centralized with your data, which again is an argument for storing the inputmask with the data. But you would need to read that format and inputmask meta data via DBGetPRop() and set form controls format and inputmask accordingly, if you want to use that meta data about the fields in all forms to be in sync with your data model. That meta data also is used, if you drag a field from data environment to the form, at design time. But it's only done at that point, it won't update, if the meta data changes, like forms also don't update controlsources, when you alter field names. And sql queries will not add such meta data to the query result cursor, as it's a db property, not a workarea property.

You'd always have to struggle with changes in something like SSNs anyway, but I'd still opt for Format="R" and brushing off your data to it's net values. I think it's easier to maintain, even and especially, if using the meta data format and input mask of the table designer, too.

Bye, Olaf.