Hi, All. How could I send a message to a widget? Say, I want to have a modal window to be closed after a specified timeout. How could I send it a "default" ID_CANCEL or ID_ACCEPT message, in order to have it close itself and return control to its parent window? TIA, -- angico ------ home page: www.angico.org Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I ------ contatos: email: angico at angico.org skype: an.gi.co ------ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/fxruby-users/attachments/20081021/4b727af8/attachment.html>
On Oct 21, 2008, at 2:54 PM, angico wrote:> How could I send a message to a widget? Say, I want to have a modal > window to be closed after a specified timeout. How could I send it a > "default" ID_CANCEL or ID_ACCEPT message, in order to have it close > itself and return control to its parent window?This should do the trick: dialog.handle(self, FXSEL(SEL_COMMAND, FXDialogBox::ID_ACCEPT), nil) Hope this helps, Lyle --- "FXRuby: Create Lean and Mean GUIs with Ruby" Now available from the Pragmatic Bookshelf! http://www.pragprog.com/titles/fxruby -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/fxruby-users/attachments/20081021/3e68dcd8/attachment.html>
Em Ter, 2008-10-21 ?s 19:59 -0500, Lyle Johnson escreveu:> > On Oct 21, 2008, at 2:54 PM, angico wrote: > > > How could I send a message to a widget? Say, I want to have a modal > > window to be closed after a specified timeout. How could I send it a > > "default" ID_CANCEL or ID_ACCEPT message, in order to have it close > > itself and return control to its parent window? > > > This should do the trick: > > > dialog.handle(self, FXSEL(SEL_COMMAND, FXDialogBox::ID_ACCEPT), nil) > > > Hope this helps, > > > Lyle >Hi, Lyle. Thanks for your tip, but I am afraid it didn''t work. The point is that I have the following code, in my custom dialog box: def execute t = Thread.new { regressao } super end def regressao while @regressor.progress > 0 do @regressor.progress -= 1 sleep 0.05 end handle(self, FXSEL(SEL_COMMAND, FXDialogBox::ID_ACCEPT), nil) end Here, I create a thread just before calling super, to implement a "regress" bar, shown in the dialog. I want the user to be prompted for as long as n seconds (here, 5 seconds) and, if she didn''t atend to the dialog, the dialog takes a default action (in this case, the ID_ACCEPT). The thread works just fine, with the regress bar showing pretty well, but... Well, inserting the line handle(...) from your tip just made the dialog to freeze, with cpu usage hitting 100%. Program needs to be killed. I have tried to move the thread "regressao" to the main window (the parent window for the dialog), but it just doesn''t get called. So, any idea on how to solve this problem? Thanks a lot, -- angico ------ home page: www.angico.org Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I ------ contatos: email: angico at angico.org skype: an.gi.co ------
Em Qua, 2008-10-22 ?s 05:53 -0300, angico escreveu:> Em Ter, 2008-10-21 ?s 19:59 -0500, Lyle Johnson escreveu: > > > > On Oct 21, 2008, at 2:54 PM, angico wrote: > > > > > How could I send a message to a widget? Say, I want to have a modal > > > window to be closed after a specified timeout. How could I send it a > > > "default" ID_CANCEL or ID_ACCEPT message, in order to have it close > > > itself and return control to its parent window? > > > > > > This should do the trick: > > > > > > dialog.handle(self, FXSEL(SEL_COMMAND, FXDialogBox::ID_ACCEPT), nil) > > > > > > Hope this helps, > > > > > > Lyle > > > > Hi, Lyle. > > Thanks for your tip, but I am afraid it didn''t work. > > The point is that I have the following code, in my custom dialog box: > > > def execute > t = Thread.new { regressao } > super > end > > def regressao > while @regressor.progress > 0 do > @regressor.progress -= 1 > sleep 0.05 > end > handle(self, FXSEL(SEL_COMMAND, FXDialogBox::ID_ACCEPT), nil) > end > >Well, while waiting for any more hints, I was wandering why the program was hanging, and I thought it was because the creation of the new thread was happening inside the overridden version of execute (before the call to super). So I dedided to create a new method, ini, to which I moved the line "t Thread.new { regressao }", and which is called from the main window just before calling dialog.execute. It firstly seemed to work, but now I got a segmentation fault at exactly the line for the call to handle(...). Does anybody know what I am doing wrong? TIA, -- angico ------ home page: www.angico.org Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I ------ contatos: email: angico at angico.org skype: an.gi.co ------
Em Qua, 2008-10-22 ?s 08:25 -0300, angico escreveu:> Em Qua, 2008-10-22 ?s 05:53 -0300, angico escreveu: > Well, while waiting for any more hints, I was wandering why the program > was hanging, and I thought it was because the creation of the new thread > was happening inside the overridden version of execute (before the call > to super). > > So I dedided to create a new method, ini, to which I moved the line "t > Thread.new { regressao }", and which is called from the main window just > before calling dialog.execute. It firstly seemed to work, but now I got > a segmentation fault at exactly the line for the call to handle(...). > > Does anybody know what I am doing wrong? > > TIA, > > -- > > angicoOk. I have solved the segmentation fault issue. Now the call to handle(...) causes the dialog box to close, but it still stays alive with its modal behavior. The only way I can get out of it is by typing Ctrl-C in the console. Then I got a message telling me: ./dialogx.rb:54:in `execute'': Interrupt from ./dialogx.rb:54:in `execute'' ... Why can''t I get out of the modal loop via handle(...)? Isn''t there a way to tell the dialog button to "simulate" a click on it, like we do it in Java, with doClick()? Is there any other way I can get out of the modal loop of execute()? Many thanks, -- angico ------ home page: www.angico.org Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I ------ contatos: email: angico at angico.org skype: an.gi.co ------
On Oct 23, 2008, at 8:58 AM, angico wrote:> Ok. I have solved the segmentation fault issue. Now the call to > handle(...) causes the dialog box to close, but it still stays alive > with its modal behavior. The only way I can get out of it is by typing > Ctrl-C in the console. Then I got a message telling me: > > ./dialogx.rb:54:in `execute'': Interrupt > from ./dialogx.rb:54:in `execute'' > ... > > Why can''t I get out of the modal loop via handle(...)? Isn''t there a > way > to tell the dialog button to "simulate" a click on it, like we do it > in > Java, with doClick()? Is there any other way I can get out of the > modal > loop of execute()?I don''t know why sending the ID_ACCEPT or ID_CANCEL message wouldn''t cancel the modal behavior, but I suppose you can just do what those handlers would do directly. Instead of calling handle() on the dialog box, do something like: getApp().stopModal(dialogBox, true) dialogBox.hide Hope this helps, Lyle
Em Qui, 2008-10-23 ?s 09:16 -0500, Lyle Johnson escreveu:> On Oct 23, 2008, at 8:58 AM, angico wrote: > > I don''t know why sending the ID_ACCEPT or ID_CANCEL message wouldn''t > cancel the modal behavior, but I suppose you can just do what those > handlers would do directly. Instead of calling handle() on the dialog > box, do something like: > > getApp().stopModal(dialogBox, true) > dialogBox.hide > > Hope this helps, > > LyleWell, Lyle, I''m affraid the mistery is still there. As far as I can see, the call to handle(...) is doing exactly the same as the call to hide(): it just hides the dialog box, while the modal loop keeps running. I made a call to dialog.show, after calling handle(...) and the dialog just popped up back to the screen. The call to getApp.stopModal(...) also is silently ignored (?). Just wandering: I''m using a thread, started from within the implementation of execute, just before calling super. This thread, then, runs a loop to implement a "regress" bar and once the regress bar reaches 0, I call handle(...) as the final line of this thread. Does this thread cause all this matter of misbehavior? Thanks, -- angico ------ home page: www.angico.org Gnu/Linux, FLOSS, Espiritismo, e eu por mim mesmo 8^I ------ contatos: email: angico at angico.org skype: an.gi.co ------