アカウント名:
パスワード:
というか、元記事は「ふつう、ウィンドウを移動させる操作のことを "ドラッグ・アンド・ドロップ" とは言わないだろ!?」と言いたいのでは?
# 違うかも
ゆーかWinとかのGUI部品って、子は親の矩形領域から「はみでる」ことが出来ない、んでしたっけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
ドラッグ・アンド・ドロップするとたなびいて動くウィ (スコア:0)
Re:ドラッグ・アンド・ドロップするとたなびいて動く (スコア:3, 興味深い)
あとは処理の状態によって、ＣＰＵ負荷の高いウィンドウは湯気が出たりゆらゆらするとか、メモリーをたくさん食っているウィンドウは丸く太るとか。
子供だましだけど楽しそう。
Re:ドラッグ・アンド・ドロップするとたなびいて動く (スコア:1)
というか、元記事は「ふつう、ウィンドウを移動させる操作のことを "ドラッグ・アンド・ドロップ" とは言わないだろ!?」と言いたいのでは?
# 違うかも
Re:ドラッグ・アンド・ドロップするとたなびいて動く (スコア:0)
だから、「ウインドウを引きずってきて落とす」。
で、空気の存在も仮定しているのでヒラヒラする…
# MSに対して「まじめに仕事しろよ」と言いたいのですが、間違っていますか？
Re:ドラッグ・アンド・ドロップするとたなびいて動く (スコア:1)
捕まえられたモノが、窓MorphからマウスポインタMorphへ、所有者変更される、のだそうです。
そしてマウスを放せばまた何処かの窓Morphに還っていく。
DragDropはこうして成り立っているそうです。
冷静に考えたらこれは合理的だなあ。
…そういやWinやXってたしか、マウスポインタをGUI部品と同一視する、という概念は
無いんでしたよね。うーむ…
#まあ、マウスポインタに常時へばりつく常駐ソフトを作って、そいつでポインタの機能をデコレートする、という手は有り得るかも。
てゆーかWinとかのGUI部品って、子は親の矩形領域から「はみでる」ことが出来ない、んでしたっけ。
それじゃ確かに、小さいもの(ポインタとか)が窓やGUI部品を所有することは出来ないわな。
＃リージョン(の動的変化)という概念を駆使すれば可能だが、少々の無駄な重さを抱えるよね。
そっか。これが元凶だな。親子関係と表示位置包含関係とは、ある程度独立して欲しいなあ。
余談：
そういやMorph、「あらゆる」GUI部品が他の部品の所有者になれる、とも書いてあったような。
ボタンは所有者になれない、なんていう制約が有っても、実際には別に嬉しくないんですよね。
それと上記の「はみでることが出来る」という性質を絡めると、
つまり「どんな部品にも、(それより大きいかも知れない)どんな部品をも、ぶら下げられる」ことになるわけで、
こりゃ考えようによってはかなり便利ではないかと。
たとえば「ボタン「に」付箋紙(に見立てたWindow)をぶら下げる」とかを「簡単に」実現できそう。
Re:ドラッグ・アンド・ドロップするとたなびいて動く (スコア:1)
Windowsの標準コントロール(ボタン/エディット/etc...)は単なる定義済みウィンドウでしかないので、WS_CHILDを指定して親ウィンドウに貼り付けなければどこへだって行けますが。