Kinook Software Forum

Go Back   Kinook Software Forum > Ultra Recall > [UR] General Discussion
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 02-20-2008, 02:13 PM
Jon Polish Jon Polish is online now
Registered User
 
Join Date: 07-21-2006
Posts: 391
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.
Reply With Quote
  #2  
Old 02-20-2008, 03:05 PM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
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.
Reply With Quote
  #3  
Old 02-20-2008, 03:47 PM
Jon Polish Jon Polish is online now
Registered User
 
Join Date: 07-21-2006
Posts: 391
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
Reply With Quote
  #4  
Old 02-20-2008, 04:24 PM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
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.


Last edited by ashwken; 02-20-2008 at 04:54 PM.
Reply With Quote
  #5  
Old 02-20-2008, 04:58 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
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.
Reply With Quote
  #6  
Old 02-20-2008, 05:06 PM
ashwken ashwken is offline
Registered User
 
Join Date: 10-16-2005
Location: Blairsville, GA USA
Posts: 431
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.
Reply With Quote
  #7  
Old 02-21-2008, 02:03 PM
janrif janrif is offline
Registered User
 
Join Date: 07-08-2005
Location: Ridgefield CT USA
Posts: 852
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.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 05:51 PM.


Copyright © 1999-2023 Kinook Software, Inc.