While migrating GRIP programms that worked fine in NX 7.5 in NX 10 i've get error - String is too long
I looked for string variable definition and initialization - all OK. All length limitation observed.
I installed latest MP10 for my NX10.0.3 but error stil happened
Please report this to GTAC. We'll need to know what command you are having trouble with, and whether this is an input string or an output string, so we can try to reproduce it. Thanks!
A couple things to try
1) Use "Print/" statements to see what the strings are
2) Use GRIP in debug mode to examine variables.
Production: NX10.0.3.5 MP16/TC11.2
I'd rather be e-steamed than e-diseaseled
I know what lines is issue. But it all strange
I have variable STRING/LST(2,10) (example)
LST(1) = 'AAAAAAAAAA'
But error message point me in this line - LST(1) = 'AAAAAAAAAA'
the size of LST(1) is not out of bounds.
Also i've got same error message pointing on following constructions:
CHOOSE/'title','option 1','option 2'
PARAM/'enter value', value
I found a note in the What's New doc for NX 10 that may shed some light on this.
GRIP now supports non-ASCII strings in addition to ASCII strings, which enables GRIP to support internationalized characters. Mixed ASCII and non-ASCII strings are also supported.
Internationalized characters are applied in NX Open GRIP programs by using a source file with a UTF-8 starting byte order mark (BOM), thereby enabling GRIP programs to use any character. The BOM is a series of bytes at the beginning of a text file that specifies the encoding of the data contained in the text file and a specific BOM signature marks the text file as containing UTF-8 data. If this signature is not present, the file contains locale data.
Without the UTF-8 BOM file, GRIP programs can still use any characters in the user’s locale. However, GRIP was not enhanced to the new character-based string lengths provided for UTF-8 functionality and GRIP programs still enforce byte-based limits on data. For example, string variables are limited to 256 bytes.
So what locale is your machine using? Is there any possibility that your characters are in UTF-8, even though the ones you mentioned look like ASCII? I tried the code that you showed us on my machine, and it compiles and runs fine - but I am in an ordinary western locale.
The BOM is a series of bytes at the beginning of a text file that specifies the encoding of the data contained in the text file and a specific BOM signature marks the text file as containing UTF-8 data. If this signature is not present, the file contains locale data.
I need to enter BOM signature at the beginning of text file or I just need to change coding type of file to UTF-8?
I'm really not sure, and everything I work with here is ASCII, so I am not seeing the issue. You could try declaring your strings longer, since that note talks about byte-length strings, rather than character-count-length. If you are using two-byte characters, try changing your LST(2,10) to LST(2, 20).
You might also want to check with your local GTAC office, in case they have already run into this and figured out the details.
So, I've found following:
String values in English locale work fine, no errors occure
But if I use non english locale as string value - the length limitation occure for string value - I cant assign more then 20 characters in non english locale for string variable.
I also changed coding type for .grs file to UTF-8 with BOM, UTF-8 without BOM - without result.
As documentation says - without UTF-8 with BOM we have limitations in byte length for strings, but 256 bytes length also supported, but i can use strings more then 20 bytes length