動的フレームの再作成でエラー (ID:22551)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 えーとさん、Frameさん こんにちは えーとさんも参加されたので、もう一度発言します。 まず、議論の仕方ですが、このような技術的な話は 客観的に議論しないと、と私は思っています。 その為、私は正式な文献を引用して発言してきました。 しかし、えーとさんとFrameさんは、主観的な回答をしていますよね これでは、議論が噛み合いません。 Delphiのヘルプで書かれていることが信用してもらえない状況では どう説明すれば分かって貰えるか分かりません。 （これからは、これを見ている他の人為に書くつもりです） ＞Releaseの行き着く先はFreeなのです。 ＞貴方の常識に基づく前にDelphiのVCLのソースを読んでみてください。 これもソースは客観的な物なので皆さんが分かると思いますが しかしFreeを使っても大丈夫だと言う理由が客観的に示されていません。 Freeを使っても大丈夫だと思うのはFrameさんの主観なのです。 私がソースを読んでFreeを使ってはいけないと思いました。 これが私の主観です。 一回私の考えを全て書いてみます。 (主観ですから、正しいとはかぎりません。参考程度で) Frameさんがよく発言されている。PostMessage・SendMessageの件ですが 私の認識では、PostMessageはキュー（スレッド毎）に貯めた順番に実行され、 SendMessageは先入れ先出し(FIFO)で実行されます。 つまり、別フォームをFreeする場合、Free先のキューにPostMessage処理がある場合 それより先にFreeが実行され、その後にPostMessage処理が実行され エラーになる可能性があるます。 Frameさんは、 ＞Releaseのソースを見ていただけたら分かると思いますが、Releaseではメッセージを自分のWindowに投げてリターンしているだけです。(まだ実体は存在している) ＞実際の解放はメッセージのアイドルループの処理の中で行うようになっています。 ＞そこでの解放にはFreeを使用しています。 ＞このことからもFree/FreeAndNilを使用することには全く問題がないことが分かると思います。 と思っているようですが、私の考えでは ＞「Windowに投げてリターンしているだけ」 が重要だと思います。これにより安全に解放されると思っていますし それが出来ないFreeは「使ってはいけない」と思います。 次に ＞一般的なイベントハンドラはSendMessageが起動元になっている場合が多いと思います。 ＞これはいわゆる割り込みに近いもので他の処理をペンディングしてメッセージの処理をしています。その(割り込み)処理の中でFreeされてしまうとペンディングされている処理が再開された時にオブジェクトがなくなっているのでメモリ保護違反が起きる可能性が高くなります。 ＞またPostMessageによるアイドルループでのメッセージイベントハンドラでは安全にFreeをすることが可能です。(ちゃんと設計されてれば) この発言の「PostMessageによるアイドルループでのメッセージイベントハンドラでは安全にFreeをすることが可能」と考えているようですが （上での発言「Free/FreeAndNilを使用することには全く問題がない」よりは、少しは 分かってもらえたみたいですが、あとすこし分かってもらえると...） PostMessage処理は、自フォーム内でのイベント場合ですか？ その場合、自フォームのキューで待機するだけです。相手フォームを安全にFreeすることが出来ません。 Freeする相手フォームでのイベントの場合、もちろん上手くいきます それが、Releaseと同じ構造だからです。 もちろん、えーとさんの ＞Release は、たんに非同期開放を行うだけです。Frame さんも書かれているようにPostMessage() を使って、いったんハンドラを出たあと開放します。この仕組みさえ ＞分かっていれば、Release() を使う必要がない場面もすぐに分かります。その場合は ＞Free や FreeAndNil() を使っても一向に構いません。 言うとおり、Freeを使って絶対に問題が出るとは私にも言えません。 しかし、絶対に問題がないとも言えないのです。 ＞「Release() を使う必要がない場面もすぐに分かります」 と発言されていますよね、すぐに分かりますか？ 私の考えではFreeを使って良い場合は、PostMessageメッセージが使われていないか またはFreeが実行される前に全てのPostMessage処理が実行を終了していることを 保証しないといけません。 この事を、フォーム自身・他フォーム・VCLなどからの実行される、 全てのPostMessage処理についも保証しないといけません。 （もちろん同じ（フォーム自身）キューで実行される処理の話です） ましてや、ユーザーがどのような操作をしても、また環境や他のアプリの影響で キューの実行が遅延しても保証しないといけません。 これは、私には簡単には出来ません。もちろん、私より優秀な人は 簡単に出来と主張するかも知れませんが．．． （そもそも、そんなに優秀な人はクラス設計時にクラスが別クラスの構造に 依存しないように作ると思います。 カプセル化はオブジェクト設計の基本なので... 今回は技術的な話なので、設計の話は止めておきますが） 長くなったのでこれで終わります。