Number format with control characters - why?

[thomas.uttendorfer]

This is a post from the old gupta forum where I found some new answer to - so I copied the original:

Hello,

does anybody know why in the format section the number masks has control characters included (see picture). When I create new one, they didn't.
This happens with all versions of TD, including 6.2 SP1.

.head 3 - Number: 0'%'
.head 3 - Number: #0
.head 3 - Number: ###000
.head 3 - Number: ###000;'('###000')'

You could see them in a texteditor, if the sourcefile was saved as text.

Best regards,

Joerg Bertram

Control characters in SAL outline.jpg

[\Quote]

[thomas.uttendorfer]

We found some clues to the format section in .apt files:
When you add a format in the "Format"-property of a datafield control - this format shows up in the apt in two places

• n the Global Declarations Fromat section

• and in the controls property.

For number formats there appear control characters for decimalpoint and thousands-separator, currency and maybe more.
This is kind of clever since the apt could be opened in an environment where other regional settings are active (e.g. in Germany the decimal-point is a comma, in US it's a point).

Why does it appear twice?
I suppose this is kind of a service for developers since entries from the global format section will be listed in the dropdown boxes of the control properties.
But then a gupta-bug jumps in:

• When you edit formats in the global format section manually then the control character disappear and will be replaced by those you see on the screen (dot and comma for example).

• But then they are useless for TD because it cannot Interpret it correctly anymore.

• And you won't see the difference between a format with or without correct control characters!

• If you select such a format in the properties of a datafield control then it has no effect since TD cannot Interpret it correctly.

So my recommendation is:
Remove the formats in the global format section as soon as possible. Don't give anybody in your team to edit them manually.

[H3PO4]

Hello Thomas,

my answer would be:

Gupta-created formats while making a new application are falsely inserted as ASCII characters (You can verify this with a hex-view on your apt-file).

When you open this file in notepad++ the Formats in ASCII look like control characters.

New inserted formats are in Unicode.

Happy coding!

Henning

[thomas.uttendorfer]

What I forgot to tell:
We investigated the format sections since we had all of a sudden strange app crashes with our compiled application.
We opened (and closed) different form windows which are located in different .apd
After about doing so with about 6 or 7 different forms we got regularly an app crash with BEX and StackHash_xxxx.

After we cleared the format section in each an every .apt and compiled again - we got rid of that nasty problem.

[FRBhote]

That's been a problem since forever. If possible keep nothing in the formats section - or at least regularly remove as much as you can.

Leave the dates as they are useful and don't cause a problem - it's always the number formats.

[J.Bertram]

We also recognized that some crashes are directly related to the format section. Thanks to Thomas, we now know the exact context! Merci!
Joerg Bertram

[Dave Rabelink]

Another thing to consider when using dynalibs (apd's):

http://wiki.tdcommunity.net/index.ph ... el_windows

[thomas.uttendorfer]

Update:

In our case deleting all formats from the global format section made things worse.

What we now do:
We made a tool with cdk which extracts all formats of every datafield and column-control of all of our .apt.
We then made a distinct list of the formats and applied them to the global format section of all of our .apt.
Now things are a bit better.

Regards Thomas