JPH0749759A - コンピュータ駐在ソフトウエアシステムに対するユーザインタフェースとしての電子的ドキュメント - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 プログラムによってボタンを含むドキュメン
トを生成させる能力のために特別なプログラミング操作
を不要とする。 【構成】 隠された持続性のあるキャラクタストリング
属性を、電子的ドキュメントについての人手による解釈
が可能な通常の要素に対して関連させることにより、そ
のような要素に対して、様々なタイプのボタンの態様を
付与することがユーザに対して許容するためのソフトウ
エアアーキテクチュアである。このアーキテクチュアに
よってこのようなボタンに許容されることは、エディッ
ト操作およびサーチ操作が、標準的なドキュメントエデ
ィタによって通常に提供されるエディットルーチンおよ
びサーチルーチンの使用を通してなされることである。

Description

【発明の詳細な説明】

【０００１】この発明は、コンピュータ駐在ソフトウエ
アシステムに対するカスタム化可能なユーザインタフェ
ースに関するものであり、より詳細には、プログラマは
もとより、非プログラマであっても、彼等のコンピュー
ティング資源（例えば、パーソナルコンピュータ、ワー
クステーション等）についての、ユーザインタフェース
のオーダに合わせることができるソフトウエアアーキテ
クチュアに関するものであって、これにより、彼等の個
別の要求および選択に緊密に合致させるようなインタフ
ェースを生成させることが許容される。これを更に詳細
にいえば、この発明のソフトウエアアーキテクチュアに
よれば、ドキュメント（テキスト、グラフィックス、表
および等式のようなもの）における通常のテキストエレ
メントおよび／またはグラフィックスエレメントについ
ての、隠された持続性のあるキャラクタストリング属性
として、構築された電子的ドキュメント内にアクティブ
ボタンを埋め込むことがユーザに対して許容されるよう
に、また、このようなボタンの動作特性を指定すること
がユーザに対して許容されるように、テキストエディタ
およびグラフィックスエディタ（以下、集合的に“ドキ
ュメントエディタ”として参照される）の能力を伸長さ
せることができる。

【０００２】多くの異なるマーケット区分における、カ
スタマの要求に対するコンピュータによる解決策のため
の、世界的な商業上の要請のために、ソフトウエアの生
産は成長産業になってきている。コンピュータユーザの
ある者は相当なプログラミング上の技能を備えているけ
れども、ツールとなっているコンピュータは、広範なコ
ンピュータプログラミングに係わる技能および／または
モチベーションが欠如したユーザによって使用されるこ
とが多い。かかる理由があることから、ユーザの意図す
るタスクに対するコンピュータの適用に焦点を合わせる
ことが、当該ユーザに対して許容されるようなユーザイ
ンタフェースを開発するために、ソフトウエアサプライ
ヤは相当な努力および費用を投じてきている。グラフィ
ックスに対するユーザインタフェースおよびウインドウ
パッケージは、ソフトウエアシステムにおける注目すべ
き例であって、現状では、非技術的なユーザから極めて
熟練したコンピュータの専門家までの者によるコンピュ
ータの使用を容易にすることが提案されている。しかし
ながら、当該システムのレベルでのソフトウエアは、そ
れ自体では、様々なインタフェースでの要求と異なるユ
ーザの選択との間での、実質的な特殊化が許容されてい
ない。

【０００３】ある一人のユーザにとって重大なソフトウ
エアユーザインタフェースの特徴は、他のユーザのディ
スプレイスクリーン上でのスペースを無用に占有する可
能性があることである。同様にして、ユーザのある者に
とって必要な特徴は、アプリケーションプログラマによ
っては含まれなかったことである。この結果として、ソ
フトウエアパッケージのあるものは、カスタム化可能な
ユーザインタフェースを有することになる。例えば、予
め定められた多様なオプションを提供するパッケージが
あり、このために、他の者を除外するように該オプショ
ンのあるものを選択的に起動することにより、ユーザは
自己のインタフェースをカスタム化することができる。
この発明に更に直接的に関係することとして、ここでの
ソフトウエアパッケージには、ユーザがアクティブボタ
ンを生成させることができるツール、および、ユーザの
個別の要求および選択の直接的な支持において機能を果
たすことをコンピュータにさせるためのメニューが含ま
れている。

【０００４】より詳細にいえば、ＨｙｐｅｒＣａｒｄプ
ログラムにより、ユーザは、個人的なボタン、フォーム
およびレイアウトを生成させることができる。ユーザに
よるこのようなボタンのプログラムが許容されるよう
に、いわゆるＨｙｐｅｒＴａｌｋ言語が維持されてい
る。Ｄ．グッドマン( D.Goodman)著の完全ＨｙｐｅｒＣ
ａｒｄハンドブック(The Complete HyperCard Handbo
ok), バンタムブックス(Bantam Books), 1987を参照さ
れたい。同様にして、Ｘｅｒｏｘ ＶｉｅｗＰｏｉｎｔ
なる製品は、ドキュメントに挿入できるボタンのプログ
ラミングをするための、ＣＵＳＰと呼ばれる言語によっ
て維持されている。これについては、ＶＰシリーズ参考
書集、ＶＰ ＣＵＳＰボタン参考書、バージョン２．
０、ゼロックスＶｉｅｗＰｏｉｎｔ、ゼロックスコーポ
レイション（VP CUSP Buttons Reference, VP Series R
eference Library, Version 2.0, Xerox ViewPoint, Xe
rox Corporation), 1988を参照されたい。これらのＣＵ
ＳＰボタンは、アイコンおよびウインドウを移動させる
ようにプログラムできるとともに、ファイルのプリン
ト、書式用紙への書き込み、電子的ファイルフォルダに
対する情報の組成、および、他のタスクを実行するとき
の支援をすることができる。ユーザが実行を所望する計
算実行のための等式において、ユーザによるプログラミ
ング操作が通常は許容されていることから、スプレッド
シートプログラムについてもある程度の関心がもたれ
る。

【０００５】いわゆるＡｎｄｒｅｗドキュメントエディ
タは、現状における更に別の関心がある例であるが、そ
の理由は、電子メールを介して送信されるために、ま
た、このようなメールメッセージの受信者によって使用
されるために、ボタンをドキュメントに含ませることが
許容されることにある。これについては、Ｊ．Ｈ．モー
リス(J.H. Morris) らの“アンドリュー：分散化バーソ
ナルコンピューティング環境 (Andrew: A Distribute
d Personal Computing Environment,) ”ＡＣＭの通
信(Communications of the ACM), Vol.29, No.3) 1986
年３月 184〜201頁を参照されたい。更に、ゼロックス
のＩｎｔｅｒｌｉｓｐ環境には、“Ｒｏｏｍｓ”と呼ば
れるウインドウマネージャが備えられており、アプリケ
ーションプログラムの始動をするために、プログラム状
態を記録して、後でそれをリストアするために、また、
ユーザが自動化を所望できる他の機能を実行するため
に、“ｒｏｏｍ−ｔｏ−ｒｏｏｍ”（即ち、ある一人の
ユーザが組成したファイルコレクションおよび処理実行
ツールから他者の方へ、または、換言すれば、ある１個
の“デスクトップ”から他の方へ）からスイッチするた
めのボタンのユーザによる生成が許容されている。これ
については、Ａ．マクリーン(A. MacLean)らの、“ユー
ザが仕立て可能なシステム：ボタンで刊行物を発行する
(User TailorableSystems:Pressing the Issues with B
uttons ”，コンピューティングシステムにおける人的
要因(Human Factors in Computing Systems), '90ＣＨ
Ｉ会報，1990年４月, 175〜182 ページを参照された
い。Ｒｏｏｍｓで維持されているボタンは、電子メール
を介して、ゼロックスのＩｎｔｅｒｌｉｓｐ環境を用い
ている他のユーザに対して転送されることが可能であ
り、また、ある一人のユーザのデスクトップに取り込ま
れて、当該ユーザのワークステーション環境におけるパ
ーマネントパーツになることができる。更に、それらが
具体化するＬＩＳＰプログラミング言語をエディットす
ることにより、または、それらの位置および／または外
見を変化させるメニューコマンドを用いることにより、
これらのボタンをカスタム化することができる。

【０００６】一般的にいえば、ユーザインタフェースの
カスタム化のために先行技術で提供されたボタンは、様
々な異なるアプリケーションで共有できるツールという
よりも、あるアプリケーションに特定のものであった。
このことは重大な不利益事項であるが、その理由は、異
なるアプリケーションの間で前後にスイッチすることに
なるファンクションをユーザが実行することができるに
しても、任意の時点においてユーザが自発的に割り当て
るディスプレイスクリーンのスペースは、大方のユーザ
にとってみれば限られた大きさでしかないことが見出さ
れていることにある。更に、このようなボタンがその中
に埋め込まれることが許容されないファンクションをユ
ーザが使用しているときには、ユーザが採用を所望でき
るカスタムボタンは、ユーザのディスプレイスクリーン
上において、アプリケーションからは空間的に分離して
いなければならず、これによってディスプレイスクリー
ンのスペース上での負担が加わるとともに、アプリケー
ションスペースとボタンスペースとの間で、ユーザによ
る注意を前後にシフトさせねばならない。

【０００７】ユーザインタフェースをカスタム化するた
めにボタンを使用することに対する従来の提案について
の更に別の不利益点は、このようなボタンがアプリケー
ション内に埋め込まれたときに、この埋め込まれたボタ
ンが“特別な”オブジェクトとして扱われることであ
る。従って、テキストドキュメント内に駐在するボタン
が、それ自体でテキストのストリングであるとしても、
ボタンのエディット操作で要求されることは、該当のボ
タンが駐在するテキストのエディット操作のために用い
られるとは別の操作について使用されることである。更
に、テキストストリングがサーチパターンと合致してい
るとしても、ボタンがドキュメントにおけるテキストの
構成部としては認識されていないために、通常のテキス
トのサーチ操作においてこのようなボタンを見出すこと
はない。

【０００８】この発明で提供されるソフトウエアアーキ
テクチュアによれば、隠された持続性のあるキャラクタ
ストリング属性を後記のような要素に対して関連させる
ことにより、電子的ドキュメントについての人手による
解釈が可能な通常の要素に対して、様々なタイプのボタ
ンの態様を付与することがユーザに対して許容される。
このアーキテクチュアによってこのようなボタンに許容
されることは、エディット操作およびサーチ操作が、標
準的なドキュメントエディタによって通常に提供される
エディットルーチンおよびサーチルーチンの使用を通し
てなされることである。

【０００９】以下の詳細な説明を添付の図面とともに参
照することで、この発明についての更なる欠陥や利点が
明かにされよう：図１は本発明のソフトウエアアーキテ
クチャの説明図であり、図２Ａ〜２Ｃは本発明によるボ
タンの生成における順次ステップを示す。図３Ａおよび
３Ｂはポップアップボタンのメニューを示す。図４Ａ及
び４Ｂはそれら自身の形式プロパティを選択されたグラ
フィックオブジェクトに変換することによってグラフィ
ック形式マクロスを達成するためのボタンの使用を示
す。図５Ａ〜５Ｃはマルチステートボタンからのユーザ
フィードバックを示す。図６はグラフィックラジオボタ
ンの組からのユーザフィードバックを示す。図７Ａおよ
び７Ｂはグラフィックエディタに埋め込まれた関連ラジ
オボタンの対からのユーザフィードバックを示す。図８
は本発明のソフトウエアアーキテクチャおよび標準的な
コンピュータシステムのアーキテクチャによって提供さ
れる通信経路を示す。図９Ａおよび９Ｂはそれぞれ本発
明によって構築された制御パネルおよびそのコンパクト
表現を示す。そして図１０Ａおよび１０Ｂはマルチステ
ートボタンとして機能する円から構成されたグラフィッ
クドキュメントを示す。

【００１０】Ａ．環境 この発明で構築される幾つかの特徴は、ある所定の新形
式のドキュメントエディタにおいて見出されるものであ
る。 （１） 任意なテキストの属性をドキュメントの要素と
関連付けさせる能力。 （２） ドキュメントエディタ自体よりも、アプリケー
ションに対して直接的な入力アクションをする能力。お
よび、 （３） 人手によるユーザよりも、ソフトウエアプログ
ラムによって特定されるエディット操作のアクションを
実行するための、エディット操作用言語を解釈する能
力。 従って、これらの特徴を具体化するエディタについて
は、これから簡略に説明される。更に、公開的に利用可
能な参照物の同定がなされるが、このために、ここでの
このような参照物は、この発明に対する適当な環境をよ
り十分に規定するための参照物として取り込まれる。

【００１１】１．隠された持続性のあるキャラクタスト
リング属性 ゼロックスのＢｒａｖｏテキストエディタ（“Ｂｒａｖ
ｏマニュアル，”Ａｌｔｏユーザーハンドブック，ゼロ
ックス・パロアルト・リサーチセンタ，1979,31〜62を
参照），Ａｎｄｒｅｗエディタ (Ｊ. モリス (J. Morri
s)らのｓｕｐｒａを参照），ゼロックスのＳｔａｒ
（Ｊ．ジョンソン (J. Johnson) ら“The Xerox Star:A
Retrospective, ”コンピュータ誌(Computer),Vol.22,
No.9,９月 1989, 11〜29ページ) ，および，Ｇｒｉｆ
エディタ（Ｒ．フルタら“相互作用的エディテングで構
築されたドキュメント（Interactively Editing Stru
cturedDocuments,”電子出版 (Electronic Publishin
g) ，Vol.1, No.1, 4月, 1988, 19〜44ページを参照）
は、（タイプフェース、カラーおよびアルファベットの
ような）隠された持続性のある属性を、ドキュメントに
ついての通常のキャラクタ要素またはグラフィックス要
素と関連付けさせることが、ユーザに対して許容される
ドキュメントエディタの例である。これらの属性に“持
続性”がある理由は、磁気ディスクまたはテープのよう
な長期間メモリ、安定的な半導体メモリ、または、他の
持続性のあるメモリ資源内に、それらの属性がドキュメ
ントとともに蓄積されているためである。更に、これら
の属性は、ユーザからユーザへ、または、コンピュータ
からコンピュータへと転送可能なものである。これに加
えて、そのテキスト的な記述（例えば、“ｒｅｄ”また
は“Ｔｉｍｅｓｒｏｍａｎ”）が、ドキュメントがビュ
ーされたりプリントされたりするときには、属性が埋め
込まれているこのようなドキュメントの構成部分とは表
現されないために、該属性が“隠される”ことになる。
代替的に、この表現プロセスにおいては、それらの属性
を関連のあるドキュメント要素に対して適用して、これ
により、それらの要素を例えばｒｅｄで表現させたり、
または、Ｔｉｍｅｓｒｏｍａｎのタイプフェースをもっ
て表現させたりする。Ｔｉｏｇａエディタ（Ｒ．ビーチ
(R. Beach) の“形式をもつテーブルおよびイラストの
設定 (Setting Tables and Illustrations with S
tyle)," 1985年、カナダ、ウオータールーのウオーター
ルー大学，Ｐｈ．Ｄ．理論を参照。−−ゼロックスＰＡ
ＲＣテクニカルレポートＣＳＬ−８５−３としても利用
可能）のような、幾つかの実在するエディタにおいて
は、隠された持続性のある属性の概念を拡張して、ユー
ザの選択にかかる任意のキャラクタストリングが、テキ
ストのキャラクタおよびグラフィックスの形状のよう
な、通常のドキュメント要素の隠された持続性のある属
性として含まれることを許容している。このことは、異
なるハードウエアおよびソフトウエアの環境にあるユー
ザ間でのドキュメントの交換のためには重要な特徴であ
ると考えられる。そして、このために、将来のドキュメ
ントエディタに対して更に普遍性のある特性になるもの
と期待される。

【００１２】２．入力の方向変換 幾つかの実在するエディタは、エディタ自体よりもアプ
リケーションプログラムに対して、入力の方向変換アク
ションをすることができる。例えば、シンボリック表現
マネジャー（Symbolic Presentation Manager) （Ｓ．
マッケイ (S. McKay) ら“応用意義学に基づく表現マネ
ジャ (A Presentation Manager Based on Application
Semantics), 1989年11月，ユーザインタフェースソフト
ウエア及び技術に関するＡＣＭ ＳＩＧＧＲＡＰＨシン
ポジウム会報 (Proceedings of the ACM SIGGRAPH Symp
osium on User Interface Software and Technology) 1
41〜148 頁) で許容されるコマンドによれば、エディタ
から分離したアプリケーションプログラムへと方向変換
するように、ある所定のテキスト要素をカーソルで指定
しているときに、“マウス”ボタンを起動することによ
ってユーザが介入することができる。同様にして、マウ
スボタンを起動することにより、ユーザがＨｙｐｅｒＴ
ａｌｋプログラムを実行できるようにして、Ｈｙｐｅｒ
Ｃａｒｄによる入力の方向変換がなされる。

