[MonoDevelop] What is the correct way of closing a Gtk dialog?
"Andrés G. Aragoneses"
knocte at gmail.com
Fri May 23 02:49:42 EDT 2008
Michael Hutchinson wrote:
> On Thu, May 22, 2008 at 8:41 AM, Chris Howie <cdhowie at gmail.com> wrote:
>> On Thu, May 22, 2008 at 7:15 AM, simon.n.lindgren at gmail.com
>> <simon.n.lindgren at gmail.com> wrote:
>>> I have created a dialog that I show to the user to get an input value.
>>> How do I close the dialog in the correct way when the user clicks one of
>>> the buttons in the dialog?
>>> Currently I'm using the Destroy() method but that's not correct, is it?
>>> I'm using C# and gtk-sharp.
>> That is the correct way to close and dispose of all of the resources
>> associated with a GObject, yes, and it works for GTK windows too.
>> (Personally, I've always wondered why GObject doesn't implement
>> IDisposable, but that's another discussion.)
>
> Indeed. The confusing thing is that IDisposable IS implemented on GTK#
> widgets but doesn't call Destroy -- and sadly, this can't be changed
> without breaking backwards compatibility.
>
> However, this needn't be the case for new widgets. The first thing I
> do when subclassing Dialog is to override Dispose with a version that
> calls Destroy. Then I can use the 'using' pattern:
> using (MyDialog dialog = new MyDialog ()) {
> somevalue = dialog.Run ();
> }
>
Sorry to jump in, and maybe I'll sound a bit disruptive but, I *think*
that breaking backwards compatibility from time to time is a good thing
(TM). For instance, the kernel devs do it for every version (yeah, there
are reasons why they don't need to keep it, but also why it's better not
to keep it). I wonder if it would be nice to plan for a release that
breaks it, announcing it properly, planning it properly (what to break
and what not, in a wiki, some months before the release, etc...). And
it's not that I'm specially interested in this, but I've seen these
problems in some cases, and this one seems the most important to me.
Regards,
Andres
--
More information about the Monodevelop-list
mailing list