Re: when we can delete a class derived from Gtk::Window or others
aitor <[email protected]> Mon, 21 Feb 2022 01:56:16 +0100
| Newsgroups | gmane.comp.gnome.gtkmm |
|---|---|
| Message-ID | <[email protected]> |
--===============8470566155400052907== Content-Type: multipart/alternative; boundary="------------B99A2E350817AA8963D74A62" Content-Language: en-US --------------B99A2E350817AA8963D74A62 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Klaus, On 19/2/22 13:00, Klaus<[email protected]> wrote: >> I tested you example and it works whenever the user closes the windows in the reverse >> order from creation. > That it seems to work is known. The question is, is it the allowed way > to do this? If the Gtk::Window class performs more actions after hide() > and access data for the current class, the code has undefined behavior, > even if it works in the moment. I simply could not find any > documentation which gives me an idea what the window class perform on > close action. > > BTW: Overriding the unrealize() function compiles ( override gives no > error message from the compiler ) but the function will never be called. > Nice bug! The signal handler manually connected via connect() works. Wow:-) > >> But, what happens if the user closes the parent window first? > All the given example is only a stupid example to give an idea what I > need to do. That in case of unordered closes something may hang is not > the problem. The question to answer is only for the current window and > delete. All interactions in the example code are not in focus here. I was going to suggest you something like this: https://www.gnuinos.org/gtkmm/simple.cc <https://www.gnuinos.org/gtkmm/simple.cc> Hope this helps :) Aitor. --------------B99A2E350817AA8963D74A62 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <pre>Hi Klaus, </pre> <div class="moz-cite-prefix"> <pre>On 19/2/22 13:00, Klaus <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:</pre> </div> <blockquote type="cite" cite="mid:[email protected]"> <blockquote type="cite" style="color: #007cff;"> <pre class="moz-quote-pre" wrap="">I tested you example and it works whenever the user closes the windows in the reverse order from creation. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">That it seems to work is known. The question is, is it the allowed way to do this? If the Gtk::Window class performs more actions after hide() and access data for the current class, the code has undefined behavior, even if it works in the moment. I simply could not find any documentation which gives me an idea what the window class perform on close action. BTW: Overriding the unrealize() function compiles ( override gives no error message from the compiler ) but the function will never be called. Nice bug! The signal handler manually connected via connect() works. Wow <span class="moz-smiley-s1" title=":-)"><span>:-)</span></span> </pre> <blockquote type="cite" style="color: #007cff;"> <pre class="moz-quote-pre" wrap="">But, what happens if the user closes the parent window first? </pre> </blockquote> <pre class="moz-quote-pre" wrap="">All the given example is only a stupid example to give an idea what I need to do. That in case of unordered closes something may hang is not the problem. The question to answer is only for the current window and delete. All interactions in the example code are not in focus here.</pre> </blockquote> <pre>I was going to suggest you something like this:</pre> <pre><a moz-do-not-send="true" href="https://www.gnuinos.org/gtkmm/simple.cc">https://www.gnuinos.org/gtkmm/simple.cc</a></pre> <pre>Hope this helps :)</pre> <pre>Aitor.</pre> <p><br> </p> </body> </html> --------------B99A2E350817AA8963D74A62-- --===============8470566155400052907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list --===============8470566155400052907==--