【００１３】３．ランタイムが解読されるエディット操
作言語 エディット操作言語のランタイムを解読することができ
るドキュメントエディタも知られている。例えばＥＭＡ
ＣＳテキストエディタによれば、テキストのエディット
操作を支持するＬＩＳＰプログラミング言語の方言が解
読される。同様にして、前述されたＴｉｏｇａエディタ
によれば、解読される言語で表現されるべき全てのエデ
ィット操作のアクションが許容され、これにより、人手
によるユーザまたはコンピュータプログラムのいずれか
のコントロールの下に、交換可能に実行されるべきエデ
ィット操作が許容される。

【００１４】Ｂ．埋め込み型のボタンアーキテクチュア この発明によるソフトウエアアーキテクチュアにおいて
は、既知のドキュメントエディタについての上述された
特徴（即ち、隠された持続性のあるキャラクタストリン
グ属性、入力の方向変換、および、ランタイムが解読さ
れるエディット操作言語）の利点が得られ、電子的ドキ
ュメントの生成可能な（ｒｅｎｄｅｒａｂｌｅ）部位の
任意のテキスト要素またはグラフィックス要素（例え
ば、このようなドキュメントの構造およびレイアウトを
規定するマシンで解読可能な要素に対抗するような、テ
キスト、グラフィックス、表および等式）に対するボタ
ンの態様を付加するオプションがユーザに与えられて、
正常なエディット操作およびサーチ操作の下ではボタン
が特別に扱われることがないようにされる。これをより
詳細にいえば、図１に示されているような、１個または
複数個のドキュメントエディタ１１の各々に含まれてい
る入力方向転換ソフトウエアスイッチは、ユーザによっ
て、入力方向転換を不可能にする“ボタンオフ”状態、
または、入力方向転換を可能にする“ボタンオン”状態
にセットすることができる。ある特定のドキュメントを
管理しているエディタ１１の入力方向転換ソフトウエア
スイッチが“ボタンオン”状態にセットされたときに
は、該当のエディタは、それが受け入れた全ての入力コ
マンドを実行して、その正常なエディット操作をするよ
うにされる。しかしながら、エディタ１１の入力方向転
換スイッチが“ボタンオフ”状態にセットされたとすれ
ば、マウスによってコントロールされるカーソルが、埋
め込みボタンを有するある１個のドキュメント要素にお
けるポイントに対して位置しているときの、マウスボタ
ンのクリック操作のようなある予め選択された入力コマ
ンドが、“埋め込みボタンカーネル”と呼ばれる集中ソ
フトウエアモジュール１２に対して回送される。

【００１５】ドキュメントエディタ１１が“ボタンモー
ド”（即ち、その入力方向転換スイッチが“ボタンオ
ン”状態にセットされている）で動作しているとすれ
ば、ドキュメント要素が選択されたときに、このような
要素がボタン属性を有しているかどうかを決定するため
に、該エディタ１１によって試験される。そして、これ
が肯定であったときには、ある予め規定されたユーザ入
力アクションが埋め込みボタンカーネル１２へと方向転
換するようにされる。このような方向転換入力コマンド
を受け入れたときには、埋め込みボタンカーネル１２
は、選択されたドキュメント要素についてのボタン属性
を規定するキャラクタストリングを、ボタンクラスマネ
ージャ１３内のクラスを特定するボタンハンドラへと中
継する。より十分に後述されるように、このボタンハン
ドラは、これに次いで、選択されたドキュメント要素の
ボタン属性を読み取って、取るべきアクションの決定を
行う。そして、それらのアクションを実行するために必
要なコマンドハンドラルーチン１４を呼び出し、エディ
タに対するエディタ入力言語ストリングを伝送して、所
望のフィードバックをユーザに対して提供する。これか
ら認められるように、コマンドハンドラ１４にはドキュ
メントエディタ１１の任意のもの、および、付加的なア
プリケーションプログラムを含ませることができる。

【００１６】この発明に関しては、ドキュメントエディ
タ１１は、全ての属性がキャラクタストリングによって
規定されるという知識を除いて、このようなボタン属性
の任意のものについての内部的な形式または内容に関す
るいかなる知識も有する必要はない。これらのストリン
グはエディタのデータ構造において見出された属性とは
区別されるものであることから、このようなドキュメン
トを能動的に管理しているエディタについての正常なエ
ディット操作およびサーチ操作は、能動的なエディタの
入力方向転換スイッチが“ボタンオフ”状態（そして、
多くのエディット操作機能は、たとえ“ボタンオン”状
態にあっても、その作業を続行する）にセットされてい
るときには、該ドキュメントに埋め込まれたボタンのエ
ディット操作およびサーチ操作のために用いることがで
きる。これに対して、能動的なエディタ１１の入力方向
転換スイッチが“ボタンオン”状態にセットされている
ときには、ユーザによってトリガされる任意のボタンの
ボタン属性を規定するキャラクタストリングが集中型の
埋め込みボタンカーネル１２に対して渡されて分析さ
れ、これにより、ボタンクラス１３内のボタンハンドラ
の一つが、該当のボタンが実行を意図されている機能を
果たすことが必要とされているアプリケーションプログ
ラム１４に対して渡される。

【００１７】上述されたアーキテクチュアの結果とし
て、いずれのドキュメントエディタでもストレートにプ
ログラミングされて、内部にロードされたドキュメント
の要素をボタンとして扱うようにされる。更に、ボタン
が埋め込まれているドキュメントまたはドキュメント要
素のタイプに拘らず、任意の与えられたクラスにおける
全てのボタンは矛盾のない態様でのふるまいをする。こ
の理由は、それらのふるまいがソフトウエアの共通本体
によって支配されていることにある。

【００１８】Ｃ．ボタンで実施される機能 この点において次のことが理解される。即ち、この発明
によって提供されるボタン属性のアーキテクチュアによ
れば、ユーザが電子的ドキュメントエディタを用いるこ
とが可能にされ、ドキュメントの要素をカーソルで指定
することにより、そして、これに次いで適当な入力デバ
イス（マウス上のボタン、ペンのチップ上のコンタクト
デテクタ、または、キーボード上のキーのようなもの）
を起動することによって予め選択されたアプリケーショ
ンルーチンをユーザが起動できるように、能動的なボタ
ンの態様が電子的ドキュメントの要素と関連される。こ
の発明の代表的な実施の例示をするために、比較的スト
レートになされるファイルオープン操作のタスクに適用
されているものとして、詳細な紹介例が以下に開示され
る。この例で示されることは、正常なドキュメント要素
としてまだエディット操作され、サーチされることが可
能なボタンに対して、テキストキャラクタの任意のスト
リングをユーザが向けていくやり方である。ただし、紹
介例に入っていくのに先だって次のことが注意される。
即ち、ここで開示されるシステムにおいては種々の異な
るタイプのボタンを支持することが可能である。なお、
ここでのボタンに含まれているものは、トリガされたと
きにアプリケーション機能を実行する“ポップアップボ
タン”、トリガされたときにある値の記憶や変更をする
“マルチ状態ボタン”と呼ばれるボタン、および、“オ
ン”または“オフ”のいずれかにあって、任意の与えら
れた時点においてそれらのグループの中のある１個のボ
タンだけが“オン”にされる、“ラジオボタン”と呼ば
れるボタンである。その完全を期するために、後続の説
明文においては、それら３タイプのボタンおよびそれら
の特性や使用の例示がなされる。

【００１９】１．導入的な例示：ファイルをオープンす
るボタン この例示についての目的のために、ＵＮＩＸオペレーテ
ィングシステムのユーザが所望することは、該ユーザが
日報的に注記をしている“〜／ｗｒｉｔｉｎｇｓ／ｄｉ
ａｒｙ”なる名称のファイルのエディット操作が極めて
容易にされることであると仮定される。更に仮定される
ことは、このユーザは、書き込みがなされるときにはい
つでも、自己のコンピュータのディスプレイスクリーン
上に表示される、“ＡｌｗａｙｓＯｐｅｎ”なるファイ
ルを有していることであり、これによって、該ユーザは
該当のファイルに対して、テキストストリング“〜／ｗ
ｒｉｔｉｎｇｓ／ｄｉａｒｙ”を付加することになる。
この点において、該ファイル“ＡｌｗａｙｓＯｐｅｎ”
は代表的には図２Ａのようにみえる。これに次いで、マ
ウスのような適当なカーソルコントローラを用いること
により、ユーザはストリング“〜／ｗｒｉｔｉｎｇｓ／
ｄｉａｒｙ”を選択し、そして、自己のウインドウシス
テムにおけるツールのセットから利用可能なボタンを起
動して、選択されたテキストストリングの周辺のボック
ス２０を取り出す。そして、このボックスを、ファイル
“〜／ｗｒｉｔｉｎｇｓ／ｄｉａｒｙ”上のテキストエ
ディタウインドウを始動させるコマンドを含んでいるテ
キストストリングと関連させる。ここで、“Ａｌｗａｙ
ｓＯｐｅｎ”は図２Ｂのようにみえる。その後で、生成
された新規なボタンについての厳密な試験をするため
に、ユーザはボックスで囲まれた“〜／ｗｒｉｔｉｎｇ
ｓ／ｄｉａｒｙ”のテキストストリングの選択をする。
これの選択は、スクリーンカーソルの位置決めをするマ
ウス（２１で示されている中心でのブラックドットを有
するブラックサークルは、マウスでコントロールされる
カーソルを表している）を用いるようなことによってな
される。次にユーザはマウス上の物理的なボタンの一つ
を押して、ファイル“〜／ｗｒｉｔｉｎｇｓ／ｄｉａｒ
ｙ”を含んでいる新規なテキストエディタウインドウの
オープン操作をさせる。

【００２０】ここで想起されるように、テキストストリ
ング“〜／ｗｒｉｔｉｎｇｓ／ｄｉａｒｙ”がボタンと
して作用するのは、“ＡｌｗａｙｓＯｐｅｎ”ファイル
を管理しているテキストエディタが“ボタンオンモー
ド”にある間（即ち、その方向転換スイッチが“ボタン
オン”状態にある間）だけということである。この結果
として、ユーザがボタンモードをオフしたときには、該
当するエディタの標準的なテキストのエディット操作お
よびサーチ操作の特徴を用いて、“ＡｌｗａｙｓＯｐｅ
ｎ”ファイルのテキストのエディット操作およびサーチ
操作をすることが可能にされる。例えば、日報（ｄｉａ
ｒｙ）のファイル名を入力する際にエラーが生じたとす
ると、誤りのあるファイル名上にボタンが生成された後
であっても、ユーザは正常なエディット操作を用いるこ
とができて、該当のファイルが“ＡｌｗａｙｓＯｐｅ
ｎ”ファイル内でリストにされている名称を訂正するよ
うにされる。

【００２１】２．ボタンタイプ この説明区分においては、この発明によって支持される
更に基本的なタイプの、３種のボタンについて説明され
る。即ち、ポップアップボタン、マルチ状態ボタン、お
よび、ラジオボタンについての説明であって、異なる種
類のドキュメントにおいてそれらのボタンが使用される
やり方の例示が含まれている。その他のボタンタイプの
ものを付加できるのは勿論であるから、ここで説明され
るタイプのものは代表例として意図されるだけのもので
ある。

【００２２】ａ．ポップアップボタン ポップアップボタンに生成されたドキュメントオブジェ
クト上を、ユーザがマウスボタン等で押えると、カーソ
ル上に集中したそのエントリの一つとともに、ポップア
ップメニューが現れてくる。有利になされることは、カ
ーソル上に集中しているメニューエントリは、押されて
いるマウスボタンに依存するものであり、また、例え
ば、これも押されているＣＴＲＬおよび／またはＳＨＩ
ＦＴキーボードキーのいずれか一方または双方に依存す
るものである。これに加えて、ユーザがマウスボタンを
早くクリックしたときには、ポップアップメニューのデ
ィスプレイが抑制されて、ＣＴＲＬ，ＳＨＩＦＴ，およ
びユーザが用いているマウスボタンの組み合せによって
決定されるような、ユーザのメニュー選択の適用を直接
的に告知するようにされる。このポップアップメニュー
の働きについては、能動的なドキュメントに対するその
使用ではないけれども、先に説明されている。Ｋ．ピア
(K. Pier) らの“水落し口への導入：会話式作図ツール
(An Introduction to Gargoyle: An Interactive Illu
stration Tool)”ドキュメント操作と印刷術 (Document
Manipulation and Typography) 、'88 ＥＰ会報、ケン
ブリッジ大学出版部、1988年、 223〜238 ページ、が参
照される。ゼロックスＰＡＲＣテクニカルＥＤＬ−８９
−１としても利用可能なものである。

【００２３】図３Ａに例示された能動的なドキュメント
に含まれている４個のポップアップボタンの各々は、ボ
ックスで囲まれて示されている。各ボタンによって、１
個または複数個のテキストエディタマクロが実行され
る。各ボタンに続いているものは、その機能についての
記述である。図３Ｂにおいては、テキストストリング
“Ａｌｐｈａｂｅｔ”の上でユーザがマウスを押し下げ
ており、これによりポップアップメニューが現れて、い
ずれかの他のドキュメント（図示されない）において現
に選択されているテキストストリングのアルファベット
を変更することを、ユーザに対して許容するようにされ
ている。メニュー上で重ね合わされているピクトリアル
プロンプト２５により、３個のマウスボタンのいずれが
将来のボタンプレスに対するアクセル体として使用でき
るかの指示がなされている。更に、方形２６によってデ
ィスプレイされるものは、現に選択されているメニュー
エントリを記述するフィードバックであり、また、図３
Ｂにおける白抜きワード“Ｌａｔｉｎ”上で一部可視の
矢印２７はカーソル（このカーソルは、ポップアップメ
ニューが能動的であるときに矢印の形状をなすものとさ
れる）である。

