プラットフォーム間でVIを移植する



LabVIEW 2018ヘルプ


発行年月: 2018年3月
製品番号: 371361R-0112
製品情報を参照

ダウンロード (Windowsのみ)


LabVIEW 2016ヘルプ
LabVIEW 2017ヘルプ
LabVIEW 2018ヘルプ
LabVIEW 2019ヘルプ
LabVIEW 2020ヘルプ

移植性に関する問題点として、ファイル名、区切り文字、画面解像度とフォント間の差、重複するラベル、画像形式間の差などがあります。

移植可能なVIと移植不可能なVI

VIの移植は、LabVIEWのバージョンが同じである限り、LabVIEWが実行するすべてのプラットフォーム間で可能です。.NETまたはActiveXなどのプラットフォームに依存する機能を含むVIは移植できません。VIは、移植すると破損します。

LabVIEWは、すべてのプラットフォームで同じファイル形式のVIを使用します。

VIを新しいプラットフォームで開くと、LabVIEWはVIが別のプラットフォームからのVIであることを検出し、現在のプロセッサ用に正しい命令を使用するようにVIを再コンパイルします。異なるプラットフォーム用にフォーマットされたディスクにVIを転送した場合は、ディスクを読み取るためにユーティリティプログラムが必要になる場合があります。

以下のVIは移植できません。

  • vi.libディレクトリ内に含まれるVIです。LabVIEWの各配布には、独自のvi.libが含まれています。vi.libのVIは、プラットフォーム間で移動しないでください。
  • 互換性VI―VIを旧バージョンのLabVIEWで作成し、新しいバージョンのLabVIEWでそのVIを開く場合、LabVIEWは互換性VIを使用します。互換性VIは、旧バージョンのLabVIEWの機能をエミュレートします。これらのVIはプラットフォームに依存する共有ライブラリを呼び出すため、移植すると壊れます。
  • ライブラリ関数呼び出しノードを含むVIです。ライブラリ関数呼び出しノードが参照する名前と一致する名前のライブラリがない場合、ライブラリ関数呼び出しノードを含むVIを移植すると破損します。
  • プラットフォームに依存する通信VI (Windowsの.NETまたはActiveX関数、macOSのAppleEvent VIなど)。
  • VISAピーク」および「VISAポーク」関数

ファイル名の違い

プラットフォーム間でのVIの移植を容易にするためにも、VIのファイル名の付け方に留意してください。Windows、macOS、およびLinuxでは.vi拡張子を含めて255文字までファイル名に使用できます。他のプラットフォームで無効な文字をファイル名に使用しないでください。コロン (:) は、macOSでは無効です。スラッシュ (/) はLinuxでは無効です。\/:*?"<>|はWindowsでは無効です。

混乱を避けるためにも、VIを保存する場合はすべてのプラットフォームに対して有効な名前をつけるか、またはVIライブラリの一部として保存してください。LLB名はプラットフォームでのファイル名規則に従う必要がありますが、LLBに保存するVIの名前はプラットフォームに関係なく255文字まで使用できます。したがって、LLBはファイルシステムに依存しないため、VIを転送する最も便利な方法です。

Linuxプラットフォームに限り、ファイル名の大文字と小文字が区別されます。VIを名前で参照する場合は、大文字/小文字の使い分けに一貫性を持たせるようにしてください。

区切り文字の相違

異なるプラットフォーム上で使用するVIを開発する場合、ファイル名のパスの区切り文字としてプラットフォームに依存した文字(\、/など)は使用しないでください。ファイル名に含まれているこれらの特殊文字は、プラットフォームごとに異なって解釈されます。たとえば、Linuxの場合、隠しファイルのファイル名の最初の文字としてピリオドが使用されます。

画面解像度とフォントの相違

フォントはプラットフォームによって異なります。VIを移植した後、そのプラットフォームでの表示に適したフォントを選択してください。VIを設計する際は、各プラットフォームで最適なアプリケーションフォント、システムフォント、ダイアログフォントを使用するよう注意してください。

アプリケーションフォントは、制御器パレット、関数パレット、詳細ヘルプ、ヒントラベルで使用されるLabVIEWのデフォルトフォントです。

システムフォントは、LabVIEWのメニューに使用するデフォルトのフォントです。

ダイアログフォントはダイアログボックスとシステム制御器のテキストに使用されるデフォルトフォントです。

プラットフォームによっては、3つのフォントのデフォルトフォントがすべて同じである場合もあります。

  • (Windows) デフォルトで英語にはSegoe UI、日本語にはメイリオが使用されます。
  • (macOS) デフォルトでLucida Grandeが使用されます。
  • (Linux) デフォルトでHelveticaフォントが使用されます。

異なるプラットフォームに移植する際、VIに上記のフォントのいずれかが含まれている場合、移植先のプラットフォームに対して適切なフォントが自動的にマップされます。

