From: "NAKAMURA, Hiroshi" <nakahiro@...>
Date: 1999-12-15T12:31:19+09:00
Subject: [ruby-list:19524] Re: ClipBoard I/O 対応

なひです．

おもいっきりWindows固有の話です．
今後Rubyに絡まないようなら，これで最後にします．m(..m

> From: 中村暁史 Nakamura Akifumi [mailto:BXQ04723@nifty.ne.jp]
> Sent: Wednesday, December 15, 1999 1:44 AM

> ＞m.set( { :CF_TEXT => anObject.inspect, :CF_RUBYOBJECT => anObject.dump } )
> ＞m.get( :CF_TEXT )
> ＞m.get( :CF_RUBYOBJECT )
> 
> う。理解できてない俺。
> ええとこのm.setはどういうことをするメソッドなんでしょうか？
> 複数のデータ(およびデータ形式)を書くんじゃないだろうし…

複数のデータ(およびデータ形式)を書くつもりでした．^^;
clientがCF_RUBYOBJECTを要求した場合にはMarshal#dump()したものを，
clientがCF_TEXTを要求した場合にはObject#inspect()したものを返せるように，
serverが複数のデータフォーマットでClipboardに登録する，と．

# もしかしてこの時点で既に認識のズレがあるかな?

順序を保存，とかはよくわかりませんでした．^^; clientがOSに
「現在Clipboardに入っているデータフォーマット（複数）はなんですか?」
と問い合わせた時に返ってくるデータフォーマットの順番?

> ＞複数あったらただの共有メモリかも．
> 
> 1つしかなくてもただの共有メモリなのでは(^^;

「ただの」共有メモリではなく，
「標準化されたフォーマットを持つ」共有メモリ，
という意味です．

> やっぱりosもoopみたいにしてtypeの樹形図を
> サポートしてくれないとなあ…と思うのです。

MFCならCOleServerItemという根がありますね．
delphiの．．．OWL? 今はもうそんなのないの? よく知りませんが(^^;)，
にも，なんかあるでしょうきっと．delayed rendering（serverは，
clientに要求されるまでClipboardにデータをコピーしない; Excelなどを
落とすときに「クリップボードにコピーする?」とか聞いてくるアレ）を
やろうと思うと，なんかの助けは必要になると思います．
で，その根が，データフォーマットまで縛るのがいいのかどうか．．．

そんなのOSに縛られたくないと，なひは思います．

> win(少なくとも9x)のエクスプローラで、ファイル「の内容」の
> 検索ってのが出来ますが、不思議なことに(笑)MSWordなどの文書
> 「の内容」は検索できないみたい。勿論それ以外のどのtypeの文書も。

できるんじゃないですかねぇ．所詮ファイルシステムのgrepだし．
もちろん圧縮してあったら駄目．
それとは別に，もっと知的な検索機能がOSについていて欲しい，
というのは理解できます．構造化記憶のインタフェイスに
検索メソッドがないのは何故だろう．

> ん、でもきちんと作らないと益々落ちやすくなるか(笑)。

なひのWin32はそんなに落ちないです．何故でしょうねぇ．:-)

--
NaHi, nakahiro, a.k.a. NAKAMURA, Hiroshi
http://www.sarion.com  Sarion Systems Research