【００２４】図４Ａにおける各ラインセグメントはポッ
プアップボタンであって、そのダッシュパターンまたは
ライン幅を、選択されたグラフィックオブジェクトに転
換するものである。ここで、これらのボタンは、図４Ｂ
に示されているマルチセグメントの形状のダッシュパタ
ーンに変更するために用いられている。前述されたＧａ
ｒｇｏｙｌｅエディタのような既知のグラフィックスエ
ディタは、これらのラインのようにエリアの殆どないボ
タンの選択を可能にするために、 "即引き”重力 ("sna
p-dragging"gravity) が用いられている。これについて
は、Ｅ．ビヤ (E. Bier)らの“即引き”コンピュータグ
ラフィック(Computer Graphics), Vol.20, 1986年 8月,
233 〜240 ページが参照される。

【００２５】ｂ．マルチ状態ボタン マルチ状態ボタンは、マウスクリックのようなユーザの
入力するコマンドに応答して、このクラスの各ボタンに
存在する区別された変数、要求されたＶａｌｕｅの内容
を修正するようにされる。このＶａｌｕｅ変数のサイク
ルは、ユーザによって規定されるストリングのセットを
通してなされる。例えば、ストリングが“オン”および
“オフ”であるときには、ボタンは、トリガされたとき
に、“オン”と“オフ”との間でスイッチされる。スト
リングが“アップル”、“バナナ”および“グレープフ
ルーツ”であるときには、ボタンはそれらの名称を通し
てサイクルされる。

【００２６】ユーザ／カスタムインタフェース設計者
は、各状態がどのように表示されるべきかを決定するこ
とができる。図５Ａ−図５Ｃに示される幾つかのボタン
の各々は、オンおよびオフの２個の状態を有している。
これらのボタンの現在の状態は、フォントを変更する
（図５Ａ）ことにより、テキストと背景とのビデオコン
トラストを反転させる（図５Ｂ）ことにより、または、
ボタンのテキスト内容を変更する（図５Ｃ）ことにより
指示される。実際に、このような強調を達成させるため
に、任意の適当なドキュメントエディタ操作を使用でき
ることは明白であろう。

【００２７】マルチ状態ボタンは、それらがアプリケー
ションをコントロールするために用いられるときには、
最も有用なものである。より詳細に後述されるように、
ボタンの名称、および、該ボタンが埋め込みボタンシス
テムに対して配置されているときの仮想メモリアドレス
を与えることにより、アプリケーションはボタンの値を
読み取ることができる。そして、与えられた名称のボタ
ンが与えられたドキュメント内で見出されたときには、
該システムはその値をアプリケーションに戻すことにな
る。ボタンがドキュメント内のどこに配置されている
か、または、該ボタンのクラスが何であるかさえも、ア
プリケーションは知る必要がない。ある与えられた名称
のボタンが状態を変更しようとしているときをアプリケ
ーションが識別することができ、これによって、該アプ
リケーションによるこのような状態変更のコントロール
が可能になる。従って、能動的なドキュメントにおける
トリガボタンによって開始されるアクションは、アプリ
ケーションプログラムの他のアクションによって同期を
とることができる。

【００２８】ｃ．ラジオボタン ラジオボタンはボタングループのメンバーであって、一
度に“オン”になるのはその中の１個だけである。かく
して、このようなボタンをトリガすることにより、代表
的には、当該ボタンを“オン”にする間に、そのグルー
プにおける他の全てのボタンを“オフ”にする。マルチ
状態ボタンと同様に、ユーザ／カスタムインタフェース
デザイナは、このようなボタンがその状態を反映する外
見を変更するやり方を決定することができる。この例に
おいては、ラジオボタンはドキュメントの存在箇所より
もそれらのグループの名称を参照するようにされてお
り、このために、それらは互いに近接して配置される必
要がない。

【００２９】図６における各々の矢印はラジオボタンで
ある。ここで示されるように、ある１個の矢印をクリッ
クしてそれをブラックにすると、他の全ての矢印はホワ
イトにされる。

【００３０】Ｄ．ボタン属性アーキテクチュアの詳細な
レビュー この発明のボタン属性アーキテクチュアによれば、通常
のテキストドキュメント要素およびグラフィックスドキ
ュメント要素がボタンとして作用できるように、ドキュ
メントエディタの修正および構築をするやり方が提供さ
れる。この文節においては、アーキテクチュアおよびそ
の新規な局面が詳細に説明され、また、このアーキテク
チュアが現在のエディタ技術についていかなる利点があ
るかが、より十分に指摘される。

【００３１】ここで認められるように、ボタン属性アー
キテクチュアは５個の主要部を有している： １．ボタン属性。“ボタン属性”と呼ばれるキャラクタ
ストリングは、ボタンの態様をもたせるような、“Ｅ”
と呼ばれる任意のドキュメント要素にリンクされる。こ
のキャラクタストリングは、所望されるボタンの態様の
タイプを記述するものである。 ２．エディタ特性。この発明を実施するために用いられ
るべきいずれのドキュメントエディタであっても、ボタ
ン属性を有するそれらのドキュメント要素を見出して列
挙することが可能でなければならず、また、当該属性を
有するドキュメント要素上またはその近傍で生じる、あ
る所定のユーザの入力によるアクション（例えば、マウ
スアクション）の（埋め込みボタンカーネルに対する）
行程を変更できるものでなければならない。 ３．埋め込みボタンカーネル。埋め込みボタンカーネル
で分析されるボタン属性は、ボタンを含んでいるドキュ
メントを管理するエディタ、該ボタン属性において特定
されるボタンクラスに適当なボタンハンドラ、および、
ある与えられたボタン属性によって特定されるアクショ
ンを実行するために要求される、“コマンドハンドラ”
と呼ばれるアプリケーションパッケージの間での通信を
達成させるものである。ここで付与される通信は、ボタ
ンアクションと関連する任意のフィードバックを実行す
るためにボタンが埋め込まれている、エディタを求める
ボタンハンドラをも可能にするものである。更に、ボタ
ンを含んでいるドキュメントがアプリケーションコント
ロールパネルとして用いられるときには、カーネルがこ
れに応答して、特定のドキュメントを特定のアプリケー
ションウインドウにリンクさせることを要求し、また、
ボタンに関連する入力アクションを適切なウインドウに
向けるようにする。 ４．ボタンクラス。ボタンクラスはボタンハンドラのセ
ットであって、埋め込まれたボタンの異なるクラスにつ
いての特定の機能を規定するものである。新規なクラス
を登録するカーネル内のルーチンを呼ぶことにより、新
規なボタンクラスをランタイムでのシステムに付加する
ことができる。かくして、新規なボタンクラスに対する
ボタンハンドラソフトウエアは、システムの他の部分を
再配置することなしにデバッグすることができる。 ５．コマンドハンドラ。コマンドハンドラは、ユーザが
それらを参照する埋め込みボタンの使用を開始するのに
先立つある所定の時点において（例えば、ユーザがログ
インをする時点において、または、埋め込みボタンソフ
トウエアがロードされる時点において）、埋め込みボタ
ンカーネルとともに自身を登録するためのアプリケーシ
ョンである。埋め込みボタンがトリガされたときには、
ボタンが属しており、該当のボタンにおいて記述されて
いるアクションを実行するクラスのために、適切なコマ
ンドハンドラがボタンハンドラによって呼ばれる。同様
なボタンクラスに、カーネルとともに登録されることに
よって新規なコマンドハンドラが動的に付加され、これ
により、システムの残りを再ロードすることなく、それ
らを容易にデバッグするようにされる。

【００３２】更に、起動されるときにボタンがその外見
を変更しようとするのであれば、第６のアーキテクチュ
ア上の特徴が必要とされる。 ６．エディタ入力言語。Ｅが埋め込まれるドキュメント
エディタは、該ドキュメント上で実行できるエディット
操作アクションを記述する（テキストストリングからな
る）入力言語を付与せねばならない。このようなエディ
タで解読可能な入力ストリングをボタン属性に含ませる
ことにより、ボタンがトリガされたときにボタン（また
は任意の他のドキュメント要素）の外見について所望の
変化をもたらすようなエディタアクションを、ボタン自
体の中に記述することができる。

【００３３】これら６個のアーキテクチュア上の特徴に
より、次のような幾つかのボタン機能が支持される。 ａ．ユーザが埋め込みボタンをトリガしたときに応答す
ること、 ｂ．アプリケーションプログラムの要求により１個また
は複数個のボタンの値の更新または点検をすること、お
よび ｃ．アプリケーションウインドウ（ドキュメントにおけ
るボタンのサブセットに対するコマンドハンドラとして
作用するもの）にドキュメントをリンクして、ボタンア
クションを該リンクしたウインドウに転送すること。

【００３４】図１で例示されている通信経路は、埋め込
みボタンアーキテクチュアによって設けられるものであ
る。ここで示されているように、カーネル１２はスイッ
チボードとして作用して、他の構成部との間でのメッセ
ージの転送をする。このアーキテクチュアにより、新規
エディタ１１、ボタンクラス１３またはコマンドハンド
ラ１４が、動的に容易に付加される。それらはカーネル
に関する名称およびルーチンの登録をしてあり、登録さ
れた名称からくる任意のメッセージについて、その後で
の転送をするようにされる。

【００３５】このアーキテクチュアの６個の部分の各々
−−ボタン属性、エディタ特性、埋め込みボタンカーネ
ル、ボタンクラス、コマンドハンドラおよびエディタ入
力言語−−については、更に詳細に後述される。その説
明の過程においては、該アーキテクチュアによる３個の
主要な機能を遂行するやり方が示される。即ち、ユーザ
の入力コマンド（例えば、ボタンクリック）に対する応
答、値の更新および点検、および、アプリケーションに
対するドキュメントのリンクという３個の主要な機能を
遂行するやり方が示されることになる。

【００３６】１．ボタン属性 先に指摘されたように、この発明を支持する全てのエデ
ィタは、“ボタン属性”と呼ばれるストリングに値が付
与される属性を、任意の与えられたドキュメント要素
（例えば、テキストキャラクタ、パラグラフ、グラフィ
ックス形状等）と関連させることが可能でなければなら
ない。ドキュメントが磁気ディスクまたは他の持続性が
あるメディアに蓄積されるときには、このストリングが
該ドキュメントとともに蓄積されねばならない。その動
作においては、ドキュメントがメモリに読み込まれると
きに、このボタン属性ストリングが埋め込みボタンカー
ネルにより読み取られて、急速アクセスのためのデータ
構造内に転送される。ドキュメントエディタが、このよ
うなボタン属性のデータ構造をドキュメント要素（ボタ
ン属性ストリングに代えて）と関連させることができる
ときには、ボタンがトリガされる度に埋め込みボタンカ
ーネルによるストリングの再読み取りを必要としないこ
とから、その実行能力が改善される。

【００３７】ボタンアーキテクチュアのテキストストリ
ングは、名称フィールドをテキストストリング値と結合
させる、“Ｐｏｐｐｙ”と呼ばれる簡単な言語によって
書かれている。この言語はＣＵＥ Ｆｏｒｍｓ言語によ
って示唆されたものである。これについては、Ｔ．カッ
ツマレック (T. Kaczmarek),“ＣＵＥ Ｆｏｒｍｓ表
現”サザンカリフォルニア大学の内部技術レポート (In
ternal Technical Report of University of Southern
California), 情報科学研究所 (Information Science
s Laboratory) ，1984年 7月25日, が参照される。ボタ
ンの態様を変更するために、ユーザは手動でＰｏｐｐｙ
ストリングのエディット操作をすることができるが、こ
のボタンの態様を変更するための他のやり方がある。例
えば、新規のボタンを生成させるためにユーザができる
ことは、ボタンになるべきドキュメント要素の選択をし
て、“ボタナイザ（ｂｕｔｔｏｎｉｚｅｒ）”と呼ばれ
る実在のボタンを起動させることであるが、その目的が
新規のボタンを生成させることである。以下に認められ
るように、代表的なボタナイザボタンについて、より十
分に後述される。

