ホームページ＞開発ツール＞Xojo / Real Studio / REALbasic コラム（旧その２）

Xojo / Real Studio / REALbasic コラム（旧その２）


　○Real Studio 2011r3 多言語版 　○REALbasic 2008r2 英語版 　○REALbasic 2008r1 英語版 　○REALbasic 2007r5 英語版 　○REALbasic 5.5.5 英語版 　○REALbasic 5.2.1 日本語版(Demo) 　○REALbasic 4.0 Pro 日本語版 　○REALbasic 3.5 Pro 日本語版 　○REALbasic 3 Pro 日本語版 　○REALbasic 2.1.2 Pro 日本語版
　ウィンドウメニューについて

　OS Xのウィンドウメニューの標準的な項目として、「しまう」「拡大／縮小」「すべてを手前に移動」があります。
　これらは、Real StudioのメソッドとCarbonDeclareLibraryを使わせて頂くことで概ね対応できるのですが、以下のような問題点がありました。
  1. 「拡大／縮小」は、Real StudioのMaximizeメソッド／CarbonDeclareLibraryの当該メソッドいずれも、縮小時にウィンドウ位置とサイズが復元されない。
  2. 「しまう」が実行された場合、しまわれたウィンドウに対応するメニュー項目にダイアモンドマークを付加する方法がない。
　この件は暫く放置状態だったのですが、先日偶々いくつかの情報を得ることができましたので、記しておきます。

　まずは「拡大／縮小」ですが、ズーム前に現在の値を待避しておけばいいらしいこと（例えばこちらのサイト）、および、それに必要な関数名が分かりました（例えばこちらのサイト）。そこでこれらを参考に、以下の通りとしてみました。
メソッド名: ZoomWindow
引数: w as Window

Declare Sub SetWindowUserState Lib "Carbon" (window as WindowPtr, rect as Ptr)

Dim bounds As MemoryBlock

if GetWindowInStandardState(w)=false then  // CarbonDeclareLibraryのメソッド（別途コピーしておく）
    
    bounds = NewMemoryBlock(8)
    bounds.Short(0) = w.Top  // top
    bounds.Short(2) = w.Left  // left
    bounds.Short(4) = w.Top + w.Height  // bottom
    bounds.Short(6) = w.Left + w.Width  // right
    
    SetWindowUserState(w,bounds)
    
end if

w.Maximize  // Real Studioのメソッド
　まだシビアなテストは十分ではありませんが、とりあえず動いているようです。

　次にダイアモンドマークですが、こちらは、OS9の頃からDeclareでSetItemMark()を利用するのが定番でした。（CarbonDeclareLibraryにも含まれています。）
　ですが、REALBasic（当時）の仕様が変更され、従来の方式では利用できなくなっていました。
　その代わりとなるものが、以下のサイトで公開されていました。（作者様に感謝します。）
MacWindowMenu : Free Download（USの方からDL可。作者様のサイトはこちら：I Declare: Calling External Functions in REALbasic）

実は、このサンプルはウィンドウメニュー関連一式の機能を持っていて、これだけで（前述の「拡大／縮小」も含めた）全てを賄うことができます。
ただ、ここではSetItemMark()の利用法にフォーカスする目的で、実験的に必要な部分のみ抜粋しています。（例えばローカライズについては、元サンプルはきちんと対応しています。）
なお、標準的なウィンドウメニューを追加するメソッドはCarbonDeclareLibraryにも含まれていますが、こちらは（おそらくはダイアモンドマークの件と同じ理由で）生成したメニューを任意の場所に追加することができないようです。（常にアプリケーションメニューの次になる？）
　これは、従来のGetMenuHandle()の代わりにCarbon Eventを利用してメニューハンドルを取得する、というものです。
Carbon Eventは、あらかじめ必要なイベント（この場合はメニューの表示）を登録しておくと、イベントが発生したときに、登録時に指定したメソッドを呼び出してくれます。
　Carbon Eventの登録は、上述のサンプルのWindowMenu＞RegisterForCarbonEventsをそのままコピーし、AppのOpen等からコールします。
　イベント発生時に呼び出されるメソッドの方は、サンプルを元に以下の通りとしてみました。
（「しまう」が実行されたウィンドウに対応するメニュー項目にマークを付ける方法は、元サンプルに示されています。そちらを参照して下さい。）
メソッド名: HandleCarbonEvent
引数: EventHandlerCallRef as Ptr, EventRef as Ptr, UserData as Ptr
戻り値型：Integer

soft declare function GetEventParameter Lib "Carbon.framework" (inEvent as Ptr, inName as OSType, inDesiredType as OSType, outActualType as Ptr, inBufferSize as Integer, outBufferSize as Ptr, ByRef outData as Ptr) as Integer

dim theMenu as Ptr
dim OSStatus as Integer = GetEventParameter(EventRef, "----", "menu", nil, 4, nil, theMenu)

soft declare function CopyMenuTitleAsCFString Lib "Carbon.framework" (inMenu as Ptr,  ByRef outString as CFStringRef) as Integer

dim menuName as CFStringRef
OSStatus = CopyMenuTitleAsCFString(theMenu, menuName)
if OSStatus <> 0 then
    return -9874 // eventNotHandledErr
end if

if menuName <> "ウィンドウ" then  // ウィンドウメニューでなければ戻る
    return 0
end if

soft declare sub SetItemMark Lib "Carbon.framework" (theMenu as Ptr, item as Short, markChar as Short)

// ウィンドウメニューの最初のメニュー項目にマークを付ける
SetItemMark theMenu, 1, 19  // 19 = ダイアモンドマーク

return 0
　これで、ウィンドウメニューの最初のメニュー項目（いずれも、あらかじめプロジェクトに追加しておく）にダイアモンドマークが付きます。
　戻る　　先頭へ

　標準のヘルプビューアを利用する（その２・HelpBook版）

　本稿は、再構成してこちらに移動しました。(2013/03/12)

　戻る　　先頭へ

　Shellの互換性について

　Shellクラスは、Mode=2にするとインタラクティブモードになり、2008r2では、ターミナル.appと同じような動作をしていました。
　即ち、標準入力から読み込むコマンドラインプログラムでは、Executeでプログラムを起動すると入力待ちとなり、WriteLineでデータを受け取り、EOTを検出した時点で入力処理を終了して、（コマンドラインプログラムが）次のステップへと進んでいくことができました。

　それが2011r3では、同じ結果になりません。（コマンドラインプログラムの出力が得られない。）
　原因はよく分かりませんが、推測できるところとしては、
　・インタラクティブモードにもかかわらず、一瞬で終わっている。（コマンドラインプログラムが動作する間もなくkillまたは放置される？）
　・EOTが機能せず、ずっと入力待ちになっている。
　あたりでしょうか。いずれにしても、Shellの挙動を詳しく観察するというのは、なかなか大変です。

