|
#1
|
|||
|
|||
Printing contact information
I have a custom template I use for my phone book. I created two zip code attributes, one for business, the other for home. They are both strings (but I think this does not matter in UR because there are no validity checks - is this correct?).
There are zip codes with leading zeros that appear correctly on my computer, but the leading zero gets stripped when printed. So 07726 gets printed as 7726. Why? Jon P.S. OOPS! It seemed that the leading zero was kept but I navigated away from the item and returned to find it missing. I thought string should be treated as text and therefore any input would be literal. Any way around this? Last edited by Jon Polish; 02-20-2008 at 02:20 PM. |
#2
|
|||
|
|||
Jon,
This was discussed a couple months ago, can't put my finger on the thread... The "fix" was to include the Attribute in the Item Attribute Pane of the Template - for some reason this forced UR to see the field as text when it is used on a Form. EDIT: here's the earlier discussion: http://www.kinook.com/Forum/showthre...&threadid=3248 Last edited by ashwken; 02-20-2008 at 03:24 PM. |
#3
|
|||
|
|||
Thanks. I saw the thread, I added the attributes to my template and it worked (of course). But I don't see why this is a requirement. Entries made to a form are the same as entries made to an attribute in the panel, no? Since they are the same I don't understand why exposing an attribute in the pane make any difference. Now that I noticed this failure, I must go through my contacts and revise the information.
This will turn into a project because some of my "foreign" (non-USA) contacts have leading zeros elsewhere in their addresses. So those fields will have to be identified and added too. It makes the attribute panel a cluttered mess. Jon |
#4
|
|||
|
|||
Quote:
It would appear that there is a dis-connect between the IA Pane and the Form, it's as if you need to "declare" the Attrribute before it'll be properly recognized on the Form - but only for String Attributes that will contain a leading zero. Maybe this will be resolved in the next version. Not sure what to suggest to ease your clean-up project. EDIT: from the earlier thread, by kinook Quote:
Last edited by ashwken; 02-20-2008 at 04:54 PM. |
#5
|
|||
|
|||
It's actually due to a SQLite quirk in older versions of SQLite. It will be fixed in the next release since it uses a newer version of SQLite.
Also, another workaround is to simply edit the attribute value again (in the form). The first time you assign a value with leading zeros, if the attribute didn't already exist, the leading zeroes will get truncated on saving, but after leaving and returning to the item and adding the leading zeroes again, it will retain the leading zeroes. |
#6
|
|||
|
|||
Quote:
|
#7
|
|||
|
|||
Quote:
|
|
|