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

名前

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

本文

> ひれかつ 2006/08/23(水) 23:54:44 
> ＞今回のFormFreeメソッドは、他のフォームのメソッドを使っているだけで、
> ＞普通にFreeと書いているのと変わりがない。
> ＞別フォームで破棄することが難しいという話の例にはならない。
> 別フォームで普通にFreeして、エラーが発生するから
> いいのでは？  Releaseは上手くいく、何が問題？
> 「Releaseは上手くいく、Freeがエラーになる」十分危険性が分かると思うが？

「Releaseは上手くいく、Freeがエラーになる」という方向性ならいいのですが、
「別フォームでFreeすることがいかに難しいか」ということに対する回答には、なりえません。
・・ということでしょ？
TAplicationのDispatchMessageで処理した一つのメッセージが流れている途中にすぎないから、
TForm2.ToolButton1Click だろうが、TForm1.Form2Free; だろうが、やってることは同じだから、結果はかわらない。

ToolButtonがエラーになり、Buttonがエラーにならないのは内部的な作りの問題。
こういうことがあるから、(今回の例で言えば)Form2上のコントロールから、自身を破棄するには、Releaseを使いなさい。
でも、Form1側にForm2の破棄処理を書いたからと言って、Form2上のコントロールから発生するイベント内で
Form1側のForm2の破棄処理を実行しても、所詮Form2が自殺しているのと同じ。

今、Delphiの環境がないけど、ToolButtonClickの自殺Freeを、Releaseに変更したら、エラーはでなくなるでしょう。
でも、Application.ProccessMessages; をさらにつっこんだら、エラーでない？

それが、この辺で言ってる事なのかもしれないが、よくわからなかった。
> まさ 2006/08/22(火) 16:56:06 
> （略）
> 私の考えではFreeを使って良い場合は、PostMessageメッセージが使われていないか
> またはFreeが実行される前に全てのPostMessage処理が実行を終了していることを
> 保証しないといけません。

>（実話は私も直接Releaseを使いません(Freeも使いません)
じゃ、どうやってるの？
これを聞きたい。
Releaseの最終結果はFreeだし、Freeなくしてメモリの解放はありえないんじゃない？
そういうことじゃなく、OnCloseでcaFree？

ま、FreeでもReleaseでも、参照している変数がnilにならずに放置されていれば、
安全に破棄できても、意味ないけどねぇ。

←解決時は質問者本人がここをチェックしてください。

戻る