【００３８】ボタン属性の一例として、代表的なポップ
アップボタンのＰｏｐｐｙ言語による記述によって、こ
こに、選択されたオブジェクトのカラーの変更がなされ
る。このポップアップボタンはここに示されている。 Ｐｏｐｐｙ１ Ｃｌａｓｓ：ＰｏｐＵｐＢｕｔｔｏｎ ＣｏｍｍａｎｄＨａｎｄｌｅｒ：Ｃｏｌｏｒｉｚｅｒ Ｍｅｎｕ：（ ((SetColor Red) "Red" "Makes selected objects red") ((SetColor Green) "Green" "Makes selected objects green") ((SetColor Blue) "Blue" "Makes selected objects blue") ） Feedback: ( Enter: ＜SetCursor bullseye＞ Down: (BeginButton MakeBold EndButton) Exit, EndActivity: (BeginButton MakeItalic EndButton) ）

【００３９】先の例において、第１のワード“Ｐｏｐｐ
ｙ１”の意味することは、次のプログラムはＰｏｐｐｙ
言語によるバージョン１のものということである。ここ
で認められるように、これには次の４個のボタンデータ
フィールドが付随している。即ち、Ｃｌａｓｓ，Ｃｏｍ
ｍａｎｄＨａｎｄｌｅｒ，ＭｅｎｕおよびＦｅｅｄｂａ
ｃｋなるボタンデータフィールドが付随している。

【００４０】ボタンのクラスで決定されることは、コー
ドのいずれのボディ（即ち、ボタンハンドラ）がボタン
に対するユーザの入力を扱うのかということであるか
ら、全てのボタンはＣｌａｓｓフィールドを持たねばな
らない。ここでの場合におけるＣｌａｓｓ は“Ｐｏｐ
ＵｐＢｕｔｔｏｎ”である。

【００４１】ＣｏｍｍａｎｄＨａｎｄｌｅｒフィールド
で同定されるコマンドハンドラアプリケーション１４
（図１）は、該当のアプリケーションがカーネル１２で
登録されているしたでの名称を用いることによって、こ
のボタンのポップメニューにおいて選択されたコマンド
を受け入れるものである。上記のボタンに対するコマン
ドハンドラは“Ｃｏｌｏｒｉｚｅｒ”アプリケーション
であって、選択されたオブジェクトのカラーを、ボタン
のメニューにおける名称のカラーに変更するものであ
る。

【００４２】上記の例におけるＭｅｎｕフィールドに
は、ポップアップボタンのクラスハンドラで理解される
ＬＩＳＰと同様なシンタクスによってポップアップメニ
ューが記述されている。このメニューは、“Ｒｅｄ”、
“Ｇｒｅｅｎ”および“Ｂｌｕｅ”なるラベルが付され
た３個のエントリを備えている。これらのエントリレベ
ルに追従するテキストストリングは、カーソルが該当の
エントリの上にあるときにディスプレイされるドキュメ
ンテーションストリングである。各エントリ名の前の括
弧付きの表現は、アプリケーションに対して伝送される
テキストストリングを表している。

【００４３】Ｆｅｅｄｂａｃｋフィールドのサブフィー
ルドにおいては、種々のボタンイベントが生じたときに
とられるべきアクションが決定される。“Ｅｎｔｅｒ”
サブフィールドにおいては、このボタンに入ったとき
に、カーソルをしてブルザイの形状に変化させる。“Ｓ
ｅｔＣｕｒｓｏｒ ｂｕｌｌｓｅｙｅ”の周囲の角括弧
は、ボタンを管理するエディタに対してそれを渡すより
も、Ｐｏｐｐｙ に対してこの表現自体の解読をするよ
うに指示している。“Ｄｏｗｎ”サブフィールドに含ま
れているものは、前述されたＴｉｏｇａテキストエディ
タの入力言語における表現のストリングであって、該エ
ディタをして、このボタンのテキストに対してボールド
体フォントを適用させるものである。同様にして、“Ｅ
ｘｉｔ，Ｅｎｄ Ａｃｔｉｖｉｔｙ”フィールドにおい
ては、ボタンのアプリケーションでその演算を仕上げた
とき、または、クリックの完了に先だってボタンのカー
ソルアウトを移動させることによって、ユーザがその操
作を中止したときには、ボタンをプレーン体フォントに
回復させる。

【００４４】Ｐｏｐｐｙ言語においては、各フィールド
の値は、ホワイトスペースによって限定される単一の英
数字ストリング、または、引用マーク“”，丸括
弧（），角括弧＜＞のような標準的な境界符号間のスト
リング（ホワイトスペースを含むことができる）のいず
れかである。エディタがボタンを含むファイルをディス
クから読み取ったときには、埋め込みボタンカーネルを
して、各ボタンのボタン属性を分析させる。カーネルで
は、ボタン属性ストリングを分析して、（フィールド
名）／（フィールド値）対のセットにする。ここで、各
フィールド値は未解読のストリングであって、ボタンク
ラスに対する適当なボタンハンドラにそれらの対を渡す
ようにされる。そして、これにより、クラスを特定する
ボタンハンドラをして、ボタンを表すランタイムのデー
タ構造を構築させる。

【００４５】マルチ状態ボタンおよびラジオボタンは、
２個の付加的なデータフィールド−Ｎａｍｅ（名称）お
よびＶａｒｉａｂｌｅｓ（変数）−を持っており、これ
らは例えばＰｏｐｐｙで表現されている。 Ｎａｍｅ：Ｆｒｕｉｔ Ｖａｒｉａｂｌｅｓ： (Value:｛orange, apple, banan
a ｝ = orange)

【００４６】上記の例においては、Ｖａｌｕｅはｏｒａ
ｎｇｅ，ａｐｐｌｅ，またはｂａｎａｎａなる値を有す
る変数であって、その現在の値は“ｏｒａｎｇｅ”であ
る。その読み取りまたは書き込みの目的のために、ボタ
ン名“Ｆｒｕｉｔ”を用いて、アプリケーションではこ
の値を参照する。複数のボタンが同一の名称を有してい
るときには、このボタン名の値はあいまいになる。従っ
て、この問題の代表的な解決は次のようにしてなされ
る。即ち、同一の名称を有する全てのボタンに対して同
一の値を強制的に持たせておき、それらの中のどの１個
の値が変更しても、他の全てを変更することによって解
決される。しかしながら、代替的なこととしては、階層
的な構造にされたドキュメントのある特定のサブパート
において、ある与えられた変数名についての値を調べる
ことができる。例えば、ボタンＡが変数名Ｎなる値を参
照したとすると、システムにおいては、まず第１にＡが
生じたパラグラフにおける変数Ｎの値を調べること、こ
れに次いでＡが生じたサブセクションにおいて調べるこ
と、これに続けてそのセクションにおいて調べること、
等々のことがなされる。このようなやり方において、名
称のあいまいさをなくすために、ドキュメントの階層的
な構造を用いることができる。

【００４７】２．エディタ特性 エディタ１１（図１）は、埋め込みボタン属性に関与す
るために、幾つかの簡単なやり方で修正されることが必
要である。特に、それらは次のようなルーチンを持つべ
きである。 ａ．ボタン属性を有するドキュメントにおいて全ての要
素を列挙すること。 ｂ．ある与えられたドキュメント要素のボタン属性（お
よびその他の属性）を記述すること。 ｃ．エディタで特定されるコマンド言語によって付与さ
れたエディット操作コマンドに従ってドキュメントのエ
ディット操作をすること（オプション）。 ｄ．ある与えられたカーソル位置が、ある与えられたド
キュメント要素の内外いずれの側にあるかを報告するこ
と。 これに加えて、改善された実行能力のためには、エディ
タは次のようなルーチンを付加的に具体化することがで
きる。 ｅ．あるドキュメント要素についての任意のデータ構造
に対してポインタを関連させること。 また、ボタンの中には次のようなことをエディタに求め
るものもある。 ｆ．ボタンの内容をテキストストリングとして記述する
こと。 この最後に述べた特徴は、ボタンがテキストドキュメン
トに埋め込まれているときには、最も意味のあるもので
ある。

【００４８】最後に、“ボタンモード”にあるときに
は、任意の与えられた時点においてカーソルの下にある
ドキュメント要素がボタン属性を有しているか否かの決
定がなされるまで、エディタは選択アクションの処理
（例えば、マウスによりまたはカーソルキーを用いるこ
とにより指示すること）を遅らせることができねばなら
ない。このような属性が見出されたときには、エディタ
はエディット操作アクションを行わない。これに代え
て、マウスボタンが押されており、ユーザが埋め込みボ
タンを指示しているという情報を、埋め込みボタンカー
ネルに対して渡すようにされる。これに対して、このよ
うな属性が存在しないときにエディタで実行されること
は、マウスボタンが与えられたドキュメント要素上で押
されているときに、正常に実行される任意のエディット
操作アクションである。

【００４９】好都合なことに、これらの特徴は一般的に
はその実施が容易なものである。マウスに基づく全ての
ドキュメントエディタには、ユーザが指示するドキュメ
ント要素を決定するためのコードが既に含まれている。
更に、大方のこのようなエディタが有しているコード
は、各入力イベントを扱うのに適当なルーチンに対して
伝えるためのものであり、また、全てのＷＹＳＩＷＹＧ
(What You See Is WhatYou Get) エディタが有してい
るコードは、ドキュメント要素の属性をアクセスするた
めのものである。従って、ボタン属性が存在するか否か
を決定するための、適当なときに埋め込みボタンカーネ
ルに対して伝えるための、これらの属性を修正するため
の、そして、特定の属性を有するドキュメント要素をサ
ーチするためのコードを含ませるように、それらは容易
に拡張される。

【００５０】３．埋め込みボタンカーネル 埋め込みボタンカーネルにより、次の２タイプのルーチ
ンが提供される。 （１） 新規なコマンドハンドラ、ボタンクラスおよび
アプリケーションウインドウがシステムに知覚されるこ
とを許容するための登録手順。 （２） ユーザおよびソフトウエアルーチンによるボタ
ンの使用に寄与するアクションルーチン。 それらのタイプの各々の基礎的なルーチンについては、
このセクションにおいて記述される。

【００５１】ａ．登録手順 メッセージハンドラは、カーネルルーチンを呼ぶことに
より、埋め込みボタンカーネルをもって好適に自己登録
される。 RegisterMessageHandler: PROCEDURE [name: String, n
otifyProc:RegisteredNotify:Proc]; ここに、“String”はＡＳＣＩＩのテキストストリング
であり、また、“RegisteredNotifyProc”は手順のタイ
プである。 RegisteredNotifyProc: TYPE = PROCEDURE [action: St
ring, button Button] RETURNS[success: BOOLEAN]

【００５２】この“RegisteredNotifyProc”における
“ｂｕｔｔｏｎ”で記述していることは、アクションを
トリガするために押された埋め込みボタン、および、ブ
ール代数値（ＢＯＯＬＥＡＮ）が真／偽の値であること
である。この結果として、登録名を有するコマンドハン
ドラに対してアクションが伝えられるべきことを要求す
るボタン属性をカーネルが読み取ったときには、該カー
ネルは関連のRegisteredNotifyProcを呼び、これによっ
て、該当のアクションリクエストを、パラメータとして
コマンドハンドラに渡す。

【００５３】ボタンクラスは、カーネルルーチンを呼ぶ
ことにより、埋め込みボタンカーネルをもって自己登録
される。 Register ButtonClass: PROCEDURE [button Class Nam
e: String,buttonClass:ButtonClass]; ここに、ＢｕｔｔｏｎＣｌａｓｓによって、次のような
手順を実行するためのルーチンが提供される。 （１） 例示する。そのボタン属性から、ある特定され
たクラスの与えられたボタンに対するランタイムのデー
タ構造を生成させる。 （２） ファイルアウトする。ボタンのホストドキュメ
ントがディスクに書き込まれたときには、そのランタイ
ムのデータ構造から、該与えられたボタンに対して修正
されたボタン属性（例えば、生成されてからのその値を
変更したときのような）を生成させる。 （３） トリガ操作を扱う。与えられたボタンをトリガ
操作するアクションに応答する。このルーチンで決定さ
れることは、フィードバックが実行されるべき事項、お
よび、コマンドハンドラが告知されるべき時点である。 （４） 値を取得する。カーネルからの質問があったと
きに、与えられたボタンの現在の値を報告する。 （５） 値をセットする。ある与えられたボタンの値を
変更するための要求に応答する。例えば、それらのラン
タイムのデータ構造を変更することにより、および、適
当な人的に可視のフィードバックを生成させることによ
り、ボタンにおける応答が可能である。 （６） 態様を履行しない。そのための特定のコマンド
ハンドラがないときには、該与えられたボタンが呈示す
べき態様の実行をする。例えば、コマンドハンドラが特
定されていないときには、状態を有するボタンが次に続
く状態へと変化することが多い。

【００５４】ある特定のドキュメントをある特定のアプ
リケーションウインドウにリンクさせることがアプリケ
ーションで所望されるときには、次のような呼びがなさ
れる。 LinkDocToApplication: PROCEDURE [doc: ActiveDoc, h
andlerName:String, window: Window, applicationDat
a: POINTER, notifyProc:NotifyProc]; ここに、“ＡｃｔｉｖｅＤｏｃ”で表されることは、ボ
タンを含んでいるリンクされるべきドキュメントの仮想
メモリアドレスである。上記のルーチンが一旦呼ばれる
と、カーネルはこれに続けて“ＡｃｔｉｖｅＤｏｃ”に
おける任意のボタンに対するトリガ操作をすることが可
能にされる。この“ＡｃｔｉｖｅＤｏｃ”のコマンドハ
ンドラフィールドには同じ“ｈａｎｄｌｅｒＮａｍｅ”
が含まれており、“ｎｏｔｉｆｙＰｒｏｃ”を呼ぶこと
により、そして、アーギュメントである“ｗｉｎｄｏ
ｗ”および“ａｐｐｌｉｃａｔｉｏｎＤａｔａ”にそれ
を渡して、ボタンのアクションを実行するようにされ
る。当該イベントにおいて、“ｗｉｎｄｏｗ”に記述さ
れている特定アプリケーションウインドウの内容は、与
えられたボタンをトリガすることによって影響されるべ
きものであり、また、“ａｐｐｌｉｃａｔｉｏｎＤａｔ
ａ”は、意図されるボタンアクションを実行するために
アプリケーションで要求される、任意の他の情報に対す
るポインタである。この目的のために、“ｎｏｔｉｆｙ
Ｐｒｏｃ”は次のようなタイプの手順にされている。 NotifyProc: TYPE = PROCEDURE [button: Button, acti
on: String,window: Window, applicationData: POINTE
R] RETURNS [success:BOOLEAN];

【００５５】ボタンクラスによって用いられるこの“ｎ
ｏｔｉｆｙＰｒｏｃ”のサクセスリターン値は、（ボタ
ンアクションが完了したことの、ユーザに可視のフィー
ドバックを提供するときに）要求されたアクションの成
否のいかんをユーザに指示するかどうかの決定をするた
めのものである。

【００５６】ｂ．アクションルーチン ボタンを含んでいるドキュメントを管理するエディタに
よって、ドキュメントをコントロールパネルとして用い
るアプリケーションプログラムによって、そして、この
ようなエディタおよびアプリケーションプログラムによ
ってなされるカーネルを支援するためのボタンクラスに
よって、カーネルのアクションルーチンが呼ばれる。特
に、カーネルによって提供される３個のルーチン（即
ち、HandlePress, DataStructureFromAttribute, Attri
buteFromDataStructure)は、ボタンを含んでいるドキュ
メントのエディタによって呼ばれるものである。更に、
カーネルによって提供される２個の基礎的なルーチン
（即ち、GetValue, SetValue）は、アプリケーションに
よって呼ばれるものである。最後に、カーネルによって
提供される６個の基礎的なルーチン（即ち、PassEventT
oCommandHandler, GetField, SetField, GetAttribute,
SetAttribute, RegisterNameValuePair）は、ボタンク
ラスによって呼ばれるものである。これらのルーチンお
よびその機能については、このセクションにおいて規定
されている。

【００５７】１．エディタによって呼ばれるアクション
ルーチン HandlePress: PROCEDURE [press: InputAction, butto
n: Button, doc:ActiveDoc]; なる更に基礎的なルーチンは、埋め込みボタンアーキテ
クチュアにおけるものの中の一つである。（マウスボタ
ンをクリックすること、キーボードキーを押すこと、ま
たは、所定の他の手段により）ユーザがボタン上でカー
ソルを動かして、該ボタンをトリガさせたことが発見さ
れたときには、このルーチンがエディタによって呼ばれ
る。“ｐｒｅｓｓ”なるアーギュメントは、ボタンをト
リガするためにユーザによって用いられる方法を表すも
のである。ある種のボタン（例えば、ポップアップボタ
ン）は、それをトリガするために押される１個または複
数個のキーに依存して、異なる態様を呈示するものであ
り、そのための情報が“ｐｒｅｓｓ”なるアーギュメン
トに含まれている。“ｂｕｔｔｏｎ”なるアーギュメン
トはいずれのボタンがトリガされるかを記述するもので
あり、また、“ｄｏｃ”なるアーギュメントはこのボタ
ンが配置されるドキュメントを記述するものである。
“ＨａｎｄｌｅＣｌｉｃｋ”が呼ばれると、ボタン属性
がカーネルで分析されて、どのボタンクラスがこのクリ
ックを扱うべきかが発見され、そして、更に続く処理の
ために該当のボタンクラスに対してアクションが渡され
る。

【００５８】エディタが呼ぶことのできる他のルーチン
は次の通りである。 DataStructureFromAttribute: PROCEDURE [attribute:
String,button: Button, doc: ActiveDoc] RETURNS [da
taStructure:POINTER]; ＨａｎｄｌｅＰｒｅｓｓルーチンを成功させるために
は、カーネルはボタン属性を分析せねばならない。ボタ
ンがトリガされる度にこの分析をすることができるけれ
ども、これは実行能力に悪い影響をおよぼすことがあ
る。代替的に、ドキュメントがロードされた時点におい
て、各ボタンに対して一度だけ、エディタは DataStruc
tureFromAttribute ルーチンを呼ぶことができる。この
ルーチンによれば、ボタン属性が分析され、ボタンを表
すためのデータ構造が構築され、そして、このデータ構
造がエディタに戻される。そして、ボタン属性のランタ
イム値としてのボタン属性ストリングに代るデータ構造
を、エディタが蓄積することができる。注：特別の強化
策として、始めてボタンが押されたときに分析をするこ
とが可能であり、このために、ドキュメントが全てのボ
タンに対してロードされる時点においてコストを支払う
必要がなくなる。このスキームによれば、使用されるボ
タンに対してのみ、コストが支払われることになる。