　そこで、手っ取り早くリダイレクトを試したところ、うまくいったので、ひとまずはこれを使う、という選択肢もありそうです。
　なお、リダイレクトの場合は、標準入力に一行ずつ書いていたものを一旦ファイルに書き出すことになる訳ですが、それには一時ファイル（GetTemporaryFolderItem関数で取得）が使えます。
（ちなみにフォルダの方は、SpecialFolder.Temporaryで取得できます。）
　戻る　　先頭へ

　#If文について

　これは2011r3固有ではなく、もっと前からある（少なくとも5.5にはある）話なのですが、気がついたのが比較的最近なのもあって、ここに記しておきます。

　#If文（#If TargetBoolean [Then]）は、条件付きコンパイルで使用するもので、当初はターゲット（Mac/Win/Linuxとか）を切り替えるためのものとして用意されていました。
　それが、いつからか、ユーザ側が自由に設定できように拡張されていました。
手持ちのマニュアルで確認したら、4.5はプリセット定数のみ、5.5では定数または定数式となっていました。
　ただし、コンパイル時に処理されるものなので、（実行時に値がセットされる）変数はダメで、定数で持つ必要があります。
　例えば、
  1. プロジェクトにModuleを追加し、定数「myTarget」を新規作成してデフォルト値をtrueにする。
  2. Window1のOpenイベントに以下を記述。 
    #if myTarget
  me.Title="myTarget"
#else
  me.Title="not myTarget"
#endif
  3. 実行してみる。次に、myTargetの値をfalseにして実行してみる。
　この方法は、実行時に切り替える方式に比べ、（myTargetで）選択されない方でのみ使われるクラスやモジュールを省略できるため、複数のプロジェクトで使い回したいオブジェクトに対して有効と考えられます。
　今まではOSXとOS9の両対応とか、DebugBuild位しか使う機会がなかったので、「あの時知っていれば…」的なことはないのですが、今後は視野に入れておきたいと思います。
　戻る　　先頭へ

　日本語入力時の下線表示の不具合対策

　テキスト入力系コントロール（TextArea等）での、日本語入力時の下線表示が変です。
　本来なら「入力時に細い下線が表示され、変換時には文節ごとに分断されて現在の変換対象が太線表示され、確定とともに消える」筈が「変換時には変換対象以外の文節が太線表示され、確定しても消えない」状態になってしまいます。
　どうも、状態が変化した際のリフレッシュがうまく行ってないような感じです。

　ということで、あれこれ実験してみた結果、以下の二種類が有効そうである事が分かりました。
  1. WindowのCompositeをオンにする。
    　この方法はシンプルです。コントロールには何もしなくても、正常表示となります。
    　ただし、当然、Compositeがオンでも問題ないケースでしか使えません。例えば、以下のような副作用が発生します。
    　(1) 書類オープン時にウィンドウの位置やサイズを記憶して復元するような処理をしている場合、一瞬オリジナルの位置サイズで表示後に移動する。
    　(2) Window内で再描画が必要となるアクションが発生した場合、（再描画が不十分で？）表示が乱れる場合がある。
    　なお、このプロパティはソース内で変更可能ですが、IDE上でチェックしておかないと機能しない（？）ようです。

  2. me.SelStart=me.SelStartを、コントロールの（例えば）KeyDownイベントに記述する。
    　どうも、これでリフレッシュがかかる（？）みたいで、正常表示となります。
    　やってることは無意味なものですが、それだけに、副作用が出る事もなさそうです。
    　ただし、コントロールの個数が多いと、全てに仕込まなければならない分、面倒です。カスタムクラス化しておいた方がいいでしょう。
追記：ESCキーによる入力キャンセル操作時、1.の方法は消去が行われません。2.は問題ないようです。(2011/09/30)
追記2：2.において、 deleteキーで一文字ずつ消していくと、最後の一文字が残ってしまいます。KeyDownイベントが発生しないことが原因のようで、KeyUpイベントに記述すれば解消されます。ただし、KeyUpでは画面のちらつきが発生するため、単純に移行できないのが悩ましいところ。(2011/11/12)
＜さらに追記＞
　本件は、公式に対応策が示されました。Real Software Japan（小ネタ集）(2012/02/03)

　戻る　　先頭へ

　2011r3と2008r2の互換性について

　2011r3では、2008r2にあったコントロールが、一部置き換わっています。（例えば、StsticTextはLabelに、EditFieldはTextAreaとTextFieldに。）
　これらは、Real Studioが半自動的に置き換えてくれるのでいいのですが、…
カスタムクラスは自動置き換えをしてくれない
　例えば、EditFieldを元に自分で派生クラスEditFieldCustomを作り、それをEditFieldC1という名前で使っていると、これは置き換えてくれません。しかも、EditFieldC1のSuperを見るとEditFieldのままで、TextAreaを選択する事ができません。（選択できる位なら、自動置き換えをしてくれるってことなんでしょうが…）
　仕方がないので、EditFieldC1を削除して、新たにEditFieldCustomと同等の機能を持つTextAreaCustomを作成し、TextAreaを配置後、SuperをTextAreaCustomにする、という事を行っていますが、もっと効率よく出来ないんでしょうかね？
追記：クラス名（Super）は、ドロップダウンメニューから選択するだけでなく、文字列を直接入力できる事を見逃していました。コピペでいけましたが、本当にこれでいいか…(2011/09/30)
　戻る　　先頭へ

　2008r2でのLion対策(2)

　Lion対策について追加です。

　その後も、メニューについては数種類の方法（グローバル定数による置き換え、等）を試してみたのですが、いずれもうまくいきませんでした。
　が、ふと、文字列をShift-JISにしたらどうだろうかと思い、試してみたところ、起動時のエラーは出なくなりました。
（例えば、以下をAppのopenイベントに追加。）
EditMenu.Text=ConvertEncoding("編集",Encodings.ShiftJIS)
　試した範囲では、表示もうまくいっているし、機能もしていますが、これで問題ないのかどうかはよくわかりません。暫く使って様子を見た方がいいとは思います。
（しつこいですが、今となっては2011r3を使った方が素直です。ただ、2011r3は10.4以降、2008r2は10.2以降に対応なので、需要がない訳ではないのが悩ましい処。）
　戻る　　先頭へ

　2008r2でのLion対策