上記以外の未定義フォントを使用すると、移植先プラットフォームでフォントのサイズが変わる場合があります。これは、移植先プラットフォームで使用可能なフォントの種類や表示解像度の違いによって起こります。たとえば、macOS対応LabVIEWのVIでGenevaまたはNew Yorkフォントを使用し、そのVIをWindowsに移植した場合、Windows上ではこれらのフォント名が検出されないので、Arialフォントが代わりに使用されます。代用されるフォントは元のフォントとは異なるため、オブジェクトが重なってしまうことがあります。また、Windowsによって認識されないフォントが含まれているVIを移植した場合にも別のフォントで代用されるので、表示が異なってしまうことがあります。

同様に、フォントが他の言語システムで認識されない場合もあります。たとえば、日本語のシステムの場合は、WindowsのArialフォントを認識しない場合があります。アプリケーション、ダイアログ、およびシステムフォントを使用することによって、アプリケーションのローカライズ後に再設定することを避けることができます。

定義済みのフォントをテキストの一部に使用する場合は、そのテキストの部分のフォントサイズは変更しないでください。デフォルト値以外のフォントサイズに変更したテキストを含むVIを異なるプラットフォームに移植すると、LabVIEWによってフォントのサイズ変更が行われ、移植先プラットフォームの画面解像度によっては正しく表示されない場合があります。

文字コードの問題

コンピュータはデータをバイトで表示します。文字や記号にはコードが割り当てられて保存されます。

単純なケースでは、1バイトはマッピングテーブル(エンコーディング)に従って1文字に対応します。ほとんどのオペレーティングシステムは、多く異なるエンコーディングをサポートします。1つのタイプのエンコーディングとしてシングルバイトエンコーディングがあり、256文字までを表すことができます。英字以外の文字を表すために、オペレーティングシステムはマルチバイトエンコーディングもサポートします。マルチバイトエンコーディングは数千文字を表すことができますが、1文字につき複数バイトを必要とします。日本語システムや中国語システムでは、数千文字を表すためにマルチバイトエンコーディングが使用されます。現在は、多くの共通文字にそれより少ないバイト数を使用する可変バイトエンコーディングもほとんどすべてのオペレーティングシステムでサポートされています。UTF-8などの可変バイトエンコーディングは、最初の128文字には1シングルバイトを使用し、可能な表示文字数を増やすために必要に応じてバイトを追加します。

メモ  マルチバイトシステム上のアプリケーションでは、特定の文字が2バイト使用している可能性があるため、文字列をバイトの配列に変換することによって文字列を区切ることは避けてください。一部の文字列関数は、マルチバイト文字を処理しません。

米国と西欧諸国で最も一般的な8ビットエンコーディングは、ASCIIの拡張版であるISOラテン Iです。

ASCIIエンコーディングは0~127までの7ビットコードです。このコード内には、アルファベットの大文字と小文字、英語で使用される句読点、0~9までの数字、およびいくつかの制御コードが含まれます。制御コードはテキストの書式化に使用される、画面には表示されない一連の特殊文字です。\0x21~\0x7F内のASCII文字の多くは印刷可能です。

国際文字を表示するために、オペレーティングシステムは、ASCIIの拡張版であるISOラテン Iなどの8ビットエンコーディングをサポートします。このシステムでは、下位128バイトはASCIIの文字と同一ですが、上位128バイトは各エンコーディング(言語)によって異なります各言語で必要な文字が上位128文字コードに割り当てられています。Windows用およびLinux用のLabVIEWは、8ビットの文字セットを使用しますが、使用するエンコーディングが異なるため、移植に関する問題が発生する場合があります。

米国および西欧諸国用には、Windows用およびLinux用LabVIEWはISOラテン 1エンコーディング(コードページとも呼ばれる)を使用します。日本語、中国語、韓国語にローカライズされた版のオペレーティングシステムでは、LabVIEWは、これら各言語の文字を表すためにそれぞれ異なるマルチバイトエンコーディングを使用します。LabVIEWは、使用するエンコーディングをOSのシステムロケールと言語設定に基づいて決定します。これらのエンコーディングは、WindowsおよびLinuxで共通なので、移植性はそれほど問題になりません。しかし、macOS (64ビット) 用LabVIEWは、任意言語の表示が可能なUTF-8と呼ばれるASCIIの可変長拡張版を使用しています。

メモ  すべてのオペレーティングシステムはUTF-8をサポートします。しかし、既存のユーザアプリケーションとの互換性を維持するために、WindowsではLabVIEWはUTF-8を使用しません。

macOSからPCへ、またはPCからmacOSへなど、特定の2つのプラットフォーム間でVIを移植する際には、プラットフォームごとのコードページの違いから問題が発生する場合があります。特に上位128バイトの非ASCII文字が使用されている場合によく問題が発生します。たとえば、Windowsでは、フランス語のcaféという単語には拡張文字é(16進数の\0xE9)が使用されます。これと同じ文字éを64ビット版のmacOSで表示するには、\0xC3\0xA9という2バイトシーケンスを使用します。

