- Home
- User Articles
- How To Write ZEMAX Extensions in FORTRAN
- Home
- Programming ZEMAX
- Extensions
- How To Write ZEMAX Extensions in FORTRAN
How To Write ZEMAX Extensions in FORTRAN
- By Anthony Richards
- Published 22 June 2006
- User Articles , Extensions
-
Rating:
Quirks Found During Development
C-Strings
The main workhorse function, PostRequestMessage, uses two character-string arguments, each consisting of one or more strings of characters separated by commas. All strings used on the C-side are ‘C-Strings’, that is they are and must be terminated with the ‘null’ character, which can be generated within the FORTRAN code using the intrinsic function CHAR with argument 0, CHAR(0). A C-string that is required to be supplied as an argument to one of the C-functions can be generated by adding this character to the end of any FORTRAN string using the concatenation operator ‘//’ thus:
GetString
This C-function included with ZCLIENT takes three arguments: an input C-string, an item number, and an output C-string. The input C-string is presumed to be a sequence of character strings separated by commas (or spaces as I discovered), and the function will locate the appropriate item and copy it into the output string, appending a null character. The location of an item uses the standard C ‘zero’ based counting sequence, where the first item is item 0, the second is item 1 and so on. I have found that in some cases, notably when ZEMAX surface labels are being extracted, that not only is a null character present, but that it can be preceded by both a ‘carriage return’ and a ‘line feed’ character (ASCII codes 13 and 10, decimal, respectively). I use a function called STRIP to strip off these unwanted characters before I contemplate converting the strings to internal numbers using internal READs. The code for STRIP is included with the test code.
One other quirk I discovered was that when faced with a string containing a space, such as one might find in a folder or filename (for example, in the string returned by the GetPath keyword), GetString will take the space as a delimiter, returning a truncated string and counting the remaining part of the string as the next item, thus upsetting the use of the item count to locate the next string. In this case, the delimiting comma was searched for using the intrinsic FORTRAN function INDEX and the required character string length(s) established accordingly.
The main workhorse function, PostRequestMessage, uses two character-string arguments, each consisting of one or more strings of characters separated by commas. All strings used on the C-side are ‘C-Strings’, that is they are and must be terminated with the ‘null’ character, which can be generated within the FORTRAN code using the intrinsic function CHAR with argument 0, CHAR(0). A C-string that is required to be supplied as an argument to one of the C-functions can be generated by adding this character to the end of any FORTRAN string using the concatenation operator ‘//’ thus:
NEWSTRING = OLDSTRING(1:LENGTH)//CHAR(0)On the other hand, when receiving and wishing to use character strings returned by one of the C-functions defined in ZCLIENT, one must be aware of the ‘null’ character that appears at the end of them and one should strip it off before using an internal read to convert a character string containing the digits of a number into a real or integer data item.
GetString
This C-function included with ZCLIENT takes three arguments: an input C-string, an item number, and an output C-string. The input C-string is presumed to be a sequence of character strings separated by commas (or spaces as I discovered), and the function will locate the appropriate item and copy it into the output string, appending a null character. The location of an item uses the standard C ‘zero’ based counting sequence, where the first item is item 0, the second is item 1 and so on. I have found that in some cases, notably when ZEMAX surface labels are being extracted, that not only is a null character present, but that it can be preceded by both a ‘carriage return’ and a ‘line feed’ character (ASCII codes 13 and 10, decimal, respectively). I use a function called STRIP to strip off these unwanted characters before I contemplate converting the strings to internal numbers using internal READs. The code for STRIP is included with the test code.
One other quirk I discovered was that when faced with a string containing a space, such as one might find in a folder or filename (for example, in the string returned by the GetPath keyword), GetString will take the space as a delimiter, returning a truncated string and counting the remaining part of the string as the next item, thus upsetting the use of the item count to locate the next string. In this case, the delimiting comma was searched for using the intrinsic FORTRAN function INDEX and the required character string length(s) established accordingly.