We have an NX Open external program that creates watermarked CGMs of NX drawings. The command line arguments are the file name and the watermark text. We are moving to a different file naming convention and the program will not recognize the new file names. It throws an error and exits.
Does the NX Open executable look at the Customer Default file versioning rule to determine a valid file name, or is the versioning rule embedded at compile, or does it get that information from somewhere else?
I can change the name of a file in the OS and make it work, or not work.
NX 126.96.36.199 MP2 on Win7, executable compiled in NX 7.5.?.?
Thanks for the help.
Solved! Go to Solution.
"Does the NX Open executable look at the Customer Default file versioning rule to determine a valid file name, or is the versioning rule embedded at compile, or does it get that information from somewhere else?"
You would really need to look at the source code to find that answer. Can the progam limit the file name based on the NX versioning rule? - Yes, if it is programmed to do so. Does it have to look at the versioning rule? - No.
Does the program generate any error messages?
Do you notice a pattern in the input that is accepted vs. what is rejected? All the accepted named conform to the versioning rule and none of the rejected ones do? Are there any certain characters common in the file names that get rejected (perhaps a space character in the file name that wasn't allowed before)?
If there is a space in the new file name, perhaps the command line input is being interpreted incorrectly; try placing double quotes around the file name in the command line input.
It is definitely not embedding that file when you compile your program.
Here is a simple method you can use to test whether NX is reading that file.
In the command shell where you are going to run the program,
(That is a dot after the equals sign, but it is hard to see on my monitor.)
Then run the external program.
In the resulting syslog, look for this string:
Processing customer default values file
If it is reading a DPV file, this should show it.
Thanks for the response. I reexamined the code and found a snippet that was expecting specific characters that are in the old filename format, but not the new one. It was in the subroutine that creates the cgm filename. Go figure.
Great suggestion. I now know that it does read the local customer defaults file. That lead me back to the code, where I found my problem. Thanks for your help.