LabVIEWでは、キャプション、VIやパラメータのヒントと説明、VIタイトル、その他のプライベートデータなどの要素にコードページ変換が行われます。プライベートデータには、リストボックスの項目名、テーブルの行と列のヘッダ、テーブルセル内で使用されるフォント、グラフの注釈、カーソルの名前などがあります。ただし、LabVIEWではラベルや文字列値はマップされません。ラベルや文字列値を異なるプラットフォームに移植した後、それらが意図したとおりに表示されない場合があります。そのような場合は手動で修正する必要がありますしたがって、WindowsやLinuxからmacOSへ、またはOS XからWindowsやLinuxへの移植を行う場合は、ラベルや文字列値に上位128バイトの文字を使用しないようにしてください。

文字列はバイナリデータとして解釈可能なので、LabVIEWは文字列値をマッピングしません。GPIBまたはシリアル通信を使用して通信している計測器にバイナリ文字列の\0x63\0x61\0x66\0xC3\0xA9を送信する場合、この文字列は、64ビット版のmacOSプラットフォームではcafé、Windowsプラットフォームではcaféと表示されます。いずれの場合でも、計測器には同じバイナリ文字列を送る必要があります。このような通信エラーを避けるために、LabVIEWは文字列値に対して文字マッピングを行いません。

ラベルを新しいエンコーディングに再マッピングすると、VIが壊れる場合があるので、LabVIEWはラベルをマッピングしません。たとえば、「名前でバンドル解除」関数を使用しており、LabVIEWがクラスタコンテンツのラベルを再マッピングすると、名前による制御器へのリファレンスが一致しなくなり、VIが壊れます。

ラベルの重なり合い

VIを異なるプラットフォームに移動した後、移動先プラットフォームのフォントサイズの大小によって制御器とラベルのサイズが変わる場合があります。LabVIEWでは、所有制御器からラベルを遠ざけることによって、所有制御器と重ならないように処理されます。また、各ラベルと定数には、テキストにサイズを合わせる属性がデフォルトで設定されています。この属性により、ラベルまたは定数を初めて作成する際にラベルや定数内のテキストがすべて表示されるよう、必要に応じてサイズが変更されます。

手動でラベルのサイズ変更を行うと、この属性がLabVIEWによって無効にされ、ショートカットメニュー内の項目のチェックマークが外されます。テキストにサイズを合せる属性が無効な場合、オブジェクトのサイズは一定に保たれ、LabVIEWによってオブジェクト内のテキストが切り捨てられたり切り詰められます。プラットフォーム間で移植する際にテキストが切り捨てられないようにするには、ラベルと定数に対するこの属性を有効のままに設定しておいてください。ラベルのサイズを手動で変更した場合には、テキストにサイズを合わせる属性を手動で有効に設定し直すことができます。

すべてのコンピュータで高解像度モニタが使用されているわけではありません。したがって、フロントパネルを移植する予定がある場合に高解像度のモニタを使用して作業するときは、フロントパネルのサイズを過度に大きくしないでください。最適な移植結果が得られるよう、制御器間には十分な間隔を置き、制御器が重なり合わないようにしてください。他のラベルに重なるようなラベルを移植した場合、移植先プラットフォーム上でフォントサイズを大きくした際にラベルが制御器全体に重なる可能性もあります。

画像の相違

最も基本的な画像には、画像を構成する各ピクセルの色を指定するための一連の値を持ったビットマップが含まれています。より複雑な画像には、画像表示のたびに実行されるコマンドが含まれていることもあります。

ビットマップベースの画像を作成する場合は、グラフィックアプリケーションのペイントレイヤを使用します。ビットマップは、すべてのプラットフォームで一般的に使用される画像の保存形式です。フロントパネルにビットマップ画像を使用した場合、異なるプラットフォームでVIをロードした後でもその画像は同じように表示されます。ただし、塗りつぶしコマンドなどの描画コマンドを使用した画像の場合は、異なるプラットフォームでそのコマンドがサポートされていないこともあります。描画コマンドを使用した画像を含むVIを異なるプラットフォームで使用する場合には、目的のプラットフォームでどのように表示されるかを確認してください

描画コマンドを含む画像を作成する場合は、グラフィックアプリケーションの描画レイヤを使用します画像の移植性が高まるよう、画像をVIにインポートする前に、完成した画像をグラフィックアプリケーションのペイントレイヤに貼り付けます。

(WindowsおよびmacOS) Windows用の一部のグラフィックアプリケーションやmacOS用の多くのグラフィックアプリケーションでは、画像の切り取りや貼り付けを、長方形または正方形だけでなく、画像の輪郭の形状で行うことができます。たとえば、macOSの場合、投げ縄ツールを使用することで円や三角形に加え、音符のような複雑な図形の枠線を選択できます。

他のプラットフォームでは、このような複雑な形状の図形は無背景の四角形領域の上に描画される場合もあります。Windowsで作業する場合、不規則な形状の図形が適切にスケールされるようにするには、拡張メタファイルをサポートしているアプリケーションを使用してください。



この記事は役に立ちましたか。

役に立たなかった