　Lionでは、REALbasic製ソフトウェアがほぼ壊滅、という衝撃的事態（笑）を迎えた訳ですが…。
　当初より、2008r2(E)で新規プロジェクトを作り、そのまま実行すると正常に動作する事から、日本語関連の障害であろう事は想像がついていました。
　それであれこれ実験した結果、どうも、メニューやコントロールのキャプションに使う、特定の文字、または文字の並びがエラーを引き起こすらしいという感触を得ました。
例えば、メニューでは「ファイル」はOKで「編集」はNG、ボタンのキャプションでは「キャンセル」はOKで「保存」はNG、等。
　とはいえ、エラーを引き起こす文字（文字列）を全てリストアップする事は現実的でないので、以下の方法が妥当かな、という感じです。
（まぁ、今となっては、こんなことするより、素直に2011r3を使えばいいんですが…。）
  1. REALbasicは、英語版を使う。
  2. メニューは英語表記。
  3. コントロールのキャプションは、デフォルトのまま。（英語版だと、Untitledになる。）
  4. コードの中で、キャプションを日本語に再指定する。（例えば、ウィンドウのOpenイベントに、StaticText1.Text="概要"、PushButton1.Caption="保存"。）
  5. ただし、メニューはコードの中で再指定してもダメっぽいので、日本語表記は諦める。（上掲(2)を参照。(2011/09/13)）
　戻る　　先頭へ

　標準のヘルプビューアを利用する

　本稿は、再構成してこちらに移動しました。(2013/03/12)

　戻る　　先頭へ

　Dockを除いたデスクトップ領域を取得する

　なんか、今更ですが「アップル ヒューマンインタフェースガイドライン」によると、ウインドウがDockと重なってはいけない、とのこと。（日本語訳は、例えばこちら）
　そこで、ガイドラインで推奨されているGetAvailableWindowPositioningBounds()について調べてみました。
extern OSStatus 
　GetAvailableWindowPositioningBounds(
  GDHandle   inDevice,
  Rect *     outAvailableRect)
　inDeviceにNULLを指定すると、メインスクリーンが対象となるようです。
　ちなみに、RECT型は、
struct Rect {
      short top;
      short left;
      short bottom;
      short right;
};
typedef struct Rect Rect;
なので、MemoryBlockを使って、
Method Name: GetAvailableBounds（注：名前は任意）
Parameters: byRef dl As Integer, byRef dt As Integer, byRef dr As Integer, byRef db As Integer

Declare Function GetAvailableWindowPositioningBounds Lib "Carbon" (dev As Ptr, bounds As Ptr) As Integer

Dim err As Integer
Dim bounds As MemoryBlock
bounds = NewMemoryBlock(8)

// メニューバーとDockを除いたデスクトップ領域を取得（必要なら、戻り値を評価）
err=GetAvailableWindowPositioningBounds(nil, bounds)
  
// 仕分け
dt=bounds.Short(0)  // top
dl=bounds.Short(2)  // left
db=bounds.Short(4)  // bottom
dr=bounds.Short(6)  // right
としてやれば、メニューバーとDockを除いたデスクトップ領域を取得できます。

　また、上記値と、Screen(0).Width, Screen(0).Heightを併用すれば、Dockの位置も分かります。（メインスクリーンの場合）
　ただし、「Dockを自動的に隠す／表示」をオンにしている時は、Dock高（幅）が4pixelと返ってきます。（しまっていても、出していても同じ。）
　この場合はどう評価すべきなのかは、まだ調査中です。

　戻る　　先頭へ

　テキストエンコーディングにNilを指定する

　だいぶ以前（OS9の頃）に作成した、絶対パスからエイリアスパスへの変換処理（Declareによる実装）が、パス名に日本語を含む場合、うまく動かなくなっていました。
　考えられるのは、例によってテキストエンコーディングの不整合ですが、この辺はそれなりに処理してある筈なので、おかしいなと思って、とりあえず考えられることを追試してみましたが、改善しません。
　そこで、デバッガを使って、うまくいっているデータ（以前に作成してあったもの）のエンコーディングを調べてみたところ、Nilになっていました。
　なので、
s=GetTextConverter(Encodings.UTF8,Encodings.MacJapanese).Convert(s)  // UTF-8 -> Shift-JIS変換
s=DefineEncoding(s,Nil)  // テキストエンコーディングにNilを指定（今回追加したもの）
s=AliasPath(s)  // エイリアス形式に変換（自作の関数）
のように、明示的にNilを指定してみたところ、うまくいくようになりました。
　Nilを指定するというのは、盲点でした。

　戻る　　先頭へ

　ListBoxのカラム幅変化時の追随不良について

　ListBoxでは、縦スクロールバーがありの場合は、スクロールバーが表示されているかいないかによって、その有効幅が変化する訳ですが、「マルチカラムで、カラム幅を%と*で指定している」状態では、縦スクロールバーの有無によって、カラム幅も変化します。
　通常は、カラム幅が変化すると、リスト部分のカラム先頭位置も直ちに追随して変化するのですが、追随しないケースがありました。

　調べてみると、ウィンドウのCompositeがtrueの時でした。
　この場合、リスト内に何らかのアクションが発生すれば、（再描画がかかって？）追随するようになるので、例えば、ListIndexを一旦別の行（-1も可）に移して元に戻すような処理を追加してやれば、とりあえず回避できるようになります。

　戻る　　先頭へ

　一時保存ファイルとQTGraphicsExporterについて
一時保存ファイルが残ってしまうケース
　一時保存ファイル（TempSaveFile******）が残ってしまうケースとしては、例えば、異常終了した場合が考えられますが、それ以外に「ダーティフラグが立っていない（ウィンドウ左上の赤丸の真ん中にポッチが表示されていない）状態で、保存を行った場合」もあるようです。
　通常、どこかを変更すればフラグが立つのですが、一部の操作では「変更があったことは検知している（ので保存が可能になる）ものの、フラグが立っていない」という状態になり、そのような時に保存すると、一時保存ファイルに書き出されるという感じです。

QTGraphicsExporterで文字化け
　QTGraphicsExporterクラスのSavePictureメソッドで画像を保存する場合、ファイル名が日本語だと文字化けします。
　FolderItemを取得した時点では文字化けを起こさないため、SavePictureの内部（FolderItemを引数で渡す）で発生しているようです。（例によって、UTF8文字列をShiftJISとして解釈している？）
　戻る　　先頭へ

　プラグインとListBoxについて
プラグインがなくても実行？
　ちょっとハマったので、記しておきます。
　プラグインを使用している際、例えば以下のような場合、プラグインがなくても実行されてしまいます。
  1. Pluginsフォルダにプラグインを置く
  2. プロジェクトを作成し、プラグインをcallするコードを記述
  3. 実行し、終了する。（正常動作することを確認）
  4. プロジェクトを閉じる
  5. プラグインを抜く
  6. プロジェクトを再度起動し、実行。本来ならエラーになる筈が、実行されてしまう