【００５９】ドキュメントがディスクに書き込まれねば
ならないときには、次の AttributeFromDataStructure
ルーチンを用いて、ボタン属性のデータ構造をストリン
グに戻すことができる。 AttributeFromDataStructure: PROCEDURE [dataStructu
re:POINTER] RETURNS [attribute: String]; ここで認められるように、このルーチンは上述された D
ataStructureFromAttribute ルーチンによって生成され
た形式のデータ構造をとるものであって、それを人によ
る読み取りが可能なＰｏｐｐｙ言語のテキストストリン
グに戻すようにされる。ドキュメントがディスクに書き
込まれているときに、エディタがこのルーチンに呼びを
出して、それらがテキストストリングとしてのボタン属
性を外部に表すことができるようにされる。ある特定の
ボタンに対して注意されることは、このルーチンによっ
て戻されるテキストストリングは、アーギュメントとし
ての DataStructureFromAttribute に渡されるテキスト
ストリングとは等しくない可能性があるということであ
る。例えば、ボタンがマルチ状態ボタンであるときに
は、その値がＴＲＵＥからＦＡＬＳＥへと変化できるよ
うにされて、この新規な状態が修正されたボタン属性の
ストリングに反映されることになる。

【００６０】２．アプリケーションによって呼ばれるア
クションルーチン GetValue: PROCEDURE [name: String, doc: ActiveDoc]
RETURNS[value: String] なるルーチンは、そのボタン属性の“Ｎａｍｅ：”フィ
ールドにおける与えられたテキストストリング“ｎａｍ
ｅ”を有するドキュメント“ｄｏｃ”の、１個または複
数個のボタンに現れるときのＶａｌｕｅなる名称の変数
の値を戻すものである。幾つかのボタンがこの名称をも
ってこのドキュメント内に存在するときには、このルー
チンによって、第１に遭遇したこのようなボタンの値が
戻される。その実行能力を改善するために、ＧｅｔＶａ
ｌｕｅルーチンにおいて、“ｎａｍｅ”がハッシュテー
ブル内の RegisterNameValuePair（下記を参照）によっ
て登録されているかどうかを認めるためのチェックがな
される。もしそうであるときには、関連の値が極めて迅
速に見出されて、それを戻すようにされる。そうでない
ときには、Ｓｅｃｔｉｏｎ Ｄ．２．ルーチンにおいて
記述された EnumerateButtons ルーチンの助けをもっ
て、ドキュメント内の全てのボタンを通してその名称を
求めるサーチがなされ、該当の名称が見出されたときに
は値を戻すようにされる。このような名称のあるボタン
が見出されなかったときには、空きのストリングを戻す
ようにされる。

【００６１】SetValue: PROCEDURE [name: String, val
ue: String, doc: ActiveDoc]; この手順においては、与えられた名称を有するドキュメ
ント“ｄｏｃ”内の全てのボタンにおける変数 Ｖａｌ
ｕｅの値が変更される。RegisterNameValuePair（下記
を参照）に対するボタン名、値およびｄｏｃ（ドキュメ
ント）も渡されて、ＧｅｔＶａｌｕｅに対する将来の呼
びにより、正しい値を迅速に生成するようにされる。

【００６２】３．ボタンクラスによって呼ばれるアクシ
ョンルーチン PassEventToCommandHandler: PROCEDURE [event: Strin
g, button:Button, application: String]; はボタンクラスによって呼ばれて、“ｅｖｅｎｔ”と呼
ばれるテキストストリングを名称が付されたボタンのコ
マンドハンドラに渡す時点であることを、カーネルに対
して告知するようにされる。ボタンと、登録されたコマ
ンドハンドラおよびリンクしたドキュメント（上述の L
inkDocToWindow ルーチンを参照）についてのカーネル
における現在のテーブルとから、該当のコマンドハンド
ラに告知するために呼ぶ手順がカーネルにより決定され
て、該イベントを該当の手順に対して渡され、最終的に
は戻すようにされる。

