Portability issues include differences in filenames, separator characters, resolutions and fonts, possible overlapping of labels, and differences in picture formats.
VIs are portable among all platforms on which LabVIEW runs as long as the versions of LabVIEW are the same. VIs that contain platform-specific features, such as .NET or ActiveX, are not portable. Porting in these cases breaks the VIs.
LabVIEW uses the same file format on all platforms.
When you open the VI on the new platform, LabVIEW detects the VI is from another platform and recompiles the VI to use the correct instructions for the current processor. If you transfer VIs on a disk formatted for a different platform, you may require a utility program to read the disk.
You cannot port the following VIs:
To ease porting VIs among platforms, consider the VI filename. Windows, macOS, and Linux filenames can have 255 characters, including the .vi extension. Avoid using characters in a filename that are invalid on another platform. The colon (:) is invalid on macOS, the slash (/) is invalid on Linux, and the following characters are invalid on Windows: \, /, :, *, ?, ", <, >, and |.
To avoid complications, save VIs with names valid for all platforms or save them in an LLB. The LLB name must conform to platform limits, but VIs in LLBs can have names up to 255 characters, regardless of platform. Thus, LLBs are the most convenient format for transferring VIs because LLBs eliminate most file system dependencies.
Filenames are case sensitive on Linux but not elsewhere. If you refer to a VI by name, capitalize the name consistently wherever you use it.
If you develop a VI for use on other platforms, do not use platform-specific path separator characters \ , / , : in filenames. Avoid any special characters in filenames because different file systems interpret them differently. For example, hidden files on Linux begin with a period.
Fonts can vary from platform to platform. After you port a VI, select new fonts to obtain an appealing display. When you design VIs, keep in mind the three fonts that map best among platforms: the Application font, the System font, and the Dialog font.
The Application font is the LabVIEW default font used in the Controls palette, the Functions palette, the context help, and tip strips.
The System font is the LabVIEW default font used for menus.
The Dialog font is the LabVIEW default font used for text in dialog boxes and system controls.
The default font is the same for all three fonts depending on the platform.
When you port a VI that contains one of these fonts to another platform, LabVIEW ensures the font maps to something similar on that platform.
If you do not use the defined fonts, the font can change size on the new platform because of the differences in the fonts available and differences in the resolution of the display on the other platform. For example, if you select Geneva or New York on macOS and port the VI to Windows, LabVIEW cannot find that font name on Windows and substitutes it with Arial. The substituted font may not match the original, and objects may overlap. If you port a VI to Windows and Windows does not recognize the fonts, the new font may display differently.
Similarly, a font may not be recognized on another language system. For example, a Japanese system may not recognize the Windows font Arial. Use Application, Dialog, and System fonts to avoid resetting the fonts after localizing an application.
If you use a defined font on a section of text, avoid changing the size of that text. If you change the font to something other than the default size and then port the VI to a different platform, LabVIEW tries to match the font with the new size, which might be inappropriate depending on the resolution of the screen.
A computer represents data as bytes. It stores letters and other characters by assigning each character a code.
In the simplest case, one byte corresponds to one character according to a mapping table, or encoding. Most operating systems support many different encodings. One type of encoding is single-byte encoding, which can represent up to 256 characters. To represent additional characters beyond English characters, operating systems also support multi-byte encodings. Multi-byte encodings can represent thousands of characters but require multiple bytes for each character. Japanese and Chinese systems use multi-byte encodings to represent several thousands of characters. Almost all operating systems also now support variable-byte encodings that use fewer bytes for more common characters. A variable-byte encoding, such as UTF-8, uses a single-byte for the first 128 characters and adds an additional byte as needed to expand the number of possible character representations.
|
Note��In applications on multi-byte systems, do not attempt to parse a string by converting the string into an array of bytes because certain characters may use two bytes. Some String functions do not handle multi-byte characters. |
The most common 8-bit encoding in the United States and Western European countries is ISO Latin I, which is an extension of ASCII.
ASCII encoding is a 7-bit code (from 0 to 127). It contains upper and lowercase English, American English punctuation, base 10 numbers, and a few control codes. Control codes are a set of non-displayable characters used for text formatting. You can print most of the ASCII characters in the \0x21 to \0x7F range.
To represent international characters, operating systems support 8-bit encodings such as ISO Latin 1 as extensions of ASCII. The lower 128 character codes are identical to ASCII, and the upper 128 are different for each encoding. The various international characters reside in the upper 128 character codes. LabVIEW for Windows and Linux use 8-bit character sets but different encodings, which can cause portability problems.
For the United States and Western European countries, LabVIEW for Windows and Linux use the ISO Latin 1 encoding, also known as a code page. For operating systems localized to Japanese, Chinese, or Korean, LabVIEW uses different multi-byte encodings to represent characters in each of these languages. LabVIEW determines which encoding to use based on the OS system locale and language settings. These encodings are the same on Windows and Linux, so portability is less of an issue. However, LabVIEW for macOS (64-bit) uses a variable-length extension of ASCII called UTF-8, which can represent any language.
|
Note��All operating systems support the UTF-8 encoding. However, LabVIEW does not use UTF-8 on Windows to maintain compatibility with existing user applications. |
When you port a VI from one platform to another, such as from macOS to Windows or from Windows to macOS, you might encounter problems because of the differences between platform code pages, especially if you use non-ASCII characters in the upper 128 range. For example, the word caf� in French uses the extended character �, whose hexadecimal value is \0xE9 on Windows. To display this same character � on 64-bit macOS, you use the two-byte sequence \0xC3\0xA9.
LabVIEW performs a code page conversion for elements such as captions, VI and parameter tips and descriptions, VI titles, and other private data. Private data includes listbox item names, table row and column headers, font used for table cells, graph plot names, graph annotation names, and cursor names. However, LabVIEW does not map labels or string content. Labels and string content might not appear as you expect after you port them to a new platform, and you may need to modify them manually. Therefore, if you plan to port your VIs from Windows or Linux to macOS and vice versa, avoid using international characters in labels or string content.
LabVIEW does not map string content because strings can be interpreted as binary information. If you communicate with an instrument using GPIB or serial communication and if your instrument expects the binary string \0x63\0x61\0x66\0xC3\0xA9, this string appears as caf� on the 64-bit macOS platform, and it appears as café on the Windows platform. In both cases, you should send the same binary string to the instrument. To avoid this type of communication error, LabVIEW does not perform character mapping on string values.
LabVIEW does not map labels because remapping labels to a new encoding can break a VI. For example, if you use the Unbundle by Name function and LabVIEW remaps the labels of cluster contents, the VI can break because references to the control by name no longer match.
When you move a VI to a new platform, controls and labels might change size, depending on whether the fonts are smaller or larger on the new platform. LabVIEW tries to keep labels from overlapping their owners by moving them away from the owning control. Also, every label and constant has a default Size to Text attribute. When you first create a label or constant, this attribute is set so the bounds of the object resize as necessary to display all the enclosed text.
If you manually resize the label, LabVIEW turns off this attribute, and the item in the shortcut menu no longer shows a checkmark. With Size to Text turned off, the bounds of the object stay constant, and LabVIEW clips or crops the enclosed text as necessary. If you do not want LabVIEW to clip text when you move among platforms, leave this attribute on for labels and constants. After you resize the label, you can manually turn on Size to Text.
Not all computers have high-resolution monitors. However, if you have a monitor with a high resolution, do not make your front panels very large if you want them to port well. For best portability results, leave extra space between controls and avoid overlapping controls. When you port a label that overlaps another label, it might overlap the whole control when you enlarge the font on the new platform.
The most basic type of picture contains a bitmap, which is a series of values that specify the color of each pixel in the picture. More complex pictures can contain commands the computer system executes every time it displays the picture.
Use the paint layer of a graphics application to create bitmap-based pictures. Bitmaps are common storage formats for pictures on all platforms. If you use pictures that contain bitmaps on front panels, the pictures usually look the same when you load the VIs on another platform. However, pictures that contain drawing commands such as filling might include commands that other platforms do not support. Check how VIs look on another platform if you expect to use them there.
Use the draw layer of a graphics application to create pictures that contain drawing commands. To make the pictures more portable, paste the final picture into a paint layer of a graphics application before you import the picture into the VI.
(Windows and macOS) With some graphic applications on Windows and many graphics applications on macOS, you can cut or copy a picture with a nonrectangular shape. For example, on macOS, you can use a Lasso tool to select the outline of a circle, triangle, or a more complicated shape such as a musical note.
Other platforms might draw these irregular shapes on a rectangular white background. On Windows, if you want pictures with irregular shapes and pictures that scale well, use applications that support enhanced metafiles.