　動作はしても不完全な状態な訳ですから、結果、異常終了を引き起こすことがあり、そうなるとどこが悪いのか見当もつかない、なんてことになります。
　調べたところ、どうも、以前正常動作したコードは、変更がないとエラーチェックを行わないような感じです。
　プラグインをcallするメソッド等を編集（変更）すると、ビルド時に「メソッドまたはプロパティが存在しない」旨、メッセージが出力されるようになります。
　プラグインをとっかえひっかえしながらテストする場合は、Searchを駆使して常にcallの状況を把握しておく必要がありそうです。

ListBoxの背景色が不完全？（解決済）
　ListBoxのCellBackgroundPaintで背景色を指定できるのですが、階層型では、フォルダを示す三角マーク部分には適用されず、白抜きになってしまいます。
　行選択（ハイライト）は問題ないだけに、惜しいです。
追記：本件は、WindowのプロパティのCompositeをチェックすることで解決することが確認できました。（Compositeプロパティについては了解していたつもりですが、理解が浅かったです。）(2010/03/09)
　戻る　　先頭へ

　セッター（Setter）メソッドについて

　これは2008固有ではなく、もっと前からある（少なくとも5.5にはある）話なのですが、気がついたのが比較的最近なのもあって、ここに記しておきます。

　セッターメソッドは、代入演算子を使って値を渡すことができるメソッドです。
　メソッドでありながら、以下のような記述ができます。
　myMethod=10
　そのためには、メソッド側の引数の記述時に、Assignsキーワードを付加する必要があります。
（例：Assigns value As Integer、詳細はUser's Guide（Assignsで検索）参照。）
　なお、Assignsキーワードを使用できるのは引数のうちの最後の一つだけです。
　で、これにどんなメリットがあるのかというと、「メソッドをプロパティのように扱える」だと思います。

　例えば、既存のリストボックスを拡張するため、キャンバスをベースにしたカスタムリストボックスに置き換えたい場合、リストボックスとキャンバスではプロパティに違いがあるため、（互換性を維持しようと思うと）自分で追加してやる必要があります。
　ところが、プロパティの中には、値を変更するとアクションが発生するものがあります。（例えば、ListIndexを変更するとハイライト行が移動する。)
　これを単にプロパティで追加してしまうと、アクション部分を記述することができません。

　このようなとき、メソッドをプロパティと同じ書式で扱うことができれば、アクション部分を記述できる訳です。

　なお、このままでは代入だけで参照ができません。
　参照は「同じ名前で、引数なし、戻り値あり」のメソッドを追加することで対応します。
（REALbasicは、引数や戻り値の異なる同名のメソッドがあれば、呼び出し側の書式に一致したものを自動的に割り当ててくれます。）

　また、メソッドに渡した値はそのままでは保持できないので、内部的にプロパティを用意して、代入メソッドでセットし、参照メソッドで戻り値に指定します。

　戻る　　先頭へ

　2008r1と5.5の互換性について(3)

　続きです。
スレッド経由の変数変更をdoループ内で検知できない？
　ちょっとややこしいのですが、例えば以下のようなケースで発生します。
  1. プロジェクトにスレッドクラスとウィンドウ（ダイアログ）を追加
  2. ダイアログにTimer（Mode=1,Period=1000）を置き、Actionに「App.flg=true」を追加
  3. スレッドのRunイベントに「Window2.ShowModal」を追加
  4. Appのプロパティにflg As Booleanを追加し、openイベントに以下を記述 
    Dim th As Class1  // Class1はスレッド
th = new Class1
th.Run
do
  if flg then
    exit
  end if
loop
Window2.Close
　これを実行すると、5.5ではループから抜けますが、2008r1では無限ループします。
　どうも、2008r1ではdoループ内でflgが変化したことを検知できないようです。

　まぁ、こんなトリッキーなことをするのが悪い、と言われればそれまでですが、いずれにせよ互換性が失われていることは確かなので、了解しておく必要はあります。
　戻る　　先頭へ

　10.5.2と2008r1の相性？

　以前、10.5.2と5.5の相性？で書いた件ですが、当初思っていた以上に深刻です。
　というのもこれが、
  1. 5.5に限らず、2008r1でも発生する
  2. Tipsウィンドウに限らず、フローティングウィンドウ全般で発生する
  3. （これが最大の問題点ですが）ビルドされたアプリケーションでも発生する
　すぐにOS側で対処されるかも、という淡い期待も持ったのですが、その気配もないことから、（遅きに失した感もありますが）順次、シートウィンドウをダイアログに置き換えるべく、作業を行っています。
（既に本家フォーラムでも話題になっていましたね。）
10.5.2 Sheet windows not accepting mouse clicks
＜追記＞
　本件は、Mac OS X 10.5.3で解決されました。(2008/05/31)

　戻る　　先頭へ

　2008r1と5.5の互換性について(2)

　続きです。
MemoryBlockはエンディアンに注意
　エンディアンとはバイト列の並び方のことで、インテル形式、モトローラ形式という呼び名があるように，両者では方式が異なります。
　で、MacはCPUがPPC（モトローラ形式）からx86（インテル形式）に移行してしまった訳です。
（エンディアンについては例えば、sonson@Picture&Software - [Tips] ビッグエンディアンとリトルエンディアンを参照。）

　Rbに関しては、少なくとも5.5の時点ではエンディアンを指定するパラメータがありましたが、5.5（自身とビルドされたアプリ）はIntel Mac上ではRosetta（エンディアン統一処理を含む）経由で動作するため、特に意識する必要はありませんでした。
　それが2008では、プラットフォームに素直に依存するようになったため、意識的に取り扱う必要がでてきました。

　注意すべきデータはいくつかありますが、その一つがMemoryBlockです。
　MemoryBlockの場合、互換性を維持するためには、従来の形式、即ちビッグエンディアンに統一するのが手っ取り早いでしょう。
　ということで、.LittleEndian=falseとするのが良さそうです。
　戻る　　先頭へ

　2008r1と5.5の互換性について

　2008r1がリリースされたので、ほんの少しですが、使ってみました。
　まずは、既存の5.5プロジェクトをそのままビルドして様子を見ようとしましたが…
コントロールのsuperが保持されない
　例えばCanvas等、自分でカスタムクラスを作ってsuperで指定している場合、オリジナルのクラスに戻ってしまいます。
　いちいち指定し直すのが面倒くさい…
（2007r5で保存後、2008r1で開けば問題なし。とりあえず、これで凌ぐか…）
　戻る　　先頭へ

　2007r5と5.5の互換性について(2)

　互換性について追加です。
ListBox
　セルが文字入力可能状態の時、編集メニューのペーストを実行すると、セル（ActiveCell。実質的にはエディットフィールド）がペーストを喰ってしまって、メニューハンドラ（EditPaste）まで届きません。（5.5では上位に継承されます。）
後から読み返してみると、分かりにくい文章ですね。
ペースト対象が「ActiveCellの1セルのみ」の場合は特に問題ありませんが、（Activeになっているセルを含む）複数セルの場合は自前でペースト処理を書き、それが実行されるようにしておかなければなりません。従来は、メニューハンドラのEditPasteに記述しておけば（システム側のペースト処理終了後）実行されていたのですが、2007r5ではActiveCellが処理を終えると、そのまま（メニューハンドラに書いた自作部分が実行されることなく）終了してしまう、ということです。
　メニュー名（とハンドラ名）をEditPasteではなくEditPaste2等とすることで、とりあえず届くようにはなりますが、その場合、ペーストに関する処理は全て自前で書く必要があります。
ダイアログ等で通常のペーストを使いたい場合は、あらかじめEditPasteとEditPaste2をメニュー中に作成しておいて、ウィンドウのActivate,Deactivate辺りに切り替え（.Visible=true|false）の処理を加える等します。
　戻る　　先頭へ

　2007r5と5.5の互換性について

　REALbasicは、ここ暫くver.5.5を使ってきました。
　5.5でビルドできるのはOS9版とPPC用のOSX版（注）です。
注：OSX版は、過去の資産の継承という観点からMach-O形式ではなく、PEF形式（いわゆるCarbon）としてきました。
　PPC用のOSX版は、Intel Mac上ではRosettaを介しての動作となりますが、Tigerではそこそこのレスポンスが得られていた（ように思える）ので、まあこれでもいいかと考えていました。
　それがLeopardでは、かなりのパフォーマンス低下が見られるようになってしまいました。
　そこで、丁度Leopard対応の2007r5がリリースされたこともあり、ユニバーサルバイナリ（UB）化を考えてみることにしました。
2007r5はMach-O形式しかビルドできないため、現在リリース中のOS9版やOSX(PEF)版も継続したい場合は、5.5と併用するしかなさそうです。
　調べたところ、いくつかの互換性のなさや工夫が必要な点が確認できました。
　とりあえず、気付いたところから列挙してみます。
ListBox
　5.5では行と列が存在する部分のみ処理されるものが、2007r5では行が存在しなくても処理対象になっています。例えば、
・CellBackgroundPaintの描画
・枠線（例：GridLinesHorizontal=ThinDotted）を指定した場合の描画
　なお、枠線を行と列が存在する部分のみ描画したい場合は、CellBorderBottom(row,column)=ListBox.BorderThinDottedのように、動的に指示するしかないようです。

bitアクセス
　Integer型をbit単位でアクセスする場合、2007r5ではUInt32にしないとうまくいかないようです。

Transparent=1はダメ？
　例えば、文字を描画するPictureにTransparent=1を指定すると、透明になり過ぎて（？）文字が読めなくなります。（5.5では問題なし）
　ただし、これが発生する箇所はちょっと特殊なことをしているので、別の要因が絡んでいるのかもしれませんが…。

アイコン
　アプリケーションのアイコンを設定しているにも関わらず、標準アイコンになってしまう、という現象が起こりました。どうも、パッケージ内のアイコンファイル名が日本語だとダメなようです。（ビルドするアプリの名前を日本語にすると、アイコンファイル名も日本語になる。）
　ビルド後、ファイル名を英字に変更し、info.plistのCFBundleIconFileの文字列を書き換えたところ、アイコンが表示されるようになりました。

プラグイン
　現在使わせて頂いているプラグインがMach-Oに対応していないため、別の方法を考える必要があります。
　フォントIDからフォント名を得る処理では、Declareが公開されているのでそれを使わせて頂こうとしたところ、Osaka等は問題ないのですが、ヒラギノ系はうまく変換できませんでした。
　これはフォントIDにShort型ではなくInteger型を使っていたためでした。
（2007r5はShort型を持っていますが、5.5にはないため、互換性を持たせるためにはMemoryBlockを使って渡す必要があります。）

5.5との共通化
　当面は、OS9版、OSX(PEF)版、OSX(UB)版の３本立てで行こうかと考えているのですが、そのためには、ソースコードを三者で共有できる状態にしておく必要があります。（そうしないと、メンテ仕切れなくなる。）
　共通化するには、Target文を使ってそれぞれのOS環境に固有の処理を書き分けることになるのですが、ターゲットの種類にOSX(PEF)を特定するものがありません。
　そのため、現状では以下のようにしています。（WinやLinuxは作らないことが前提。）
#if TargetPPC  // OS9
　…
#elseif TargetMachO  // OSX(UB)
　…
#else  // OSX(PEF)
　…
#endif
CarbonLibとCarbon
　Mach-Oでは、Declare文で指定する際、従来の"CarbonLib"を"Carbon"に変更する必要があります。（使い分けは上述のTarget文で行います。）
　戻る　　先頭へ

　10.5.2と5.5の相性？

　まだまだ現役のver.5.5ですが、OSを10.5.2にしてから（だと思う）、しばらく使っていると、シートウィンドウ（IDEのメソッドやプロパティの編集ダイアログ等）でマウスクリックが効かなくなる（escやreturn等のキー入力は受け付ける）、ということが度々起こるようになりました。

　結局、Tipsウィンドウが表示されているとダメということが分かりました。
　Tipsウィンドウを閉じてあげれば復活します。
（これに気づくまで、何度もプロジェクトを閉じては開くを繰り返していました。）

＜追記＞
　本件は、Mac OS X 10.5.3で解決されました。(2008/05/31)

　戻る　　先頭へ

　OS X エディットフィールドにおけるスタイルの問題(2)

　REALbasic 5.2.1の日本語版が公開されました。
　早速、下記に示したスタイル問題が改善されているのか、ダウンロードして確かめてみることにしました。

　確認の方法は以下のとおりです。
  1. Window1にEditfieldを１つ置く
  2. MultiLineとStyledプロパティにチェックを付ける
  3. 起動
  4. 他のアプリからスタイル付きテキスト（日本語または日英混在の文字列）をコピー
  5. Editfieldにペースト
　結論からいうと、スタイルがずれました（泣）。

　そこで、ずれ方について、4.0,4.5と同じ原因なのかを調べてみました。
　なお、REALbasicは5.2.1JのDemoモード、OSはMac OS X 10.1.5です。

　まずは前提事項ですが、Mac OS X 10.1.5の日本語環境では、クリップボードからコピーしたスタイル付きテキスト（のエンコーディング方式）には２種類あります。（他にもあるかもしれませんが未確認。）
　１つはUTF-16で、もう１つはX-MAC-JAPANESE。
　前者はTexyEdit、後者はAppleWorks6からコピーしたもので、おそらくはCocoaアプリとCarbonアプリの違いによるものと思われます。

　さて、調査の方法は以下のとおりです。
  1. 新規クラスを作成し、Editfieldのサブクラスとする
  2. メニューハンドラにEditCopyとEditPasteを追加する
  3. ClipBoardとやり取りするためのコードを書く
  4. スタイルテキストのセットはme.SetTextAndStyle text,style、取得はme.TextStyleDataとする
　あれこれ試してみた結果、ペーストについては以下のとおりとなりました。
  1. X-MAC-JAPANESEの場合、クリップボードから取得したテキストとスタイルを、そのままme.SetTextAndStyle text,styleとしてやれば正常に表示。
  2. UTF-16の場合、テキストエンコーディングをX-MAC-JAPANESEに変換してからme.SetTextAndStyle text,styleとしてやれば正常に表示。
　また、コピーについては以下のとおりとなりました。
  1. me.TextStyleDataをそのままクリップボードにセットし、AppleWorks6にペーストすると、正常に表示。
  2. 同じ文字列をTextEditにペーストすると、文字列はペーストされるがスタイル情報は失われる。（この件は継続調査中）
　ということで、4.0,4.5のケースとは違っていました。
　特にX-MAC-JAPANESEベースでやり取りする環境では、データは何の細工もしていないにも拘わらず正常に処理することから、SetTextAndStyleメソッドやTextStyleDataプロパティは問題ないが、EditFieldが直接処理すると誤動作する、ということのようです。

　ただし、上記を確認したのがMac OS X 10.1であり、10.2ではどうなるのか分かりません。
（もし、10.2での情報をお持ちの方がいらっしゃいましたら、教えていただければ幸いです。）

　とは言え、10.1でダメな以上、使えないという結論を出さざるを得ない訳で、そろそろ何とかして頂きたいと思います。（この調子では、5.5も期待薄か…）

＜追補＞
アスキーソリューションズ社に問い合わせたところ、REALSoftwareの見解は「これはMac OS X 10.1のバグであり、10.2では直っている。10.2上では問題ない」というものでした。そう言われても、3.5.2では正しく処理できる訳ですから、今一つ釈然としません。ということで、「3.5.2相当のEditFieldを何らかの形で提供してほしい」と要望を出しておきました。

　戻る　　先頭へ

　OS X エディットフィールドにおけるスタイルの問題

　Rb4.0の場合、Mac OS X 10.1（およびMac OS 8.6以降のCarbon環境）において、MultiLine=true, Styled=true としたEditFieldに、スタイル付きのテキストを、
  1. 他のアプリ上でコピーし、EditFieldにペーストする
  2. EditField上でコピーし、他のアプリにペーストする
と、スタイル情報が崩れるという問題が発生しています。

　これはRb4.0では、EditField上の文字列を「文字」単位で扱う一方、スタイル情報は（もともとバイトベースの情報であるため）「バイト」単位で適用することからずれが生じる、ということのようです。
（日本語は基本的に２バイトで１文字を表します。）

　この件は、Rb3.5.2では発生しません。
　なぜRb4.0からこのような仕様になったのかは不明（注）ですが、あきらかに不具合であり、これが放置されたままになっているのは理解に苦しみます。（詳細に調査した訳ではないのですが、Rb4.5でも改善されていないようです。（注２））

　今後開発するソフトにRb4.xは必須ですし、とはいっても、このまま改善を待つのも期待薄なので、しかたがないので、自前でスタイル処理を行うEditFieldのサブクラスを試作してみましたが、やはり実用には難があります。
　あとはRb5.0に期待するしかないのですが、どうなることやら…。

注）アスキー社に問い合わせたところ、REALSoftwareの見解は「Mac OS Xでのテキストのドラッグ＆ドロップに関する詳細な情報がApple社から提供されておらず、対応ができない」ということのようです。（ただしREALbasic 4.5.2のリリースノートを見る限り、この見解はMac OS X 10.2に対するもののような気がします。）

注２）その後、Mac OS X 10.2で検証したところ、Rb4.5.2と10.2の組み合わせでは問題ないことを確認しました。

　戻る　　先頭へ

　OS X エディットフィールドにおけるフォント名の問題

　Rb4.0の場合、Mac OS X 10.1（およびMac OS 8.6以降のCarbon環境）において、MultiLine=true, Styled=true としたEditFieldに、スタイル付きテキスト（フォント名情報を含む）をペーストした後に再度フォント名を取得すると、フォント名が変わってしまうという問題が発生しています。（本件はSelTextFontで発生します。TextFontでは発生しません。）
　例えば、
  1. 平成明朝 ⇒ 平成明朝体
  2. 平成ゴシック ⇒ 平成ゴシック体
  3. Osaka−等幅 ⇒ Osaka
  4. Bodoni SvtyTwo ITC TT-Bold ⇒ Bodoni SvtyTwo ITC TT
　少し調べた結果、平成明朝体、平成ゴシック体というのは、Cocoaアプリから（のみ）アクセスできる「フォントパネル」上の名前だということが分かりました。
　また、ヒラギノ系は全て、最後のW3,W8等が欠落するのですが、フォントパネルではそれらは（フォント名本体とは別の）書体に分類されており、このあたりからもフォントパネルが絡んでいることを伺わせます。
（…とはいえ、なぜにCarbonベースである筈のRb4.0のEditFieldが、フォントパネル上の名前を返してくるのかは謎ですが…。）

　で、問題はそれだけではありません。
　Rb4.0で作成したテストアプリ（Carbon）内で、例えばフォント名を強制的に平成明朝（正確には対応するフォントID）に書き換えて、Cocoaアプリにペーストしても、平成明朝にはなりません。一方、Carbonアプリにペーストすれば平成明朝になります。
　ということで、どうもCocoaアプリとCarbonアプリとではフォントの扱いが異なるようです。
（念のため、AppleWorks6(Carbon)からTextEdit(Cocoa)にもコピーしてみましたが、やはりフォント名情報だけ伝わりません。このことから、こちらの問題点はRb固有ということではなさそうです。）

　さて、困った…。

