Is there a way to test if a FXWindow has been destroyed?
If a window is closed by the user clicking the close box, for example,
is there some flag in the FXWindow object that you can test so that you
don''t try to show or raise the window without creating it again?
Or do you have to intercept the close event and maintain that state
yourself?
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
AFAIK there is the shown? method On 4/19/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote:> > > Is there a way to test if a FXWindow has been destroyed? > > If a window is closed by the user clicking the close box, for example, > is there some flag in the FXWindow object that you can test so that you > don''t try to show or raise the window without creating it again? > > Or do you have to intercept the close event and maintain that state > yourself? > > -- > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20070419/0cdf3d11/attachment.html
On 4/19/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote:> Is there a way to test if a FXWindow has been destroyed?If a window has been destroyed, or hasn''t been created *yet*, then created? method should answer false: window.create unless window.created? window.show Note, however, that create is supposed to be a no-op if the window is already realized, so you should be able to shorten the above code to: window.create window.show Hope this helps, Lyle
Lyle Johnson wrote:> On 4/19/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote: > >> Is there a way to test if a FXWindow has been destroyed? > > If a window has been destroyed, or hasn''t been created *yet*, then > created? method should answer false: > > window.create unless window.created? > window.showA window that has been destroyed causes created? to fail with "This FXId * already released". To see this, change glviewer.rb as follows: --- glviewer.rb.bck 2007-04-19 09:13:28.000000000 -0700 +++ glviewer.rb 2007-04-19 09:13:28.000000000 -0700 @@ -272,6 +272,10 @@ FXMenuCommand.new(filemenu, "&Dump...\t\tDump widgets.", nil, getApp(), FXApp::ID_DUMP) FXMenuCommand.new(filemenu, "&Quit\tCtl-Q\tQuit the application.", nil, getApp(), FXApp::ID_QUIT) + FXMenuCommand.new(filemenu, "Foobar", nil).connect(SEL_COMMAND) do + p mdichild.created? + end + # Edit Menu editmenu = FXMenuPane.new(self) FXMenuTitle.new(menubar, "&Edit", nil, editmenu) Then, run it, select the File/Foobar menu cmd, close the child window, and then select the File/Foobar menu cmd again. You shout get this: $ ruby glviewer.rb true glviewer.rb:276:in `created?'': This FXId * already released (RuntimeError) from glviewer.rb:276:in `initialize'' from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.6.11/lib/fox16/responder2.rb:57:in `call'' from /usr/local/lib/ruby/gems/1.8/gems/fxruby-1.6.11/lib/fox16/responder2.rb:57:in `onHandleMsg'' from glviewer.rb:579:in `run'' from glviewer.rb:579 -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Meinrad Recheis wrote:> AFAIK there is the shown? methodIf the window has been destroyed, #shown? has the same effect as #created? -- it dies with "This FXId * already released". -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
On 4/19/07, Joel VanderWerf <vjoel at path.berkeley.edu> wrote:> > Meinrad Recheis wrote: > > AFAIK there is the shown? method > > If the window has been destroyed, #shown? has the same effect as > #created? -- it dies with "This FXId * already released".jeah, and interestingly a widget comes back to life when you call create again. i found out that calling destroy on widgets does not remove them from the widget tree and they come back to live after calling create on their parent. but this is another story. Lyle, I also think that such a state that can be queried with a method like destroyed? would be very good to have. i had to work around this shortcoming in fxruby for several times. Is it technically possible? regards, -- henon --> vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 > _______________________________________________ > fxruby-users mailing list > fxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/fxruby-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/fxruby-users/attachments/20070419/0890d99c/attachment-0001.html
On 4/19/07, Meinrad Recheis <meinrad.recheis at gmail.com> wrote:> jeah, and interestingly a widget comes back to life when you call create > again. i found out that calling destroy on widgets does not remove them from > the widget tree and they come back to live after calling create on their > parent. but this is another story.Yes, this is as designed. Calling destroy() on a widget is (supposed to) only destroy the server-side resource and leave the client-side object (i.e. the Ruby instance) intact -- so that you could, as you noted, call create() on it to "re-realize" it. This is in contrast to, say, removeWidget(), which both destroys the server-side resource and deletes the client-side object. The message that Joel is seeing indicates that the underlying C++ object has been destroyed (deleted) as well, which shouldn''t happen if all you''re doing is calling destroy on it. So I need to figure out what''s going on there.> Lyle, I also think that such a state that can be queried with a method like > destroyed? would be very good to have. i had to work around this shortcoming > in fxruby for several times. Is it technically possible?As I stated in a previous e-mail, created? is supposed to answer true is there is a server-side resource (e.g. a widget, font, cursor, ...) associated with the client-side object (the Ruby instance).
Lyle Johnson wrote:> On 4/19/07, Meinrad Recheis <meinrad.recheis at gmail.com> wrote: > >> jeah, and interestingly a widget comes back to life when you call create >> again. i found out that calling destroy on widgets does not remove them from >> the widget tree and they come back to live after calling create on their >> parent. but this is another story. > > Yes, this is as designed. Calling destroy() on a widget is (supposed > to) only destroy the server-side resource and leave the client-side > object (i.e. the Ruby instance) intact -- so that you could, as you > noted, call create() on it to "re-realize" it. This is in contrast to, > say, removeWidget(), which both destroys the server-side resource and > deletes the client-side object. > > The message that Joel is seeing indicates that the underlying C++ > object has been destroyed (deleted) as well, which shouldn''t happen if > all you''re doing is calling destroy on it. So I need to figure out > what''s going on there.I *think* the following is a good workaround, and in some ways a better approach than #destroyed? anyway (better to ask forgiveness than to ask permission, as they say): begin window.show rescue => ex if /already released/ =~ ex.message window = make_window window.show else raise end end I don''t like matching the exception text though. I wonder if the "already released" error could be represented by a subclass of RuntimeError? -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407