Printing contact information

Jon Polish · #1 02-20-2008, 02:13 PM

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?

ashwken · #2 02-20-2008, 03:05 PM

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

Jon Polish · #3 02-20-2008, 03:47 PM

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

ashwken · #4 02-20-2008, 04:24 PM

Quote:

Originally posted by Jon Polish
...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.

Yeah, that was my question also.

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:

This behavior only occurs if the attribute did not already exist for an item, so you can avoid it by adding the attribute (with a blank value) to the item template.

It would seem that placing Attributes on a Form do not "bind" them to an Item (or the Template of the Item), but this only seems to be an issue with this particular situation.

kinook · #5 02-20-2008, 04:58 PM

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.

ashwken · #6 02-20-2008, 05:06 PM

Quote:

Originally posted by kinook
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.

Thanks for the insight on the source of this problem, looking forward to the upcoming release.

janrif · #7 02-21-2008, 02:03 PM

Quote:

Originally posted by ashwken
Thanks for the insight on the source of this problem, looking forward to the upcoming release.

Hope this project is not high priority. Last time I asked about next release I was told sometime between March - June (if memory serves me correctly) so, potentially, it could be a wait.