A blog (primarily about Dynamics AX/D365) covering topics like X++, AX for Retail, D365 Commerce, Trade and Logistics, retail concepts, warehousing, etc. Something for everyone. Grab bag blog for whatever I think would help out people in the Dynamics AX/Commerce/Retail community. The opinions expressed on this site are my own and do not necessarily represent the views of my company
Monday, March 7, 2011
AX Carriage Return - Address field
In AX, a field that is an address will likely show up on multiple lines with the street name, city, state, etc on different lines. In previous versions of AX, carriage returns were seen in the AX database and table browser with a '□' value. In AX 2009, you will just see a string value with these squares absent. The spacing is determined some other way.
Since there are no square carriage returns in the strings in AX 2009, how we determine when the values will return to a new line? I've seen an error where there is a magical break in an address with no explanation as to why it would be this way. In the image below, the string in the SalesTable.DeliveryAddress field would look like '272 E ASHE DRASHEBORO, NC 27203US'. Why is there this big blank thing?
The Extended Data Type (EDT)'s DisplayHeight property value specifies the number of lines to be displayed simultaneously when the EDT is displayed in a form.
If the value is NOT equal to 1 (Figure 3), the value will be displayed in a single line like it appears in the DB (eg '272 E ASHE DRASHEBORO, NC 27203US'). If the value is not 1 (Figure 2), it will add the spaces and split up the line into multiple lines. This DOES NOT mean that it will be split into 2 lines. It will split the exact same way it does with 5 but instead show the field in the form with 2 lines and give you a scrolly bar for the field (Yuck!).
Figure 2 – The 'DisplayHeight' value dictates the size of the display
Figure 3 – The 'DisplayHeight' value dictates the size of the display. NOTE: on one line.
This makes me wonder, what happens when this DisplayHeight value is not 1? Using the all of the powers of the internets and the Bing/Google, I didn't get anything. L Looks like it is something that is hidden in the kernel now.
Still can't find anything on this but I solved the issue: On the street, there was a process somewhere that was putting an enter in after the string. This made it look like there was a blank space in it. This blank space would not show up in the address field string but the string could somehow put that in there between the street and the city while not showing the value in a string.
Interesting mystery…
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment