日記

アキバですよ、アキバ。某サイトでローカルに盛り上がっていたメイド喫茶漫画それ町とか、いい加減GigaEthernet環境への移行を始めようと思いまずはバックボーンからということでギガビット対応のL2スイッチとか、その他ごちゃごちゃと買ってきました。

本日の発見。トンカツ屋の和幸で千円以下のメニューが復活していた（いつからだろう）。しかも禁煙だった（いつからだろう）。素敵だよ、和幸。

スイッチだけをギガビットにしても全体の通信速度は全く変わりませんが、とりあえず交換しておきました。次は「蟹」をどうにかしたいですね。五年弱の間、一度も止まらずに働き続けてきた100BASE-TのL2スイッチは引退です。引退とはいってもまだまだ普通に使えるので、大切に保管しておきましょう。

プラグインがいつまで経ってもβ版な件について。

次はポップアップメニューを実装したいなー、と考えてます。Windowsアプリケーションでありがちな、所謂「右クリックメニュー」ってやつです。今まで吉里吉里２にはありそうでなかったんですよね、これ（私が知らないだけかも）。

…こんなことだからいつまで経ってもβなんだよ！

なんか出た。

• 
• 

今のところ、おおよそ以下のようなコードを書くだけで、右クリックでポップアップできるようになってます。

//当然、メニュー作成は別途必要

//フック関数
function showPopup()
{
  var x = kag.lastMouseDownX;
  var y = kag.lastMouseDownY;
  kag.trackPopupMenu(0, x, y, 0, 10);
  return false;
}

kag.rightClickHook.add(showPopup);

が、あまり実用にはならないかもしれません。今わかっている欠点として、次のようなものがあります。

1. 非表示状態のメニューはポップアップできない（当然か）
2. 親メニューはポップアップできない（そういうものか？）
3. 表示させるメニューは親メニューの子孫でなければならない
4. 表示させるメニューの指定方法が、インデックスによる位置指定

始めの二つは諦めるとして、三つめはポップアップメニューの存在意義に関わります。親メニューの子孫に限定されるということは、ポップアップできるメニューは親メニューに登録されている、ということになります。親メニューにあるのであれば、ポップアップメニューにする意味はあるのか、と。

四つめは制作者に負担をかけるものです。インデックス指定ということは、制作者は常にメニューのインデックスを把握していなければなりません。吉里吉里のMenuItemインスタンスは、自身のインデックスを知る方法を持たないため、これは意外と厄介です。

三つめと四つめの妙な制限があるのは、MenuItemインスタンスからメニューハンドルを直接取得できないためです。直接取得できない以上、間接的にやるしかありません。現状では、ウィンドウハンドルからGetMenu()で親メニューハンドルを、親メニューハンドルとインデックスからGetSubMenu()で子メニューハンドルを、…といった感じに孫、曾孫、と辿っています。また、MenuItemからは事実上有益な情報を何も取得できないため、MenuItemコンテキストで実行することに何のメリットもありません。メニューなのにWindowインスタンスのメソッドになっているのは、このためです。

MenuItemインスタンスから、ネイティブインスタンスを無理矢理引きずり出してやろう ^*1 かとも考えましたが、ネイティブインスタンスのクラスIDやら、ネイティブインスタンスのクラス定義やら、VCLヘッダやら、いろいろと面倒なことになりそうだったのでやめました。

要するに、いま一つ使いづらい仕様になったということですが、どうしてもポップアップメニューにしたいというときには使えなくもないです。

• *1: ネイティブインスタンスはVCLのTMenuItemオブジェクトを保持（has a）している。TMenuItem::Handleでハンドルを取得できる。