メニューの再定義(2)
思うに、メニューを定義するとして、まったく異なった体系にしようとしない限り、だいたいはどの拡張子クラスでも同じ構成になるはずです。その合間に、拡張子クラスに特化した項目が挟まる形になるのではないかと思います。
それを踏まえると、たとえば現状、ファイルメニューは
- 新規(N)
- 指定して新規(F)
- 開く(O)...
- 最近のファイル(D)
- 上書き保存(S)
- 名前を付けて保存(A)...
- 閉じる(C)
- ページ設定(U)
- 印刷(P)...
- 萌ディタの終了(X)
という構成になっています。メニューを定義する段階で、「ここは拡張子クラスごとに変わるよ」という特別なメニュー項目を置いといて、その実体を別のプロパティなりオブジェクトなりに定義しておけばよいのかなー。つまり、メニュー自体は
- 新規(N)
- 指定して新規(F)
- (ファイル - 新規系の仮想項目)
- 開く(O)...
- 最近のファイル(D)
- (ファイル - 開く系の仮想項目)
- 上書き保存(S)
- 名前を付けて保存(A)...
- (ファイル - 保存系の仮想項目)
- 閉じる(C)
- (ファイル - 閉じる系の仮想項目)
- ページ設定(U)
- 印刷(P)...
- (ファイル - 印刷系の仮想項目)
- 萌ディタの終了(X)
- (ファイル - 終了系の仮想項目)
のような感じで定義しておく。実際にメニューが選択されたとき、仮想項目の実体化を行い(それぞれをプロパティで設定するか、イベントが発生)、その後実際にメニューが
- 新規(N)
- 指定して新規(F)
- 新規マクロ
- 開く(O)...
- 最近のファイル(D)
- お気に入りから開く...
- 上書き保存(S)
- 名前を付けて保存(A)...
- すべて保存
- 閉じる(C)
- すべて閉じる
- 右のタブをすべて閉じる
- 左のタブをすべて閉じる
- ページ設定(U)
- 印刷(P)...
- 萌ディタの終了(X)
なんていう風に表示される。こうすると、既存の環境へ割り込ませることもたやすいと思います。
どこかの拡張子クラスで定義されている仮想項目にさらに追加する場合は、
var f = class_js.prototype;
f.onRequestMenu(arg, classname, methodname) {
switch (arg("kind")) {
case "file":
swich (arg("kind2")) {
case "new":
// まず親クラスで実体化して
result = invoke(arg, this.parent, methodname);
// それに追加する
result += '追加する項目';
break;
}
break;
}
}
のような感じに。ということは、仮想項目の実体化はイベントで、ということになるのかな。なんかいわゆるプログラミング言語の仮想関数と考え方がちょっと似てますね。
by knife37
| 2004-11-11 12:17
| 妄想を申そう
| Top
|