＜追補＞
　REALbasic NUG メーリングリスト（英語）にも「SelTextFontでフォントのフルネームが取得できないけど、どうすればいいの？」という質問が流れていました。それに対する回答は「スタイルデータからフォントIDを読み出してフォント名に変換すればいいよ」というものでした。従って、この問題は日本語版に固有という訳ではなさそうです。
　ただし、スタイルデータからの抽出は、日本では上述のずれの問題があり、そう簡単にはいかないところが厄介です。

　戻る　　先頭へ

　OS X エディットフィールド入力時の横縞回避策（案）

　Rb3.5の場合、Mac OS Xではエディットフィールド入力時に、文字列の背景に横縞（aquaの背景と同じもの）が入るという問題があります。（入力中のみで、確定すると消える。）
　この現象が発生する状況を調べたところ、
  1. エディットフィールドがマルチライン（MultiLine=true）
  2. ウィンドウのバックカラーが未設定（HasBackColor=false）
の場合に起きるようです。少なくとも上記のいずれかが該当しなければ、この問題は発生しません。
　従って、対策としては、
  1. まず、マルチラインでなくてもいい場合は、設定をオフにする。
  2. 例えば一般的なエディタのように、全面がエディットフィールドのウィンドウの場合は、バックカラーを設定してしまう（結果的には、この色はどこにも現れない）。
　さて、問題なのは「ウィンドウの一部にマルチライン対応のエディットフィールドを置き、aquaの背景を活かしたい」場合です。
　ここで、プラカードがaquaの背景（と同じ仕様？）を持っていることに注目します。
　つまり、プラカードをウィンドウ全面を覆うように配置すると、擬似的にaquaの背景を再現できます。
　この状態でウィンドウのバックカラーを設定すると、入力時に横縞が表示されることはなくなります。

　なお、ウィンドウ内にチェックボックス等を配置すると、それぞれの横縞が微妙にずれることがあります。その場合は、プラカードの位置を微調整する必要があります。（作者の環境ではtop=-4で一致しました。ちなみにtop=-2で、本来の背景と一致するようです。）
　また、べベルボタン等は問題ないようですが、ポップアップメニュー等は周囲が微妙に浮くようです。あくまで、擬似的な回避策と考えた方がよいでしょう。

（注：上記回避策は作者の環境では有効ですが、環境（なんらかのカスタマイズソフトをお使いの場合等）によっては意図したとおりに表示されない可能性もあります。もし、うまくいかない場合があるようでしたら、状況を教えていただけると幸いです。）

　戻る　　先頭へ

　Str関数の精度【各版共通】

　REALbasicにおいて、整数を文字列に変換する場合はStr関数を用いるのが一般的です。ですが、数字が大きくなると、誤差が発生するようになります。
　このことは言語リファレンスにも、以下のように記述されています。（以下は3.5.2Jのオンラインリファレンスからの引用です。）

Strは、7桁の有効桁数を返します。6桁以上の数字を返す必要がある場合は、科学的記述法を使用します。Str(123456789)は1.234568e+8を返します。

（注：わざわざボールドで書いてあるところを見ると、問合せが多かったのかもしれません。なお、ボールドの境目が変な気もしますが、原文のままにしてあります。）

　例えば、16777215(&hFFFFFF)をStr関数に通すと結果は1.677722+e7となり、これを再び整数に戻すと16777220(&h1000004)となって、誤差が発生します。

　この問題を解決するためにはFormat関数を使います。
　上述の例の場合、Format(16777215,"########")とすれば、整数に戻しても、元どおり16777215(&hFFFFFF)となります。

　戻る　　先頭へ

　デバッグ時の動作不安定について(2)

　前項で「プラグインが原因でデバッグ時の動作が不安定になった」と書きましたが、必ずしもそうではなかったようです。
　というのも、暫くは順調だったのですが、また不安定になってきたのです。ただし今回のはRb自身の問題ではなく、Rb終了後に他がおかしくなるのです。状況は、
  1. ファインダがコケる。（メニューを選ぼうとするとエラーのダイアログが表示される、を繰り返す。）
  2. 特定のアプリがシステムエラーを起こす。（エラーの発生箇所は少しずつ違うが、発生率は100％！）
というものです。
　またもや自分のコードのせいかとも思ったのですが、ふと試しに余分な機能拡張類を全て外してみようか、という気になりました。

　なぜそう思ったかというと、暫く前にとあるソフトをインストールしたのですが、その際色々あって、インストール・アンインストールを繰り返すはめに陥ってしまい、なんとなくシステムが不安定になっているかも、という予感はあったのです。

　とはいっても、Rbを動かしさえしなければ何の問題もなく、半信半疑だったのですが、ものは試しということで「MacOS基本」＋αでセットを作成し、それでRbを動かしてみると上記のエラーは全く発生しなくなりました。
　そこで、外していたプラグインも入れてみたところ、こちらも問題なく動きました。（プラグインと機能拡張のコンフリクトというのは考えにくいのですが、何か内部処理的な問題が発生するのかもしれません。）

　という訳で、機能拡張のコンフリクトか設定ファイル類が壊れているのかもしれません。
「怪しい時は素に戻せ」というのは昔からいわれていることですが、結局再確認することになってしまいました。

　戻る　　先頭へ

　デバッグ時の動作不安定について

　REALbasic 2Jから3Jに移行したことによって、急に不安定になったプログラムがありました。現象は、
  1. IDE上で「実行」すると、5回に1回位の割り合いで、システムエラー、アプリケーションエラー、フリーズのいずれかが発生する。
  2. エラーが発生するのはIDEの内部的な初期化作業時（と思われる）で、アプリケーション本体が動きだしてしまえばエラーは起きない。
  3. ビルドしたアプリケーションではエラーは起きない。
というものです。
　このプログラム自体、かなりサイズが大きいため、どこかにコーディングミスがあってもおかしくはないのですが、それをしらみつぶしにチェックすることは至難の技で、どうしたものかと苦慮していました。

　それがある日、問題を起こしていたプログラムから再利用のために、あるモジュールをコピーしたとたん、それまで問題のなかったプログラムが、同じ現象に見舞われるようになってしまいました。
　このことから、このモジュール内にエラーの原因があることは明らかで、一つづつ順番にチェックしていったところ、あるプラグインを呼び出しているメソッドを削除すると、エラーが発生しなくなることが確認できました。

　確かにそのプラグインは2.x用で、3.xでの動作は保証されていませんが、このプラグインを利用している別のプログラムは特に問題なく動いていることから、他のファクターとの複合的な要因で、エラーが発生しているのかもしれません。

　ともあれ、バージョンアップ等によって、それまで問題のなかったプログラムの動作が急に不安定になった場合には、とりあえずプラグインは全て外してみるというのは、やってみる価値があると実感しました。

