動的フレームの再作成でエラー (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にならずに放置されていれば、 安全に破棄できても、意味ないけどねぇ。