こんばんは、川合です。
FORM-Akkie さんは 2003/11/03 18:56:19 の「[OSASK 6641] FORM: re:
ウィンドウ移動アルゴリズムについて」で書きました：
>> いや、ええと、グラフィックボックスも更新していないことは分かり
>>ますよ。つまり、flushだとか、ラインだとかの際に、windowがアクセ
>>スイネーブルかどうかを調べる部分がありますが、あそこにelseを追加
>>して、グラフィックボックス内のフラグ（64バイトのうちの、空いてい
>>るところを適当に割り振るとして）を立ててやればいいんです。
>
> flushコマンドの引数にはgboxがないので、どのグラフィック
>ボックスをflushしているのか分かりません。そもそもグラフィッ
>クボックスのflushであるとは言い切れません (本来putblockです
>から)。
しまった！そうか・・・。I.Tak.さんのいう通りです。
ということは、gboxを指定できるflushを作るべきだな。よし、その
うち作ろう。
> ……つまり、川合さんのコードでは目的は達せられなかったん
>です(;_; 状況は変化しませんでした。
がーん、しくしく・・・。なぜだあ！
>> あちゃあ・・・。それを説明しなきゃなんないのか・・・。というか
>>それだと、僕がwinman0を改造するほうが楽になってしまう・・・。
>
> そんなに複雑なんですか!?
> じゃ、もっと突っ込んで聞きます。
>1)job_flag0の下位16ビット (4ビットしか使われてないけど) は
> job_general1の最初で計算される＝外で書き換える必要はない
> ということでいいんでしょうか。job_movewin0の中で1を代入
> してるんですが。
確かに1を代入しています。それは0とかにしてみて観察しないと断言
はできませんが、もしかしたらとりあえず上位ビットをクリアするため
だけに代入をしているのかもしれません。またjob_flags0は、job_gene
ralでの解釈がそうであるだけで、generalに突入する前は他の目的で使
ってもよいことになっています。そういう事があるのかもしれません。
>2)逆に上位16ビットは外部からも渡される値ですね?
そのようです。
>3)そこに入ってるWINFLG_OVERRIDEDISABLEの意味はなんですか?
> 一時的かつ最優先の描画禁止 (ウィンドウを下から再描画する
> 際の順序を保証するため) という認識でOKですか?
>これだけ教えて頂ければなんとかなります。多分。
ええと括弧内の部分を除いて、「一時的な描画禁止」と認識してくだ
さい。つまり、conditionではaccessenableな値を示しているのに、あ
えて一時的にdisableにしなければいけない状況というのはあるのです
。たとえば、ウィンドウ移動中とか。そんな風に、一時的に描画禁止に
しておきましたので、必要に応じて解除してください、というのをjob_
generalに伝えるためのbitです。
job_general内では、またbitの意味が変わっているかもしれません。
これらのbitの意味は、job_generalに突入する際の約束であって、その
ほかの状況では守る必要のないことですから。
ウィンドウを下から描画するために、上のウィンドウをoverride-dis
ableにしている部分がありましたか？・・・いや、原理的に多分そんな
ことをする必要はないと思うので、もしそういう部分があったとしたら
僕の勘違いの残骸です（下のウィンドウを描いている間に、オーバラッ
プした部分を勝手にいじられても問題はないかと。だってそこはどうせ
書き直される部分なのですし）。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/