　戻る　　先頭へ

　画像描画速度の低下について

　REALbasic 3.2 Jでは、一部の環境において、画像の描画速度が低下する現象を確認しています。
（例えば覧画帖で、画面をはみだす画像をマウスで掴んでスクロールさせるような場合、時計カーソルが出っ放しになってなかなか動いてくれない、といった状態になります。）

　今のところ、どのような環境で発生するのかは特定できていませんが、最近の機種では起こらず、比較的旧い機種（OSも旧い）で起こるようです。
　3.2 Jのリリースノートによると、

（引用開始）
3.2b1
=====
[Opt] (Mac) Graphics.DrawPicture：速度とメモリ効率が改善された。NewPictureメソッドで作られたピクチャを描画する際に不必要なキャッシングを回避した。
（引用終了）

とありますので、この辺がなにか関係しているのかもしれません。
　一方、3.1 Jではこの現象は発生しませんので、覧画帖は3.1 Jでビルドするようにしています。

＜追補＞
　REALbasic 3.5.2 Jでも、（3.2 J程ではないですが）速度低下が起こります。3.2 Jの段階でアスキー社には連絡済なのですが、他では再現しないのでしょうか？

　戻る　　先頭へ

　Windowsアプリケーションでの問題点

　REALbasicはWindowsアプリケーションをビルドすることができるため、マルチプラットフォーム環境では威力を発揮します。が、Macでは問題ないのにWinではうまく動かない場合があります。以下は作者が経験した事例です。いずれもアスキー社には報告済みで、再現が確認された項目とそうでない項目がありますが、とりあえず両方挙げてあります。（後者は行き詰った時等のヒント情報程度にお考え下さい。）
Windowsアプリケーションをビルドすると、タブパネルがおかしくなる。（確認済）
　これは、ビルドされたアプリケーションではなく、Mac上のIDEでの話です。タブパネルがタブ１枚になり、タブ情報の編集等ができなくなります。REALbasicを再起動すれば解消されます。

ListBoxのcellをCheckBox付きにすると、c0000005のエラーが発生する。（確認済）
　下記のように、ColumnCountを２にして、２セル目をCheckBox付きにするとエラーが発生します。
　ListBox1.ColumnType(1)=2
　ListBox1.addrow "abc"
　なお、１セル目には問題なくCheckBoxが付きます。

ピクチャーが透明にならない。（確認済）
　ピクチャーオブジェクトのTransparentに１を指定して白を透明にし、CanvasにDrawPictureしても透明にならない。

CanvasにDrawStringする際、改行コードが正しく処理されない。（確認済）
例えば、canvas1のpaintイベントに、
me.Graphics.DrawString "abc"+Chr(13)+Chr(10)+"def",10,10
と記述しても、制御文字ごと一行に表示されます。

EditFieldとPushButtonの相性。（確認済）
　EditField(Multiline)とPushButton(Default=true)があると、EditFieldで文章入力中に改行を押すと、ボタンが押されたことになってしまいます。PushButtonのDefault=falseにしてやれば回避できます。

Window(Dialog)のtop,leftを指定しても、指定した位置に表示されない。（再現せず）
　これは、アプリの中でウィンドウを生成し、その属性として指定した場合の話です。
　ただし、一度Hideして再びShowすると、指定した位置に表示されるようになりました。

TimerのModeをプログラム内で書き換えてからウィンドウを表示させると、ウィンドウを閉じられなくなる。（再現せず）
　ただし、本当にTimerの問題かどうかは究明しきれていません。

参照（ByRef）で返ってきた値が１であると、c0000005エラーになる。（再現せず）
　返ってきた値が０や２の時は問題ありませんでした。ByRefをやめて戻り値で返す方式にしたらエラーが出なくなりました。ちょっと考えにくいことなので別の原因が絡んでいる可能性もありますが、とりあえず挙げておきます。

Canvasの描画がうまくいかない。（？）
　Canvasへの描画を何度か繰り返していると、Canvas以外の場所（デスクトップに直接の場合もあり）に描画されてしまうことが起こりました。
　例えばCanvas1とCanvas2があって、Canvas1が描画されると同時にCanvas2も描画したい場合、Canvas1のPaintイベントにCanvas2.Graphics.Draw... と記述すると、上記現象が発生するようです。

　戻る　　先頭へ

　REALbasicとATOK13の相性

　REALbasicで作成したソフトウェアに、ATOK13を経由してキーボードから文字入力を行うと不具合が発生することを確認しています。（ただし特定の条件下でのみ発生するものなので、さして問題視されていないようです。）

　既にREALbasic発売元のアスキー、ATOK13開発・発売元のジャストシステム両社には報告済みですが、今のところ有効な対策が示されてはいません。
　また、この件はソフトウェア作成者のレベルでは回避できません。

　従いまして、ここでは不具合の発生する状況と当面の回避策を提示することしかできません。悪しからずご了承下さい。

不具合の内容
(1) ローマ字入力で日本語が正しく入力できない。
(2) パスワード入力時などに用いるブレット文字表示（「・」表示）が正しく処理されず、打った文字がそのまま表示される。（こちらは半角でも発生）

発生条件
(a) 本件は、ローマ字入力時に「環境設定−入力・変換２」の「caps lockキーの設定」が「OFF:半角英数」となっていると発生します。（「通常」では発生しません。）

(b) インライン入力時に発生します。（変換ダイアログ経由では発生しません。）

(c) caps lockキーを押し込んで「ひらがな入力」にし、ローマ字で「かいはつ」と入力すると「ｋあいｈあｔｓう」となってしまいます。

(d) この時、入力中の文字列やメニューバーがちらつきます。ジャストシステムによると「ATOK13にcaps lockキーがon,offを繰り返すようなイベントが来ている為」だそうです。

(e) この状態で、一度returnキーを押して確定します。そうすると、ちらつきが止みます。その後は正常に入力できます。（ただし、caps lockキーを変化させると、再び入力不可となる。）

(f) この不具合は、REALbasicで作成したソフトだけでなく、同時に複数のソフトを起動しているような場合は、他のソフトでの入力にも影響します。

　ブレット文字表示については、「・」が表示されず、打った文字がそのまま表示されます。こちらはcaps lockキーの状態には無関係であり、用途を考えるとこちらの方が深刻かもしれません。

当面の回避策
(1) ATOK13のcaps lockキーの設定を「通常」にする。
(2) REALbasic製ソフトを利用するときは「ことえり」を使う。

　戻る　　先頭へ

[Home]　 [MacSoft]　 [Donation]　 [History]　 [Privacy Policy]　 [Affiliate Policy]