【００６３】GetField: PROCEDURE [fieldName: Strin
g, button: Button]RETURNS [field: String]; なるルーチンは、ある与えられたボタンについてのボタ
ン属性のある特定のフィールドの値を戻すためのもので
ある。例えば、GetField ["CommandHandler"が、上述さ
れたＣｏｌｏｒｉｚｅｒアプリケーションに対するマル
チ状態ボタンに適用されたときには、該当のストリング
“Ｃｏｌｏｒｉｚｅｒ”を戻すようにされる。

【００６４】SetField: PROC [fieldName: String, fie
ld: String, button: Button]; なる手順は、ボタン属性の特定のフィールドに対して新
規な値を割り当てるためのものである。変更されたフィ
ールド上での後続のＧｅｔＦｉｅｌｄ操作によって、新
規な値を戻すようにされる。

【００６５】GetAttribute: PROC [key: String, butto
n: Button] RETURNS [pointer:POINTER]; ボタン属性（キーを“ＢｕｔｔｏｎＡｔｔｒｉｂｕｔ
ｅ”とすることで同定される）は、埋め込みボタンアー
キテクチュアに必須であるドキュメント要素の属性だけ
であるが、ある所定のボタンクラスにおいては、他の属
性の値を取得することが所望される。例えば、ここで説
明されるＢｕｔｔｏｎｉｚｅｒボタンでは、第２の属性
（キーを“ＢｕｔｔｏｎＡｔｔｒｉｂｕｔｅＬｉｔｅｒ
ａｌ”とすることで同定される）が用いられる。このＧ
ｅｔＡｔｔｒｉｂｕｔｅの手順においては、これらの属
性の全てがボタンクラスに対して有用にされる。このル
ーチンでは、任意のデータ構造に対してポインタが戻さ
れる。このために、ボタンクラスにおいては、このデー
タ構造がテキストストリングであるか、または、その利
用のためのある種の他のデータ構造であるかを知らねば
ならない。

【００６６】SetAttribute: PROCEDURE [key: String,
pointer: POINTER, button:Button, edited: BOOLEAN]; によれば、“ｂｕｔｔｏｎ”アーギュメントによって記
述されたドキュメント要素についての任意の属性の変更
が、ボタンクラスに対して許容される。

【００６７】RegisterNameValuePair: PROC [name: Str
ing, value: String, doc:ActiveDoc]; なるルーチンは、“ｎａｍｅ”をキーとして用いて、ハ
ッシュテーブルにおける対（名称、値）を蓄積するため
のものである。ここで想起されるように、ＧｅｔＶａｌ
ｕｅルーチンではこのテーブルが用いられ、それらの名
称が付されたボタンの値が迅速に見出されて、それらの
名称および値をこのテーブルに蓄積するようにされる。

【００６８】４．ボタンクラス セクションＣ．２において上述されたように、ボタンを
含んでいるドキュメントについてのユーザの観点から、
少なくとも３個の異なるボタンクラスが支持されるが、
これらのクラスで提供される３個の基礎的なビルディン
グブロックは、ドキュメントから作成されるインタフェ
ースのためのものである。また、セクションＤ．３．ａ
において記述されているように、ボタンクラスのセット
は、登録手順を呼ぶことにより（ランタイムにおいてさ
えも）拡張することができる。更に想起されることは、
これもセクションＤ．３．ａにおいて記述されているよ
うに、各ボタンクラスが６個の手順によって規定され
る。これに加えて、ある与えられたボタンクラスにおけ
るボタンは、その活動性を支持するボタン属性内におい
て異なるフィールドを有している。このセクションに
は、上述された３個のボタンクラス全てについてのボタ
ン属性の例が含まれており、また、各クラスでのその６
個のルーチンの実施のやり方が説明されている。

【００６９】ａ．ポップアップボタン （ユーザがそれらをトリガする態様に依存して）ポップ
アップボタンがトリガされたときには、それらによるポ
ップアップメニューのディスプレイが可能にされ、そし
て、ユーザが選択するメニューアイテムに基づくアクシ
ョンを実行するようにされる。例えば、図２Ｃにおける
ような、ボタン自体についてテキスト内で名称が付され
ているファイルをオープンする、ポップアップボタンに
対するボタン属性（このボタン属性は、このアクション
を意味のあるものにするためのテキストドキュメント要
素と関連していなければならない）は、次の通りであ
る。 Poppy1 Class: PopUpButton Menu: ( ((＜Contact "Open" ＜ButtonText＞＞) "Open""Opens the file represented by this button") ) CommandHandler: CommandTool Feedback: ( (Mouse Moved ＜SetCursor bullseye＞) )

【００７０】ＰｏｐＵｐＢｕｔｔｏｎのクラスでは“Ｍ
ｅｎｕ”なるフィールドが必要とされる。Ｃｌａｓｓ，
ＣｏｍｍａｎｄＨａｎｄｌｅｒ，Ｆｅｅｄｂａｃｋなる
フィールドは、全てのボタンに対する埋め込みボタンカ
ーネルによって支持される。

【００７１】ポップアップボタンのクラスに対する６個
の基礎的なルーチンは次のように実施される。 例示。このルーチンでは、Ｍｅｎｕフィールドを読み取
って、ポップアップメニューのグラフィックな外見を表
すデータ構造を生成する。ファイルアウト。このボタン
属性は値を有していないから、その使用の間に変化を生
じることはない。このファイルアウトルーチンでは、オ
リジナルなボタン属性を返すだけである。 ボタンプレス。まず、埋め込みボタンカーネル１２（図
１）は、押されているボタンとＦｅｅｄｂａｃｋフィー
ルドにおいて関連する、任意のフィードバックを実行す
るように要求される。次に、（ディスプレイを保証する
のに十分なだけ、ユーザがマウスボタンを押えていると
きには）ポップアップメニューがユーザのディスプレイ
スクリーン上で描かれ、これに次いで、ユーザによるメ
ニューの選択が許容される。ユーザがある選択をしたと
きには、この選択の評価がなされる。例えば、上記の例
において＜Ｃｏｎｔａｃｔ“Ｏｐｅｎ”＜Ｂｕｔｔｏｎ
Ｔｅｘｔ＞＞なる表現が評価されると、これにより、ボ
タンのテキストにおいて挙げられたファイル名が見出さ
れて、“Ｏｐｅｎ”なるストリングがそれに対するもの
のようにされる。例えば、ボタンが“〜／ｗｒｉｔｉｎ
ｇｓ／ｄｉａｒｙ”なるテキストストリングであったと
きには、その連続として、“Ｏｐｅｎ〜／ｗｒｉｔｉｎ
ｇｓ／ｄｉａｒｙ”なるストリングが生成されることに
なる。最後に、カーネル１２はこのストリングをコマン
ドハンドラ（この例では“ＣｏｍｍａｎｄＴｏｏｌ”）
に渡す。次いで、コマンドハンドラ１４はそのアクショ
ンを実行する（例えば、該当の名称が付されたファイル
をスクリーン上にディスプレイさせる）。最後に、カー
ネル１２は、エディタに求めて、ボタンコマンドが終了
したことを示すために付与されるような任意のフィード
バックを実行させる。 値取得(Get Value) 。値がないために、この手順では何
もされない。 値セット(Set Value) 。値がないために、この手順では
何もされない。 不履行の態様(Default Behavior)。コマンドハンドラが
ないときには、ポップアップボタンはユーザによる読み
取りのためにそれらのコマンドをスクリーン上にディス
プレイさせるだけである。このクラスのボタンをデバッ
グするためには、これは有用なことである。

【００７２】ｂ．マルチ状態ボタン 図５Ｂに例示されているマルチ状態のテキストボタン
は、ＴＲＵＥまたはＦＡＬＳＥなる値をもつことができ
る。その値がＴＲＵＥであるときには、そのテキストの
外見はブラック上のホワイト（白抜き文字のこと）であ
る。これに対して、ＦＡＬＳＥであるときには、そのテ
キストの外見はホワイト上のブラックである。そのボタ
ン属性は次の通りである。 Poppy1 Class: MultiStateButton Name: GridOn Variables: (Value: BOOL = TRUE) UpClickMessage: (Toggle Grid) CommandHandler: Picture Region Feedbask: ( (Down (BeginButton ClearLooks LookItalic End Button)) ((Value TRUE) (BeginButton ClearLooks LooksWhiteOnBlack End Button)) ((Value FALSE) (BeginButton ClearLooks EndButton)) )

【００７３】マルチ状態ボタンで必要とされることは、
“Ｖａｒｉａｂｌｅｓ”フィールドがそれらのボタン属
性に現れること、および、“Ｖａｌｕｅ”と呼ばれる変
数が規定されることである。これに加えて注意されるべ
きことは、上記の例において“ＵｐＣｌｉｃｋＭｅｓｓ
ａｇｅ”と呼ばれるフィールドには、ユーザがこのボタ
ン上でのクリック操作を終了したときにコマンドハンド
ラに対して伝送するメッセージが記述されているという
ことである。“Ｎａｍｅ”なるフィールドは埋め込みボ
タンカーネルによって支持されている。これはカーネル
に対してこのボタンの値を参照するやり方を付与するも
のである。他のフィールドとしてのＣｌａｓｓ，Ｃｏｍ
ｍａｎｄＨａｎｄｌｅｒ，および Ｆｅｅｄｂａｃｋ
は、全てのボタンクラスに対する埋め込みボタンカーネ
ルによって支持されている。

【００７４】このマルチ状態ボタンによれば、次のよう
な６クラスの特定ルーチンが実施される。 例示。このルーチンではＶａｒｉａｂｌｅｓフィールド
の読み取りがなされて、各名称を付された変数とその値
とを表すデータ構造が生成される。これで確実にされる
ことは、Ｖａｌｕｅの現在値に関連するフィードバック
を実行することにより、ボタンが初期的に正しい外見を
有することである。例えば、この例においては、ボタン
によってテキストエディタに伝送されるストリングは
“BeginButton Clearlooks LookWhiteOnBlack EndButto
n ”であるが、これによって（ＣｌｅａｒＬｏｏｋｓコ
マンドの結果として）ボタンのテキストが正常に見える
ようにされる。ただし、（ＬｏｏｋＷｈｉｔｅＯｎＢｌ
ａｃｋの結果として）ブラック上のホワイトにされてい
る。この例におけるＢｅｇｉｎＢｕｔｔｏｎコマンドお
よびＥｎｄＢｕｔｔｏｎコマンドによってテキストエデ
ィタに指示されることは、ドキュメントの他の部分に対
してではなく、このボタンのテキストに対して他のコマ
ンドを適用することである。 ファイルアウト。自体をテキスト的に記述するために、
オリジナルのボタン属性において述べた各変数の名称お
よび現在の値を書き出すことにより、マルチ状態ボタン
はＶａｒｉａｂｌｅｓフィールドのための新規な値を構
築せねばならない。この例における書き出しには、変数
Ｖａｌｕｅの現在の値に依存して、ストリング“ＴＲＵ
Ｅ”または“ＦＡＬＳＥ”が含まれる。ボタン属性の他
のフィールドは変化を生じることはなく、それらが読み
込まれたように書き出されることになる。 ボタンプレス。まず、カーネルが、押されているボタン
とＦｅｅｄｂａｃｋフィールドで関連している任意のフ
ィードバックをすることが要求される。上記の例におい
て、“Ｄｏｗｎ”で始まるフィードバックラインで特定
されることは、ユーザがその上でクリックダウンしてい
るときに、ボタンがイタリックでディスプレイされるべ
きということである。ユーザがマウスボタンをリリース
したとき（または、選択がなされている旨の他の指示が
なされたとき）には、“Ｔｏｇｇｌｅ Ｇｒｉｄ”なる
メッセージがコマンドハンドラに伝送される。この表現
を含む手順が（ポップアップボタンの例における＜Ｂｕ
ｔｔｏｎ Ｔｅｘｔ＞または＜Ｃｏｎｔａｃｔ＞のよう
な）呼びを出すときには、このような手順はこの時点に
おいて呼ばれることになる。 値取得。このルーチンでは、変数Ｖａｌｕｅの値が戻さ
れる。 値セット。ここでは変数Ｖａｌｕｅに対する新規な値が
指定されて、この新規な値に関連するフィードバックが
実行される。例えば、先の例においてＶａｌｕｅがＦＡ
ＬＳＥにセットされたときには、エディット命令“Ｂｅ
ｇｉｎＢｕｔｔｏｎ ＣｌｅａｒＬｏｏｋｓ ＥｎｄＢ
ｕｔｔｏｎ”がテキストエディタに伝送され、これによ
って、ボタンがホワイト上でブラックのテキストになる
ようにされる。 不履行の態様。コマンドハンドラがなく、ユーザがこの
ボタンの選択を完了するときには、ＵｐＣｌｉｃｋＭｅ
ｓｓａｇｅフィールドが無視される。これに代えて、Ｖ
ａｌｕｅが次に可能性のある値までサイクルされる。例
えば我々の例においては、各クリックによって、この値
がＴＲＵＥからＦＡＬＳＥに、または、ＦＡＬＳＥから
ＴＲＵＥに変化する。

【００７５】ｃ．ラジオボタン 図７Ａおよび図７Ｂに例示されている一対のラジオボタ
ンは、グラフィックエディタに埋め込むことができるも
のである。ここで認められるように、円形（図７Ｂ）は
方形（図７Ａ）よりもボールドにされていて、円形ボタ
ンは“オン”であり、これに対して方形ボタンは“オ
フ”であることが示されている。これら２個のボタンに
対する方形ボタン属性はほぼ同等のものである。これを
より詳細にいえば、方形ボタンに対する属性は次の通り
である。 Poppy1 Class: RadioButton CommandHandler: DrawShapes Name: Shape RadioButtonValue：Ｒｅｃｔａｎｇｌｅ Variables: (State: BOOL ＝ＦＡＬＳＥ） UpClickMessage: (RectangleMode) Feedback: ( ((State TRUE) ((BeginButton) (LineWidth 5.0) (DashesOff) (End Button))) ((State FALSE) ((BeginButton) (LineWidth 2.0) (DashesOff) (End Button))) (Down ((BeginButton) (Dashed) (End Button))) (UP ((BeginButton) (DashesOff) (EndButton))

【００７６】円形ボタンに対するボタン属性において
は、上記の例におけるボールドのワードである“Ｒｅｃ
ｔａｎｇｌｅ”は“Ｃｉｒｃｌｅ”で置換され、また、
ボールドのワードである“ＦＡＬＳＥ”は“ＴＲＵＥ”
で置換されることになる。

【００７７】ここで認められるように、ＲａｄｉｏＢｕ
ｔｔｏｎのクラスで支持されるフィールドは、Ｒａｄｉ
ｏＢｕｔｔｏｎ Ｖａｌｕｅ，Ｖａｒｉａｂｌｅｓ，お
よびＵｐｃｌｉｃｋＭｅｓｓａｇｅである。Ｒａｄｉｏ
Ｂｕｔｔｏｎ Ｖａｌｕｅのフィールドで記述されてい
る変数Ｖａｌｕｅの一つの可能性がある値は、そのボタ
ン属性では明白には述べられていないけれども、同じ名
称を有する全てのラジオボタンによって実質的に規定さ
れている。例えば先の例においては、Ｖａｌｕｅは｛Ｒ
ｅｃｔａｎｇｌｅ，Ｃｉｒｃｌｅ｝のセットを取り込む
ことができる。これに対して、Ｖａｒｉａｂｌｅｓおよ
びＵｐＣｌｉｃｋＭｅｓｓａｇｅの有する機能は、マル
チ状態ボタンに対するそれらの機能と類似のものであ
る。しかしながら、ラジオボタンに対しては、変数Ｓｔ
ａｔｅが規定されねばならず、また、ＢＯＯＬＥＡＮ
（ＴＲＵＥ／ＦＡＬＳＥ）の値でなければならない。更
に、このＳｔａｔｅの値は、ラジオボタンのセットの中
の一つのボタンだけに対してＴＲＵＥであることができ
る。一グループ内の全てのラジオボタンは同じＮａｍｅ
フィールドを有している。他のフィールドであるＣｌａ
ｓｓ，ＣｏｍｍａｎｄＨａｎｄｌｅｒ，Ｎａｍｅ，およ
びＦｅｅｄｂａｃｋは、全てのボタンクラスに対する埋
め込みボタンカーネルによって支持されている。

【００７８】ラジオボタンにおいては、６クラスの手順
が次のように実施される。 例示。このルーチンでは Ｖａｒｉａｂｌｅｓフィール
ドの読み取りがなされて、各名称を付された変数および
その値を表すデータ構造が生成される。ここで保証され
ることは、Ｓｔａｔｅの現在値に関連したフィードバッ
クを実行することにより、ボタンが初期的には正しい外
見を有していることである。例えば上記の例において、
方形のボタンは、グラフィックスエディタに対して、エ
ディタで解読可能なストリング“（ＢｅｇｉｎＢｕｔｔ
ｏｎ）（Ｌｉｎｅ Ｗｉｄｔｈ２．０）（Ｄａｓｈｅｓ
Ｏｆｆ）（ＥｎｄＢｕｔｔｏｎ）”を伝送するが、これ
により方形が肉細にされ、アンダッシュにされる。同様
にして、円形のボタンは、エディタに対して解読可能な
ストリング“（ＢｅｇｉｎＢｕｔｔｏｎ）（Ｌｉｎｅ
Ｗｉｄｔｈ ５．０）（ＤａｓｈｅｓＯｆｆ）（Ｅｎｄ
Ｂｕｔｔｏｎ）”を伝送するが、これにより、エディタ
をして、ボールドにされ、アンダッシュにされた円形を
ディスプレイさせる。 ファイルアウト。マルチ状態ボタンと全く同様に、ラジ
オボタンでは、そのＶａｒｉａｂｌｅｓフィールドを表
すための新規なストリングを生成させねばならない。他
のフィールドは変化することがなく、読み込まれたと同
じストリングが書き出されることになる。 ボタンプレス。先の場合と同様に、まず、カーネルが、
押されているボタンとＦｅｅｄｂａｃｋフィールドで関
連している任意のフィードバックをすることが要求され
る。上記の例において、“Ｄｏｗｎ”で始まるフィード
バックラインで特定されることは、ユーザがその上でク
リックダウンしているときに、選択されたボタンがダッ
シュ形状にされるべきということである。ユーザがマウ
スボタンをリリースしたとき（または、選択がなされて
いる旨の他の指示がなされたとき）には、“Ｒｅｃｔａ
ｎｇｌｅＭｏｄｅ”なるメッセージがコマンドハンドラ
に伝送される。この表現を含む手順が（ポップアップボ
タンの例における＜Ｂｕｔｔｏｎ Ｔｅｘｔ＞または＜
Ｃｏｎｔａｃｔ＞のような）呼びを出すときには、この
ような手順はこの時点において呼ばれることになる。 値取得。ラジオボタンに対するＧｅｔ Ｖａｌｕｅルー
チンが関係している。ラジオボタンに関連したグループ
の値は、そのＳｔａｔｅ変数がＴＲＵＥであるグループ
の一つのボタンについてのＲａｄｉｏＢｕｔｔｏｎＶａ
ｌｕｅの値である。このために、上記の例においては、
Ｇｅｔ Ｖａｌｕｅは“Ｃｉｒｃｌｅ”に戻ることにな
る。 値セット。Ｓｅｔ Ｖａｌｕｅも関係のあるものであ
る。特定されたＶａｌｕｅは、グループにおけるボタン
の一つのＲａｄｉｏＢｕｔｔｏｎＶａｌｕｅフィールド
の値でなければならない。このボタンのＳｔａｔｅ変数
はＴＲＵＥにセットされ、また、グループにおける全て
の他のボタンのＳｔａｔｅ変数はＦＡＬＳＥにセットさ
れる。各変数では、その新規な状態に対して適切なフィ
ードバックが実行される（状態の変化がなかったボタン
は、いかなるフィードバックアクションでも実行する必
要はない）。 不履行の態様。コマンドハンドラがなく、ユーザがこの
ボタンの選択を完了するときには、ＵｐＣｌｉｃｋＭｅ
ｓｓａｇｅフィールドが無視される。これに代えて、選
択されたボタンのＳｔａｔｅ値がＴＲＵＥにセットさ
れ、そのグループにおける、Ｓｔａｔｅ変数を有する全
ての他のボタンはＦＡＬＳＥにセットされる。Ｓｅｔ
Ｖａｌｕｅのルーチンについて説明されたように、フィ
ードバックの実行がなされる。

【００７９】５．コマンドハンドラ ボタンのトリガがなされたときには、ある所定の機能を
果たすために、コマンドハンドラアプリケーション１４
（図１）に対してコマンドが伝送される。各ボタンで記
述されることは、コマンドの一部として該当のハンドラ
の名称を付することにより、または、ボタン属性の“Ｃ
ｏｍｍａｎｄＨａｎｄｌｅｒ”フィールドにおいて、い
ずれのコマンドハンドラ１４が各コマンドを受け入れる
かということである。実際に、それらの名称をＣｏｍｍ
ａｎｄＨａｎｄｌｅｒフィールドにおいてリストにする
ことにより、幾つかのコマンドハンドラに対してコマン
ドを伝送することができる。

【００８０】新規なコマンドハンドラは、ソフトウエア
システム（ｏｎ−ｔｈｅ−ｆｌｙ．１（？））に付加す
ることができる。埋め込みボタンカーネル１２（図１）
をもってコマンドハンドラ名およびコールバックの手順
を登録するために、いずれのプログラムであっても、Ｒ
ｅｇｉｓｔｅｒＣｏｍｍａｎｄＨａｎｄｌｅｒの手順を
呼ぶことができる。この後で、カーネル１２は、その登
録されたコールバックの手順を呼ぶことにより、登録さ
れたコマンドハンドラ名に指向される全てのコマンドを
取り扱うようにされる。このコールバックの手順は２個
のアーギュメントを交互に取り込む。即ち、コマンドお
よび押されているボタンについての記述を交互に取り込
む。更に、コマンドが成功したか否かの指示に戻り、こ
れによって、コマンドが失敗したときには、異なるフィ
ードバックをユーザに提供することが許容される。

【００８１】好適なことに、このシステムにはコマンド
ハンドラ１４（これらのハンドラによれば、広範なボタ
ンの態様に対する支持が与えられる）の少なくとも以下
のような基礎的セットが含まれている。

【００８２】ａ．ＣｏｍｍａｎｄＴｏｏｌコマンドハン
ドラ ユーザによって例えばＣｅｄａｒコマンドシェルでタイ
プされたものであっても、ＣｏｍｍａｎｄＴｏｏｌコマ
ンドハンドラはそのコマンドアーギュメントを解読す
る。コマンドシェルからの任意の出力が全ての埋め込み
ボタンによって共有される特定のタイプスクリプトに書
かれることから、このＣｅｄａｒコマンドシェルは、Ｕ
ＮＩＸにおけるコマンドシェルと酷似した作業をするも
のである。

【００８３】ｂ．Ｂｕｔｔｏｎｉｚｅｒコマンドハンド
ラ Ｂｕｔｔｏｎｉｚｅｒコマンドハンドラは、ユーザが選
択したドキュメント要素に対してボタン属性の適用をす
る。これをより詳細にいえば、適用されるボタン属性が
取り出されるのは、いわゆるＢｕｔｔｏｎｉｚｅｒボタ
ンの“ＢｕｔｔｏｎＡｔｔｒｉｂｕｔｅＬｉｔｅｒａ
ｌ”と呼ばれる、ある特定の他では使用されない属性で
ある。ここで認められるように、双方の態様がＢｕｔｔ
ｏｎｉｚｅｒボタンの属性をエディット操作することに
よって変更できるために、Ｂｕｔｔｏｎｉｚｅｒボタン
自体の態様をエディット操作することに関して、このア
プローチは、Ｂｕｔｔｏｎｉｚｅｒボタンのようなもの
の使用を通して生成されるボタンについてのボタン属性
の変更が極めて容易にされる。例えば、ここに示された
Ｂｕｔｔｏｎｉｚｅｒボタンの属性は、ポップアップボ
タンを生成させるためのものである。 ButtonAttribute: Poppy1 Class: PopUpButton Menu: ( ((Selected) "Buttonize""Applies the ButtonAttributeLiteral property of this button to the selected text") ) CommandHandler: Buttonizer ButtonAttributeLiteral: Poppy1 Class: PopUpButton Menu: ( ((Event1)"FirstItem""Sends Event1 to application") ((Event2)"SecondItem""Sends Event2 to application") ) CommandHandler: Meesage Window

【００８４】ＢｕｔｔｏｎＡｔｔｒｉｂｕｔｅ属性によ
れば、このボタン自体の態様が記述される。これに対し
て、ＢｕｔｔｏｎＡｔｔｒｉｂｕｔｅＬｉｔｅｒａｌ属
性によれば、新規に生成されたボタンのＢｕｔｔｏｎＡ
ｔｔｒｉｂｕｔｅになるようにされる。従って、この特
定の場合においては、この新規のボタンは２個の要素を
備えたポップアップメニューを有することになる。更
に、このポップアップボタンによれば、そのコマンドが
“Ｍｅｓｓａｇｅ Ｗｉｎｄｏｗ”と呼ばれるコマンド
ハンドラに伝送される。

【００８５】ｃ．メッセージウインドウコマンドハンド
ラ メッセージウインドウコマンドハンドラは、ユーザが読
み取れるように、フィードバックのために保留されてい
るディスプレイスクリーンの特定の領域において、コマ
ンドをプリントアウトするだけのものである。このコマ
ンドハンドラは、新規のボタンをデバッグするためには
特に有用なものである。

【００８６】ｄ．ドキュメントエディタコマンドハンド
ラ ドキュメントエディタコマンドハンドラは、ボタンのコ
マンドストリングを、前述されたＴｉｏｇａエディタの
ような適当なドキュメントエディタに対して伝送する。
このテキストストリングにおけるコマンドが一般的に使
用されるのは、ボタンが現れているドキュメントまたは
現にユーザが選択したドキュメント要素を含んでいるド
キュメントのエディット操作のためであるが、任意のド
キュメントをエディット操作するために用いることがで
きる。ここで認められるように、このコマンドハンドラ
によれば、ドキュメントエディタマクロをトリガするた
めにボタンを用いることが許容される。例えば、そのボ
タン属性を備えたポップアップボタンは次の通りであ
る。 ButtonAttribute: Poppy1 Class: PopUpButton Menu: ( ((ApplyLook Bold)"Bold""Make selected text bold") ((ApplyLook Italics)"Italics""Make selected text italic") CommandHandler: Document Editor このポップアップボタンによれば、ドキュメントエディ
タをして、第１のメニューアイテムが選択されたときに
は、選択されたドキュメントオブジェクトをボールドに
し、または、第２のメニューアイテムが選択されたとき
には、これをイタリック体にする。

【００８７】６．エディタ入力言語 セクションＤ．１における第１の例で示されているボタ
ンに対するボタン属性は、それが能動状態にあるときに
はテキストの外見をボールドに変化させ、それがアイド
ル状態にあるときにはプレーンフェースに戻すためのも
のである。このフォント変化の達成は、コマンドストリ
ング“ＢｅｇｉｎＢｕｔｔｏｎ ＡｐｐｌｙＬｏｏｋ
Ｂｏｌｄ ＥｎｄＢｕｔｔｏｎ”および“ＢｅｇｉｎＢ
ｕｔｔｏｎ ＲｅｍｏｖｅＬｏｏｋ Ｂｏｌｄ Ｅｎｄ
Ｂｕｔｔｏｎ”を、ドキュメントエディタに対して伝送
することによってなされる。同様にして、セクション
Ｄ．５で記述されているボタンによれば、ユーザが選択
したいずれのテキストストリングであっても、エディタ
マクロが実行される。

【００８８】ドキュメントエディタにとっては入力エデ
ィット操作言語を解読できることが絶対に必要というこ
とではないが、この能力があるときには、埋め込みボタ
ンが更に有用になる。このようなエディタが与えられる
と、フィードバックをディスプレイするための、およ
び、ある特定のドキュメントエディタにおけるマクロ操
作を実行するための標準的なドキュメントエディタ操作
を求めるために、ユーザは、ボタン属性のサブストリン
グとしてのドキュメントエディット操作ストリングを含
ませることができる。

【００８９】７．ボタンプレスの取り扱い 図８に例示されている通信経路は、ユーザが埋め込みボ
タンをトリガするときに用いられるものである。これら
の通信経路は次のような幾つかのステップにおいて用い
られる。 ステップ１：告知（特定されたボタンクラス１３に対す
る埋め込みボタンカーネル１２へのエディタ１１） 例えば埋め込みボタン上のマウスボタンをユーザがクリ
ックすると、該埋め込みボタンを含んでいるドキュメン
トを管理するエディタ１１により、埋め込みボタンカー
ネル１２に対して、マウスアクション、ドキュメントに
おける埋め込みボタンの位置の記述、および、そのボタ
ン属性が渡される。カーネル１２の側においてはボタン
属性の“Ｃｌａｓｓ”フィールドが読み取られ、特定さ
れたボタンクラス１３のためのボタンハンドラに対し
て、上記の情報が転送される。 ステップ２：イニシャルフィードバック（エディタ１１
に対する埋め込みボタンカーネル１２への特定されたボ
タンクラス１３） 適切であるときには、ボタンクラス１３は、このマウス
アクションに関連する任意のフィードバックアクション
を実行するように、埋め込みボタンカーネル１２に対し
て要求する。例えば、マウスがそれに入ったときにはボ
タンがその周囲にボックスを描くか、または、マウスが
その上でクリックしたときにはそれ自体をグレイにする
ことができる。カーネル１２はボタンの“Ｆｅｅｄｂａ
ｃｋ”フィールドにおいてマウスアクションを調べ、そ
れで見出された任意のコマンドを、ボタンを管理するた
めのエディタ１１に渡す。 ステップ３：（コマンドハンドラ１４）に対する埋め込
みボタンカーネル１２へのアクション（特定のボタンク
ラス１３）の選択 この時点におけるボタンクラスは、アクションのメニュ
ーをポップアップすることができるか、または、マウス
ボタンが近接してくるのを待つだけである。一旦ユーザ
がこのボタンの実行のためのアクションを選択したとき
には、ある操作が進行中である（ステップ２を参照）こ
とを示すために、ボタンクラス１３は更なるフィードバ
ックを要求することができる。そして、ボタンクラス１
３は、カーネル１２に対して、選択されたアクションの
リストを伝送する。カーネルはボタン属性の“Ｃｏｍｍ
ａｎｄＨａｎｄｌｅｒ”フィールドにおいてその名称を
調べ、当該名称で登録されているコマンドハンドラルー
チン１４に対して、該アクションのリストを渡す。 ステップ４：ファイナルフィードバック（エディタ１１
に対する埋め込みボタンカーネル１２への特定されたボ
タンクラス１３） ボタンによってトリガされたアクションの実行を一旦コ
マンドハンドラ１４が終了すると、ボタンクラス１３
は、ある所定のファイナルフィードバック（例えば、埋
め込みボタンをそのオリジナルの外見に戻すこと）を実
行することを（カーネル１２を介して）エディタ１１に
求める。

【００９０】図８に示されているように、ソフトウエア
システムは、多少は従来に属するコンピュータシステム
２２の仮想メモリ２１内に駐在している。例えば、この
コンピュータシステム２２に好適に含まれているもの
は、メモリコントローラ２５を介して中央処理ユニット
（ＣＰＵ）２４を仮想メモリ２１にリンクさせるため
の、Ｉ／Ｏコントローラ２８を介してキーボード２６お
よびカーソルコントローラ（例えば、マウス）２７にリ
ンクさせるための、そして、ディスプレイコントローラ
３０を介してモニタ２９にリンクさせるためのバス２３
である。しかしながら、ここで理解されるべきことは、
この発明はホストコンピュータ２２のアーキテクチュア
に依存するものではないことから、他のアーキテクチュ
アを有するコンピュータにもこの発明を適用できるとい
うことである。

【００９１】ボタン値の取得およびセット マルチ状態ボタンおよびラジオボタンの双方に、アプリ
ケーションプログラムによって問い合わせができる値が
含まれている。これらのタイプのボタンを取り扱うこと
については、セクションＤ．３．ｂ において説明され
たメカニズムに対する２個の複雑な事態が必要とされ
る。

【００９２】第１に、アプリケーションプログラムにと
っては、これらのボタンの中の一つにおける現在の値を
見出すことが可能であるべきである。これに関連して想
起されることは、埋め込みボタンカーネル１２によっ
て、能動的なドキュメントおよびアーギュメントとして
のボタンを取り込み、該ボタンの値をテキストストリン
グとして戻すようなルーチンＧｅｔＶａｌｕｅが付与さ
れるということである。好都合なことに、アプリケーシ
ョンにおいて能動的なドキュメントをそのコントロール
パネルとして用いているときには、該アプリケーション
はこの能動的なドキュメントに対するポインタを有して
おり、このために、この手順の呼びが素直なものにされ
ている。ここで認められるように、カーネル１２は、こ
のような能動的なドキュメントを、該アプリケーション
に対して名称の付されたコマンドハンドラ１４として、
アプリケーションによってなされたルーチン登録要求に
応答して動的に登録することができる。

【００９３】第２に、ボタンの状態変更は、他のアプリ
ケーションのアクションと同期がとられることを必要と
することがある。現在のカラーの値をセットするために
能動的なドキュメントを用いる、ドローイングプログラ
ムについて考えてみる。ユーザが現在のカラーをブルー
に変更した時点においてアプリケーションが遅れてお
り、第１の形状をディスプレイすることが終了していな
いとしても、ユーザは、カラーをレッドにセットして第
１の形状を描き、カラーをブルーにセットして第２の形
状を描くことが可能であるべきである。混乱を防止する
ために、現在のカラーを変更する１個または複数個のボ
タンは、現在の値を用いるアプリケーションがなされる
まで、報告する値の変更をすべきではない。

【００９４】この同期化を可能にするために、マルチ状
態ボタンおよびラジオボタンは、自動的に状態を変更す
ることはない。これに代えて、これらのボタンは、アプ
リケーションに対して状態変更の要求を伝送する。アプ
リケーションの準備がなされたときには、ルーチンＳｅ
ｔＶａｌｕｅを呼んで、新規な値をボタンにセットする
ようにされる。これにより、入力処理における第５のス
テップへとリードされる。

【００９５】ステップ５：変更された値のフィードバッ
ク（エディタに対する埋め込みボタンカーネルへのアプ
リケーション） アプリケーションがＳｅｔＶａｌｕｅを呼んだときに
は、埋め込みボタンカーネル１２は、実行されるべきフ
ィードバックアクションのために変更される値を有す
る、各ボタンの“Ｆｅｅｄｂａｃｋ”フィールドの中を
みる。ある１個がリストにされているときには、このア
クションが、ボタンを管理するエディタ１１に対して伝
送される。好適なことには、アプリケーションによる名
称を付されたボタンの値に対する要求に迅速に応答する
ために、埋め込みボタンカーネル１２には、ハッシュテ
ーブル（標準的なコンピュータ科学のデータ構造のも
の。ドン・ナス(Don Knuth) のコンピュータプログラミ
ングの技法 (The Art of Computer Programming)，第３
刊を参照）の値が保持されている。ここに、ハッシュテ
ーブルのキーはボタンの可変名称から導出されるもので
あり、また、このテーブルに蓄積されている値はボタン
の現在値である。１個のこのようなハッシュテーブル
は、それぞれの現に能動的なボタンを含むドキュメント
のために保持されているものであり、テーブルに関連し
たドキュメント内の名称が付されたボタンの変数がその
値を変化させる度に、当該テーブルの更新がなされる。

【００９６】８．ドキュメントをアプリケーションウイ
ンドウにリンクさせること 多くのシステムにおいては、ある与えられたアプリケー
ションは幾つかのウインドウにおいて一度にランするこ
とができる。しかしながら、ある与えられたウインドウ
のコントロールパネルにおける操作は、当該ウインドウ
の内容に対して適用するように意図されており、他のい
ずれのウインドウの内容に対して意図されるものではな
い。これに加えて、ウインドウによっては多くのペーン
を有するものがある。更に、ある与えられたコントロー
ルパネルにおける異なるボタンは、異なるペーンに対し
て適用するように意図されている。

【００９７】かくして、ボタンを含んでいるドキュメン
トをコントロールパネルとして一般的に用いるために、
埋め込みボタンカーネル１２によって付与される前述の
ＬｉｎｋＤｏｃＴｏＡｐｐｌｉｃａｔｉｏｎルーチン
は、ある与えられた能動的なドキュメントにおけるＣｏ
ｍｍａｎｄＨａｎｄｌｅｒの名称をあるアプリケーショ
ンウインドウの特定のペーンにリンクさせるべく、アプ
リケーションによって呼ばれることができる。例えば、
メール読み取りプログラムでは、１個のペーンをメッセ
ージヘッダのディスプレイをするために使用し、他方の
ペーンをメッセージ本体のディスプレイをするために使
用することができる。そして、ヘッダに適用されるボタ
ンにおいては、そのボタン属性に“ＣｏｍｍａｎｄＨａ
ｎｄｌｅｒ：Ｈｅａｄｅｒｓ”が蓄積されるが、これに
対して、メッセージ本体に関連したボタンにおいては、
そのボタン属性に“ＣｏｍｍａｎｄＨａｎｄｌｅｒ：Ｂ
ｏｄｉｅｓ”が蓄積される。この場合において、リンク
ルーチンは２回呼ばれることになる。即ち、ある１回は
“Ｈｅａｄｅｒｓ”ボタンのリンクにされ、他の１回は
“Ｂｏｄｉｅｓ”ボタンのリンクにされる。

【００９８】ここで注意されるのは、ボタンそれ自体は
アプリケーションペーンにリンクされないということで
ある。むしろ、それらが参照するＣｏｍｍａｎｄＨａｎ
ｄｌｅｒの名称がリンクされる。これで可能にされるこ
とは、それらが正しいＣｏｍｍａｎｄＨａｎｄｌｅｒの
記述をしているときに、ドキュメントを含む正しいパネ
ルに対して自動的にリンクされるように、ランタイム時
において、コントロールパネルに対して新規なボタンを
付加することである。

【００９９】結論 前述されたところに鑑みて理解されることは、ドキュメ
ントに対してボタンの埋め込みが許容されるシステムに
よれば、次のような能力が付与されるということであ
る。 （１） ドキュメントに埋め込まれているボタンを用い
ることにより、リーダ（ｒｅａｄｅｒｓ）は、ドキュメ
ントそれ自体における能力を用いて、ドキュメント内の
情報に対して作用を施すことができる。この統合作用に
よってユーザが許容されることは、彼等のタスクに集中
できること、および、そうでないときには該ドキュメン
トを“ｏｆｆ ｔｏ ｔｈｅ ｓｉｄｅ”のツールにす
るような、スクリーンスペースの節減をすることであ
る。 （２） 構築されたドキュメントがメールを介して伝送
されるためのシステムがどこに存在するにしても、ボタ
ンもこれと同様にメールを介して伝送することができ
る。そして、ユーザに許容されることは、有用なボタン
を容易に交換すること、および、電子的メールにおいて
受け入れた情報に対して迅速に応答することである。 （３） ユーザは、実在するコントロールパネルの一部
を新規なドキュメントにコピーして、カスタム化された
コントロールパネルを生成させることができる。

【０１００】これに加えて、ここで説明されたボタンア
ーキテクチュアによれば、これらの付加的な利点が付与
される。 （４） それらは通常のドキュメント要素であることか
ら、標準的なドキュメントのエディット操作を通して、
ボタンのエディット操作をすることができる。 （５） ボタンによって実行されるアクションは、ボタ
ンそれ自体の内容または外見と関連させることができ、
このために、ドキュメントエディタで支持される任意の
プロパティと関連させることができる。かくして、それ
ら自体の外見を修正するために、または、同一のドキュ
メントエディタ内の他のオブジェクトに対してそれらの
プロパティを転送するために、該ボタンを用いることが
できる。 （６） ボタンは任意の形状を有することができる。多
くのシステムにおいては、ボタンは方形であるべきもの
とされている。しかしながら、ここで説明されているシ
ステムにおいては、ボタンは随意のドキュメント要素で
あり、また、それらの形状は、それらが埋め込まれるエ
ディタの能力によって制限を受けるだけである。 （７） このようなボタンは、ドキュメント要素上での
付加的なストリング属性として表されるだけのものであ
ることから、ボタンを含むドキュメントは、構築された
ドキュメントを生成させるために実在するソフトウエア
を介して生成させることができる。

【０１０１】この発明について前述された利点は、以下
のように更に詳細にレビューされる。 １． タスクへの集中を維持すること 電子的なドキュメントにおいては、その読み取られる多
くの情報が、ユーザによる即座の使用が意図されている
ものである。例えば、ディレクトリ内でファイルをリス
トにするコマンドをユーザが入力したとすると、このユ
ーザがしばしば所望することは、リスト内のファイルの
あるものについての、読み取り、名称の改正または削除
である。大方の現在のインタフェースにおいては、ユー
ザの注意が、コマンドシェルまたはファイルツールか
ら、リストにされたファイルの一つの上でのエディタウ
インドウをオープンすることへと転換されねばならな
い。しかしながら、それらがある所定のＳｙｍｂｏｌｉ
ｃｓなアプリケーション内にあるように、該当のファイ
ル名がボタンであるときには、これらの操作は、リスト
から注意を転換させることなく、ファイルリスト上で直
接的に実行することができる。

【０１０２】別の例として、ソフトウエアモジュールに
含ませることができるボタンのセットは、各ルーチンの
テキストに近接しているものであって、該当のルーチン
がドキュメント化され、実施され、または呼ばれるとき
の、ルーチンのテスト操作を行い、そのパフォーマンス
のタイミングをとり、または、ハイパーテキストのリン
クをするためのものである。

【０１０３】２．電子メールにおけるボタン 電子メールメッセージの送信者(sender)は、メッセージ
内の情報について受信者(recipients)が操作する助けと
なるボタンを含ませることを所望することができる。例
えば、ソフトウエアのリリース、電話番号またはファイ
ルを記述したメッセージを伝送しているときには、それ
ぞれに、新規なソフトウエアのインストール、電話番号
のダイアル操作またはファイルのオープン操作のため
に、送信者はボタンを含ませることができる。

【０１０４】３．コントロールパネルの再使用 前述されたように、ボタンのセットは、アプリケーショ
ンウインドウにおけるある特定のペーンにリンクするこ
とが可能であって、ボタンを含むパネルがコントロール
パネルとして作用することが許容される。コントロール
パネルがドキュメントであるときには、ドキュメントエ
ディタが使用可能にされて、それらを介してのナビゲー
ション操作、それらの修正操作、コピー操作およびそれ
らの部分の組み合わせ操作をして、特別なタスクのため
にカスタム化したコントロールパネルにされる。

【０１０５】例えば図９Ａに示されているダイアログボ
ックスは、テキストパターンをサーチするためのもので
ある。それはボールドワードＡｐｐｌｅに対
するサーチのためにセットされ、それをイタリックワー
ドＢａｎａｎａで置換するようにされる。図９Ｂにおい
ては、このコントロールパネルはドキュメントにコピー
されている。そのスペースを節減するために、“Ｐａｒ
ａｍｅｔｅｒｓ”と呼ばれる隠しボタンが使用されてお
り、図９Ａに示されたコントロールパネルを閉じ込める
ようにされている。（ある１個の隠しボタンによって、
小規模のドキュメントがその内部に隠される；この隠し
ボタンが押されると、小規模のドキュメントが現れるこ
とになる。）図９Ｂに示されている、Ｓｅａｒｃｈ，Ｙ
ｅｓ，Ｎｏ，Ｓｕｂｓｔｉｔｕｔｅのボタンにより、１
対１または一括のいずれかの置換を実行するための機能
が付与される。これらのボタンとともに、ある特定のサ
ーチタスク（Ａｐｐｌｅをサーチして、それ
をＢａｎａｎａで置換すること）のためのコンパクトな
コントロールパネルが形成される。このパラメータを変
更するためには、ユーザは隠されたコントロールパネル
を露出させて使用することができる（図９Ａ）。

【０１０６】４．ドキュメントスキルがユーザインタフ
ェーススキルになる 従来のドキュメントエディタによれば、ドキュメントの
情報について、生成、選択、移動、コピー、削除、格
納、検索、サーチ、スクロール操作、スタイルの変更、
選択的なディスプレイおよびプリント操作をすることが
できる。ドキュメントがユーザインタフェースであると
きには、これらの能力の全てが、ユーザインタフェース
の生成および使用の双方のために利用可能なものにな
る。

【０１０７】更に、コントロールパネルを構成するため
に、ドキュメントエディタについての通常のレイアウト
能力を用いることができる。境界およびアイコンを生成
させるためにはグラフィックエディタを用いることが可
能であり、また、適当なカラー、フォント、アンダーラ
インその他によってボタンのアウトラインや表の配置を
するためにはテキストエディタを用いることが可能であ
る。このようなコントロールパネルによれば、異なるペ
ージのサイズやスケールファクタに対するテキストのフ
ォーマットを改めるための、テキストエディタにおける
能力を継承することができる。

【０１０８】インタフェースユーザのために、ドキュメ
ントエディタによれば、ユーザインタフェースを介して
ナビゲーション操作するやり方が提供される。様々なタ
スクにおける助けとなるように、ユーザが構築できる大
規模のドキュメントは、セクションおよびサブセクショ
ンに組織されていて、多くのボタン、演算フィールドお
よびその他の能動的な要素を含むようにされている。こ
れらのユーザは、スクロール操作、レベルクリップ操作
（例えば、ヘッダ名だけをディスプレイすること）、お
よび、ユーザインタフェースの構成部を見出すためのテ
キストでのサーチまたはグラフィックスでのサーチをす
る上での利点を享受することができる。

【０１０９】テキストでのサーチ／置換およびグラフィ
ックスでのサーチ／置換（Ｄ．カーランダー(D. Kurlan
der)らの“グラフィックスでのサーチと置換 (Graphica
l Search and Replace) ”, コンピュータグラフィック
ス (Computer Graphics)第22巻、第４号 1988 年８月,
113〜120 ページを参照）は、実在するドキュメントか
らのユーザのインタフェースを迅速になさせるために使
用できるものである。例えば、ドキュメント名、アドレ
スおよび電話番号は、電話番号に類似するストリングを
サーチして、電話番号をダイアルするボタンにそれらを
転送することにより、能動的なドキュメントに転換させ
ることができる。

【０１１０】５．ドキュメントエディタのカスタム化 ユーザインタフェースを改善するためにドキュメントエ
ディタの能力を使用できるように、ボタンを含んでいる
ドキュメントをドキュメントエディタの増強のために使
用することができる。この増強操作サイクルの結果とし
て、ドキュメントエディタおよびユーザインタフェース
の双方に、迅速な改善がもたらされる。例えば、ユーザ
は、テキストのサーチおよびスタイルの変更を含む、退
屈で繁雑なテキストエディタの操作を実行するような、
ボタンコレクションを生成させることができる。一つの
特に有用な実施例であるこのようなボタン（これは“ｓ
ｔｕｆｆｅｒ”と呼ばれている）は、現在のテキストエ
ディタのカーソル位置において、それ自体のテキストの
内容を挿入するものである。

【０１１１】ボタンは、ドキュメントのナビゲーション
操作を改善するためにも用いることができる。一つの例
として、ＧＵＩＤＥハイパーテキストシステム（Ｐ．ブ
ラウン (P. Brown) の“ダイナミックドキュメントの著
作者のためのシンプルメカニズム (A Simple Mechanism
for Authorship of Dynamic Documents) ”Ｊ．Ｃ．バ
ンブリート(J.C. van Vliet)著, テキスト処理およびド
キュメント操作 (TextProcessing and Document Man
ipulation ，ケンブリッジ大学出版部, 内部会議会報
(Proceedings of the Internal Conference, Cambridge
University Press), 1986 年４月, 35〜42ページ) に
よって影響を受けたことは、ボタンの背後にあるドキュ
メントの部位を隠すことである。各ボタンプレスによっ
て、テキストは交番的に現れたり隠れたりする。このよ
うな隠しボタンによれば、関係のあるドキュメント部分
だけに対するスクリーンスペースを用いて、ユーザがド
キュメントを通してブラウズ操作をすることが許容され
る。ここで注意されることは、隠しボタンを有するドキ
ュメントを、積層されたコントロールパネルとして使用
できることである。なお、図９Ａおよび図９Ｂを参照。

【０１１２】グラフィックスエディタをカスタム化する
ために、通常とは異なるやり方でボタンを用いることが
できる。図１０Ａおよび図１０Ｂには、イラストレーシ
ョンプログラムで描かれた円（サークル）のコレクショ
ンが示されている。ここで仮定されることは、ユーザ
が、これらの円について異なるカラー付けを試みようと
することである。通常のエディタコマンドを採用してそ
れぞれの円を順に選択し、それにカラーをあてはめるこ
とによって上記のことは実行できるけれども、それぞれ
のカラーを変更させるためには何回かのマウスクリック
が必要である。例えば、オンのときにはブラック、オフ
のときにはホワイトのように、それぞれの円を２状態の
ボタンにすることの方がはるかに容易なことである。こ
のようなイベントにおいては、カラー変化毎に１回のマ
ウスクリックによってカラーの変化をさせることができ
る。このような全ての変化がなされたときには、再びエ
ディット操作できるカラー直しされたピクチュアを残し
て、ボタンの能動性をオフにすることができる（また
は、ボタンのプロパティをその形状から排除することが
できる）。

【０１１３】６．ボタンは任意の形状をもつことができ
る 任意のカーソルに基づくエディタは、テキスト、グラフ
ィックス、等式、表等のいずれに対するものであって
も、どのオブジェクトをユーザが指摘しているかを見出
すためのやり方を備えている。ボタン属性のアーキテク
チュアには、ユーザがボタンを押しているときに、これ
らの機能について記述する利点がある。かくして、ユー
ザが該当の形状を指摘しているときに、ボタンが埋め込
まれているドキュメントエディタが検出することができ
る限りは、ボタンの形状は、円形、三角形、菓子パン屋
(gingerbread man)、装飾的なレースパターン、その他
の任意の形状であることができる。図４Ａを想起する
と、これに示されているボタンはシステム内の単一のラ
インセグメントであってもよく、ここでユーザに必要な
ことは、正確にオブジェクトにおいてではなく、該オブ
ジェクトの近傍で指示することだけである。

【０１１４】７．ゼネレータ この発明によって考えられている埋め込みボタンについ
ての、より重要なプロパティの一つは、プロセスにおけ
る大方のステップに対し、通常のドキュメントエディタ
の操作の使用を介して、それらがユーザによって生成さ
れ、修正されることが可能なことである。しかしなが
ら、プログラムコントロールの下に、埋め込みボタンを
自動的に生成できることも有用なことである。例えば、
ディレクトリにおける全てのファイルをリストさせるコ
マンドによれば、ボタン属性がファイル名に付加され、
該ファイル名がボタンに転換されて、それが押されたと
きに対応のファイルがオープンするようにされる。

【０１１５】この発明のアーキテクチュアを用いること
により、プログラムによってボタンを含むドキュメント
を生成させる能力のために、特別なプログラミング操作
は必要とされない。このシステムで必要とされること
は、ドキュメント要素上に随意の属性を備えて構築され
たドキュメントを生成させるための、プログラムに対す
るやり方を提供することだけである。この能力は、“ｐ
ｒｉｖａｔｅ ｄａｔａ”と呼ばれるデータを許容す
る、デジタルイクイップメント社 (Digital Equipment
Corporation)のＣＤＡアーキテクチュアのようなシステ
ムには既に存在するものであるが、標準的なドキュメン
ト要素と関連するような、ある特定のドキュメント処理
の実施に限られている。これについては、ＣＤＡ（合成
ドキュメントアーキテクチャ：Compound Document Arc
hitecture ）マニュアル、デジタルイクイップメント
社, メイナード(Maynard),エムエイ(Ma), 1988年11月,
セクション３．１．５．６ が参照される。このような
構築ドキュメントのゼネレータが与えられると、ボタン
を生成させるために必要とされることの全ては、ボタン
として作用するドキュメントのそれらの部分を生成させ
るときに、“ＢｕｔｔｏｎＡｔｔｒｉｂｕｔｅ”と呼ば
れる属性を取り付けることである。

【図面の簡単な説明】

【図１】 本発明のソフトウエアアーキテクチャの説明
図である。

【図２】 Ａ〜Ｃは本発明によるボタンの生成における
順次ステップを示す説明図である。

【図３】 ＡおよびＢはポップアップボタンのメニュー
を示す説明図である。

【図４】 ＡおよびＢはそれら自身の形式プロパティを
選択されたグラフィックオブジェクトに変換することに
よってグラフィック形式マクロスを達成するためのボタ
ンの使用を示す説明図である。

【図５】 Ａ〜Ｃはマルチステートボタンからのユーザ
フィードバックを示す説明図である。

【図６】 グラフィックラジオボタンの組からのユーザ
フィードバックを示す説明図である。

【図７】 ＡおよびＢはグラフィックエディタに埋め込
まれた関連ラジオボタンの対からのユーザフィードバッ
クを示す説明図である。

【図８】 本発明のソフトウエアアーキテクチャおよび
標準的なコンピュータシステムのアーキテクチャによっ
て提供される通信経路を示すブロック図である。

【図９】 ＡおよびＢはそれぞれ本発明によって構築さ
れた制御パネルおよびそのコンパクト表現を示す説明図
である。

【図１０】 ＡおよびＢはマルチステートボタンとして
機能する円から構成されたグラフィックドキュメントを
示す説明図である。

【符号の説明】

１１ ドキュメントエディタ、１２ 埋め込みボタンカ
ーネル、１３ ボタンクラスマネージャ、１４ コマン
ドハンドラ、２０ ボックス、２１ 仮想メモリ、２２
コンピュータシステム、２３ バス、２４ ＣＰＵ、
２５ メモリコントローラ、２６ キーボード、２７
カーソルコントローラ、２８ Ｉ／Ｏコントローラ、２
９ モニタ、３０ ディスプレイコントローラ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 ユーザによってトリガされたときに所定
   のアクションを開始するためのカスタムボタンを任意に
   含んでいるユーザインタフェースを備えたコンピュータ
   駐在ソフトウエアシステムであって；前記ボタンは、電
   子的ドキュメントにおいて、このようなドキュメントの
   人手による判断が可能なエレメントに関連して、隠され
   た持続性のあるキャラクタストリング属性として具体化
   されており；前記ボタンの各々のボタン属性ストリング
   は、ボタンクラス、ボタンデータ、コマンドハンドラ、
   および、任意所望のユーザフィードバックを指定するも
   のであって：次のものを含む前記ソフトウエアシステム 前記ドキュメントの中のユーザによって選択されたもの
   を前記システムにロードするための少なくとも１個のド
   キュメントエディタであって、前記エディタは前記ユー
   ザによって選択されたドキュメントの各々に対するデー
   タ構造を構築しており、これにより、前記選択されたド
   キュメントの任意のものにおいて具体化された任意のボ
   タンに対するボタン属性が、それらの関連したドキュメ
   ントエレメントの構成部分として、前記ドキュメントの
   ためのエディタによって構築されたデータ構造において
   始まるようにされており；ボタンオンモードおよびボタ
   ンオフモードにおいて前記エディタを選択的に動作させ
   るための、ユーザによるセットが可能な入力方向切り替
   えスイッチを備えている前記エディタ：指定可能なボタ
   ンクラスに対する少なくとも１個のクラス指定ボタンハ
   ンドラであって、ある所定のボタンクラスに対するコマ
   ンドリストをそれぞれに含んでいる前記ボタンハンド
   ラ；前記ボタン属性によって与えられたコマンドを実行
   するための、複数の指定可能なコマンドハンドラ；およ
   び前記ユーザによってトリガされた各ボタンのボタン属
   性を分析するための集中カーネルであって、そのように
   分析しながら、前記ボタンについて指定されたボタンク
   ラスおよび前記ボタンに対して指定されたコマンドハン
   ドラを同定するようにされており；前記ボタンによって
   要求されるアクションおよびフィードバックを実行する
   ために、前記エディタ、前記ボタンについて指定された
   ボタンクラスに対するボタンハンドラ、および、前記ボ
   タンに対して指定されたコマンドハンドラの間で通信パ
   スを提供する前記カーネル。