本日もいけいけどんどん。(^-^;
旧バージョン: Gecko Info for Windows Accessibility Vendors Rev.1.02
新バージョン: Gecko Info for Windows Accessibility Vendors Rev.1.13
原文（旧）： 青色表示
原文（新）： 緑色表示
訳文（新）： 黒色表示
*注記/コメント: 赤色表示
How to Find a Gecko Window
All Mozilla windows have the window class called "MozillaWindowClass". In addition, you can find out whether a window is a content window or a XUL UI window. This is done by checking the low bit of the control ID, which is returned when you make the Win32 API call controlId = ::GetWindowLong(hWnd, GWL_ID) & 1. If the result is 0, this is a UI window; if it is 1, then this is a content window. At this point, embedding clients don't use XUL, so for them you only need to find the top MozillaWindowClass window. Fortunately, you won't need separate logic for all different clients. Whenever you see a MozillaWindowClass window focused, keep moving to the first child if it has a control ID of 0. If it has a control ID of 1, find the first ancestor that also has a control ID of 1. This is where you should start when using MSAA to get the content tree for a Mozilla application.
//→この節は跡形もなく変更されています。//
How to Find the Content Window and Load the Document
Screen readers need to find the content window so that they know where to start grabbing the MSAA tree, in order to load the current document into a buffer in their own process. The content window always has the class MozillaContentWindowClass.
In total, Gecko supports the following window classes:
* MozillaUIWindowClass - root UI window, at the root of the window hierarchy
* MozillaContentWindowClass -- root document window
* MozillaContentFrameWindowClass - root of a subdocument created by a (frame) or (iframe) element
* MozillaHiddenWindowClass - ignore these windows, they are used to help manage other windows
* MozillaWindowClass - general filler window, a catch all
コンテンツウィンドウの見つけ方と、ドキュメントの読み込み方法
スクリーンリーダーは、自らの処理で現在のドキュメントをバッファに取り込むために、コンテンツウィンドウを見つけ MSAA ツリーの獲得を開始するポイントを知る必要があります。コンテンツウィンドウはかならず、MozillaContentWindowClass というクラスを備えています。
Gecko は以下に示すウィンドウクラスをすべてサポートします:
* MozillaUIWindowClass - ウィンドウ階層の根底にあるルート UI ウィンドウ
* MozillaContentWindowClass -- ルートドキュメントウィンドウ
* MozillaContentFrameWindowClass - (frame) や (iframe) 要素によって作られるサブドキュメントのルート
* MozillaHiddenWindowClass - これらのウィンドウを無視してください。他のウィンドウの操作の支援をするのに使われます。
* MozillaWindowClass - 一般的な埋め草ウィンドウ、多目的
When you see any of the above windows receive focus, first check the role. If it is ROLE_PANE or ROLE_DOCUMENT then this should be treated as a document for the default modality of the screen reader. If it is a ROLE_APPLICATION or ROLE_DIALOG then stay in focus tracking mode -- there is no need to parse the document. This can happen because of the new DHTML accessibility technology.
上記のウィンドウのいずれかに気付いたなら、始めにその役割を調べてください。ROLE_PANE や ROLE_DOCUMENT ならば、スクリーンリーダの初期設定モード用のドキュメントとして処理されるべきです。ROLE_APPLICATION や ROLE_DIALOG であれば、フォーカスの追跡モードであって、ドキュメントの解析は必要ありません。というのは、新しい DHTML アクセシビリティテクノロジーのお陰でこれが可能になります。
Once you know that you have a document, go up the ancestor chain of windows until you see a MozillaContentWindowClass or a MozillaUIWindowClass. If it is a content window, you may use AccessibleObjectFromWindow() to get the root IAccessible for the content, and begin traversing the tree from there.
ドキュメントがあると分かれば、ウィンドウの上層へ、MozillaContentWindowClass か MozillaUIWindowClass を見つけるまで、連鎖をたどってください。もしそれが、コンテンツウィンドウであれば、AccessibleObjectFromWindow() を使ってコンテンツ用に ルート IAccessible を取得し、ツリーからツリーへと移動を開始できます。
Gecko also helps determine when to load a new window by firing two EVENT_STATE_CHANGE's on the root ROLE_DOCUMENT accessible -- the first state change indicates the document pane is now busy loading. The second state change indicates the document pane has finished. When handling the event, use get_accState() to check the STATE_BUSY flag. When the document has finished loading the busy flag will be cleared.
Gecko はまた、ROLE_DOCUMENT accessible で 2 つの EVENT_STATE_CHANGE を起動することで、新しいウィンドウをいつ読み込むべきかの決定をし易くします。最初の状態の変更はドキュメントのペインが今読み込みで塞がっていることを示します。2 番目の変更はドキュメントのペインが読み込みを完了したことを示します。イベントを処理するとき、get_accState() を使って STATE_BUSY フラグを調べてください。ドキュメントが読み込みを完了すると、塞がっていることを示すフラグはクリアーされます。
本日までの完了分は、あらたに新草稿へ追加反映します。
旧草稿→新草稿
(^-^)/~~~~
旧バージョン: Gecko Info for Windows Accessibility Vendors Rev.1.02
新バージョン: Gecko Info for Windows Accessibility Vendors Rev.1.13
原文（旧）： 青色表示
原文（新）： 緑色表示
訳文（新）： 黒色表示
*注記/コメント: 赤色表示
How to Find a Gecko Window
All Mozilla windows have the window class called "MozillaWindowClass". In addition, you can find out whether a window is a content window or a XUL UI window. This is done by checking the low bit of the control ID, which is returned when you make the Win32 API call controlId = ::GetWindowLong(hWnd, GWL_ID) & 1. If the result is 0, this is a UI window; if it is 1, then this is a content window. At this point, embedding clients don't use XUL, so for them you only need to find the top MozillaWindowClass window. Fortunately, you won't need separate logic for all different clients. Whenever you see a MozillaWindowClass window focused, keep moving to the first child if it has a control ID of 0. If it has a control ID of 1, find the first ancestor that also has a control ID of 1. This is where you should start when using MSAA to get the content tree for a Mozilla application.
//→この節は跡形もなく変更されています。//
How to Find the Content Window and Load the Document
Screen readers need to find the content window so that they know where to start grabbing the MSAA tree, in order to load the current document into a buffer in their own process. The content window always has the class MozillaContentWindowClass.
In total, Gecko supports the following window classes:
* MozillaUIWindowClass - root UI window, at the root of the window hierarchy
* MozillaContentWindowClass -- root document window
* MozillaContentFrameWindowClass - root of a subdocument created by a (frame) or (iframe) element
* MozillaHiddenWindowClass - ignore these windows, they are used to help manage other windows
* MozillaWindowClass - general filler window, a catch all
コンテンツウィンドウの見つけ方と、ドキュメントの読み込み方法
スクリーンリーダーは、自らの処理で現在のドキュメントをバッファに取り込むために、コンテンツウィンドウを見つけ MSAA ツリーの獲得を開始するポイントを知る必要があります。コンテンツウィンドウはかならず、MozillaContentWindowClass というクラスを備えています。
Gecko は以下に示すウィンドウクラスをすべてサポートします:
* MozillaUIWindowClass - ウィンドウ階層の根底にあるルート UI ウィンドウ
* MozillaContentWindowClass -- ルートドキュメントウィンドウ
* MozillaContentFrameWindowClass - (frame) や (iframe) 要素によって作られるサブドキュメントのルート
* MozillaHiddenWindowClass - これらのウィンドウを無視してください。他のウィンドウの操作の支援をするのに使われます。
* MozillaWindowClass - 一般的な埋め草ウィンドウ、多目的
When you see any of the above windows receive focus, first check the role. If it is ROLE_PANE or ROLE_DOCUMENT then this should be treated as a document for the default modality of the screen reader. If it is a ROLE_APPLICATION or ROLE_DIALOG then stay in focus tracking mode -- there is no need to parse the document. This can happen because of the new DHTML accessibility technology.
上記のウィンドウのいずれかに気付いたなら、始めにその役割を調べてください。ROLE_PANE や ROLE_DOCUMENT ならば、スクリーンリーダの初期設定モード用のドキュメントとして処理されるべきです。ROLE_APPLICATION や ROLE_DIALOG であれば、フォーカスの追跡モードであって、ドキュメントの解析は必要ありません。というのは、新しい DHTML アクセシビリティテクノロジーのお陰でこれが可能になります。
Once you know that you have a document, go up the ancestor chain of windows until you see a MozillaContentWindowClass or a MozillaUIWindowClass. If it is a content window, you may use AccessibleObjectFromWindow() to get the root IAccessible for the content, and begin traversing the tree from there.
ドキュメントがあると分かれば、ウィンドウの上層へ、MozillaContentWindowClass か MozillaUIWindowClass を見つけるまで、連鎖をたどってください。もしそれが、コンテンツウィンドウであれば、AccessibleObjectFromWindow() を使ってコンテンツ用に ルート IAccessible を取得し、ツリーからツリーへと移動を開始できます。
Gecko also helps determine when to load a new window by firing two EVENT_STATE_CHANGE's on the root ROLE_DOCUMENT accessible -- the first state change indicates the document pane is now busy loading. The second state change indicates the document pane has finished. When handling the event, use get_accState() to check the STATE_BUSY flag. When the document has finished loading the busy flag will be cleared.
Gecko はまた、ROLE_DOCUMENT accessible で 2 つの EVENT_STATE_CHANGE を起動することで、新しいウィンドウをいつ読み込むべきかの決定をし易くします。最初の状態の変更はドキュメントのペインが今読み込みで塞がっていることを示します。2 番目の変更はドキュメントのペインが読み込みを完了したことを示します。イベントを処理するとき、get_accState() を使って STATE_BUSY フラグを調べてください。ドキュメントが読み込みを完了すると、塞がっていることを示すフラグはクリアーされます。
本日までの完了分は、あらたに新草稿へ追加反映します。
旧草稿→新草稿
(^-^)/~~~~