': undefined method `each' for "a\nb\n":String (NoMethodError) each_byte works though. === arity: class A def self.meth_with_block(a, &block) puts block.arity end end A.meth_with_block do |arg1| end Ruby 1.9 => -2 Ruby 1.8.6 => 1 (I don't know if this is a bug in 1.9 or not. I don't understand the logic behind -2 - you'd think it'd be 1). From what I've seen on the mailing lists, -2 should be |a,*b|. === From activesupport: def self.included(klass) #:nodoc: klass.funcall(:alias_method, :to_default_s, :to_s) klass.funcall(:alias_method, :to_s, :to_formatted_s) end works, but: def self.included(klass) #:nodoc: klass.send(:alias_method, :to_default_s, :to_s) klass.send(:alias_method, :to_s, :to_formatted_s) end doesn't. === about "when" clause, a couple libraries I use do this: case somevar when 1: true when 2: false end This no longer works in 1.9. You have to do: when 1; true when 2; false or when 1 then true when 2 then false I've never done this in my own code. === You are correct about RB_STRING* also, it is RSTRING*, just misspoke. My quick hack was to replace all with the _PTR and _LEN macros. I'll update my own libraries to use StringValuePtr and StringValueCStr. Thanks! Kevin http://www.systemware.com/ From lyle.johnson at gmail.com Wed Apr 18 10:59:50 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Wed, 18 Apr 2007 09:59:50 -0500 Subject: [fxruby-users] [ANN] FXRuby 1.6.11 Now Available Message-ID: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, FXRuby version 1.6.11 is now available for download from this page: http://rubyforge.org/frs/?group_id=300&release_id=11201 This is a bug fix release and is strongly recommended. Note that if you're building FXRuby from source, you should be using FOX 1.6.16 or later due to some important changes made in that release of FOX. For a summary of the changes in this release of FXRuby, please see this page: http://www.fxruby.org/doc/changes.html As usual, the code is provided as a Win32 installer or a binary Gem (both compatible with the latest One-Click Installer for Ruby), as a source gem, and as a source tarball. For instructions on compiling FXRuby from source, please see: http://www.fxruby.org/doc/build.html And as always, the FXRuby home page is here: http://www.fxruby.org Enjoy, Lyle - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGJjIkFXV/hD6oMd0RAjlNAJwMfNChkS289j2eFj3NjsH9LmmFSACeKjYc Izv7GCI9ke2DJT+9BFwO/sM= =ChLV - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGJjJnFXV/hD6oMd0RAofeAKCLr3G3/otVvnWjxXKjTR7pKnc5ewCfVqjf 2gPTMz1a3QGThgaqlcpEXkc= =xq2U -----END PGP SIGNATURE----- From vjoel at path.berkeley.edu Thu Apr 19 01:24:18 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Wed, 18 Apr 2007 22:24:18 -0700 Subject: [fxruby-users] test if a window has been destroyed Message-ID: <4626FD02.20806@path.berkeley.edu> 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 From philippe.lang at attiksystem.ch Thu Apr 19 04:59:49 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Thu, 19 Apr 2007 10:59:49 +0200 Subject: [fxruby-users] FXRuby 1.6.11 problems with Ruby 1.8.5? References: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com> Message-ID: <6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch> > All, > > FXRuby version 1.6.11 is now available for download from this page: > > http://rubyforge.org/frs/?group_id=300&release_id=11201 > > This is a bug fix release and is strongly recommended. Note that if > you're building FXRuby from source, you should be using FOX 1.6.16 or > later due to some important changes made in that release of FOX. For > a summary of the changes in this release of FXRuby, please see this > page: > > http://www.fxruby.org/doc/changes.html > > As usual, the code is provided as a Win32 installer or a binary Gem > (both compatible with the latest One-Click Installer for Ruby), as a > source gem, and as a source tarball. For instructions on compiling > FXRuby from source, please see: > > http://www.fxruby.org/doc/build.html > > And as always, the FXRuby home page is here: > > http://www.fxruby.org > > Enjoy, > > Lyle Hi Lyle, I have just given a try to your new FXRuby release, and I have a few problems when my application starts: -------- c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant TRUE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant FALSE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant MAYBE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant NULL c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_NONE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_KEYPRESS c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_KEYRELEASE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_LEFTBUTTONPRESS c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_LEFTBUTTONRELEASE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_MIDDLEBUTTONPRESS c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_MIDDLEBUTTONRELEASE c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning : already initialized constant SEL_RIGHTBUTTONPRESS c:/ruby/lib/ruby/gems/1.8/gems/fxruby-1.6.11-mswin32/ext/fox16/fox16.so: warning -------- I'm using that Ruby version: ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32] Until now, I had no single problem with version 1.6.6. With that new version, I get not only warnings at start, but also other weired things later, like Win32OLE that does not work anymore. But I have to invertigate that a little bit further... Do we need Ruby 1.8.6 maybe? You mention "compatible with the latest One-Click Installer for Ruby" in your announce. 1.8.5 is in not the latest version, but close! Regards, Philippe Lang From meinrad.recheis at gmail.com Thu Apr 19 06:29:01 2007 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Thu, 19 Apr 2007 12:29:01 +0200 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: <4626FD02.20806@path.berkeley.edu> References: <4626FD02.20806@path.berkeley.edu> Message-ID: <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> AFAIK there is the shown? method On 4/19/07, Joel VanderWerf 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 From lyle.johnson at gmail.com Thu Apr 19 09:30:39 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Thu, 19 Apr 2007 08:30:39 -0500 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: <4626FD02.20806@path.berkeley.edu> References: <4626FD02.20806@path.berkeley.edu> Message-ID: On 4/19/07, Joel VanderWerf 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 From lyle.johnson at gmail.com Thu Apr 19 09:48:26 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Thu, 19 Apr 2007 08:48:26 -0500 Subject: [fxruby-users] FXRuby 1.6.11 problems with Ruby 1.8.5? In-Reply-To: <6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch> References: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com> <6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch> Message-ID: On 4/19/07, Philippe Lang wrote: > I have just given a try to your new FXRuby release, and I have a few > problems when my application starts: > I'm using that Ruby version: ruby 1.8.5 (2006-12-25 patchlevel 12) > [i386-mswin32] This bug has been fixed and I can't imagine how it could have snuck back in. Can you tell me which version of the Ruby One-Click Installer you're using, specifically? > Do we need Ruby 1.8.6 maybe? You mention "compatible with the latest > One-Click Installer for Ruby" in your announce. 1.8.5 is in not the > latest version, but close! Well, I *am* compiling everything against the Ruby 1.8.6 include files, and linking against that version of the Ruby library, so it's possible that there are some binary incompatibilities with Ruby 1.8.5. I will try to investigate this later today and see if I can reproduce the bug. From philippe.lang at attiksystem.ch Thu Apr 19 09:54:27 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Thu, 19 Apr 2007 15:54:27 +0200 Subject: [fxruby-users] FXRuby 1.6.11 problems with Ruby 1.8.5? References: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com><6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch> Message-ID: <6C0CF58A187DA5479245E0830AF84F423378E1@poweredge.attiksystem.ch> fxruby-users-bounces at rubyforge.org wrote: > On 4/19/07, Philippe Lang wrote: > >> I have just given a try to your new FXRuby release, and I have a few >> problems when my application starts: > > > >> I'm using that Ruby version: ruby 1.8.5 (2006-12-25 patchlevel 12) >> [i386-mswin32] > > This bug has been fixed and I can't imagine how it could have snuck > back in. Can you tell me which version of the Ruby One-Click > Installer you're using, specifically? Hi, I'm using "ruby185-24.exe". Philippe From lyle.johnson at gmail.com Thu Apr 19 11:49:19 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Thu, 19 Apr 2007 10:49:19 -0500 Subject: [fxruby-users] FXRuby 1.6.11 problems with Ruby 1.8.5? In-Reply-To: <6C0CF58A187DA5479245E0830AF84F423378E1@poweredge.attiksystem.ch> References: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com> <6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch> <6C0CF58A187DA5479245E0830AF84F423378E1@poweredge.attiksystem.ch> Message-ID: On 4/19/07, Philippe Lang wrote: > I'm using "ruby185-24.exe". OK. I can confirm that the problem is there for Ruby 1.8.5 as installed from that version of the one-click installer (ruby186-24.exe). I did a clean install of Ruby, and then the 1.6.11 gem for FXRuby, and saw the mess. I can *also* confirm that the problem is corrected in Ruby 1.8.6, from the latest one-click installer. I was testing the same gem (fxruby-1.6.11-mswin32.gem) in both cases, so the difference is definitely in Ruby and not in FXRuby. So my answer is: Time for you to upgrade to 1.8.6. ;) From vjoel at path.berkeley.edu Thu Apr 19 12:15:02 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 19 Apr 2007 09:15:02 -0700 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: References: <4626FD02.20806@path.berkeley.edu> Message-ID: <46279586.4040900@path.berkeley.edu> Lyle Johnson wrote: > On 4/19/07, Joel VanderWerf 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 A 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 From vjoel at path.berkeley.edu Thu Apr 19 12:58:52 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 19 Apr 2007 09:58:52 -0700 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> References: <4626FD02.20806@path.berkeley.edu> <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> Message-ID: <46279FCC.80307@path.berkeley.edu> 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". -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From meinrad.recheis at gmail.com Thu Apr 19 13:14:07 2007 From: meinrad.recheis at gmail.com (Meinrad Recheis) Date: Thu, 19 Apr 2007 19:14:07 +0200 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: <46279FCC.80307@path.berkeley.edu> References: <4626FD02.20806@path.berkeley.edu> <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> <46279FCC.80307@path.berkeley.edu> Message-ID: <43d756720704191014t79c7f1e1wd65a06ced9bb69f7@mail.gmail.com> On 4/19/07, Joel VanderWerf 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 From lyle.johnson at gmail.com Thu Apr 19 14:18:01 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Thu, 19 Apr 2007 13:18:01 -0500 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: <43d756720704191014t79c7f1e1wd65a06ced9bb69f7@mail.gmail.com> References: <4626FD02.20806@path.berkeley.edu> <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> <46279FCC.80307@path.berkeley.edu> <43d756720704191014t79c7f1e1wd65a06ced9bb69f7@mail.gmail.com> Message-ID: On 4/19/07, Meinrad Recheis 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). From vjoel at path.berkeley.edu Thu Apr 19 15:37:54 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 19 Apr 2007 12:37:54 -0700 Subject: [fxruby-users] test if a window has been destroyed In-Reply-To: References: <4626FD02.20806@path.berkeley.edu> <43d756720704190329m4050cf35k9e488032da9be9ee@mail.gmail.com> <46279FCC.80307@path.berkeley.edu> <43d756720704191014t79c7f1e1wd65a06ced9bb69f7@mail.gmail.com> Message-ID: <4627C512.6030806@path.berkeley.edu> Lyle Johnson wrote: > On 4/19/07, Meinrad Recheis 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 From lyle.johnson at gmail.com Thu Apr 19 15:55:28 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Thu, 19 Apr 2007 14:55:28 -0500 Subject: [fxruby-users] Help with debugging FXRuby on SPARC Message-ID: I might as well ask. ;) Is anyone out there using FXRuby on a SPARC platform and running Linux? http://rubyforge.org/tracker/?func=detail&atid=1223&aid=10226&group_id=300 From philippe.lang at attiksystem.ch Fri Apr 20 01:01:53 2007 From: philippe.lang at attiksystem.ch (Philippe Lang) Date: Fri, 20 Apr 2007 07:01:53 +0200 Subject: [fxruby-users] FXRuby 1.6.11 problems with Ruby 1.8.5? References: <4C60A92C-FAA4-4F84-8BCD-F6671E5253BA@gmail.com><6C0CF58A187DA5479245E0830AF84F4218CE29@poweredge.attiksystem.ch><6C0CF58A187DA5479245E0830AF84F423378E1@poweredge.attiksystem.ch> Message-ID: <6C0CF58A187DA5479245E0830AF84F423378E3@poweredge.attiksystem.ch> fxruby-users-bounces at rubyforge.org wrote: > So my answer is: Time for you to upgrade to 1.8.6. ;) I'll do it! :) Thanks for your help, Regards, Philippe Lang From dstar at pele.cx Sun Apr 22 00:01:02 2007 From: dstar at pele.cx (Shalon Wood) Date: Sat, 21 Apr 2007 23:01:02 -0500 Subject: [fxruby-users] FXProgressBar messages? Message-ID: <871widxdkx.fsf@pele.pele.cx> I'm trying to subclass FXProgressBar and pervert it into a slider (anyone who remembers the original Master of Orion game will understand what I'm doing). Unfortunately, it doesn't seem to send SEL_LEFTBUTTONPRESS or SEL_LEFTBUTTONRELEASE messages, despite being derived from FXWindow via FXFrame. Am I mistaken in thinking that it should send those messages? I assumed that that sort of behaviour would be inherited... Shalon Wood -- From jeroen at fox-toolkit.org Sun Apr 22 11:50:52 2007 From: jeroen at fox-toolkit.org (Jeroen van der Zijp) Date: Sun, 22 Apr 2007 10:50:52 -0500 Subject: [fxruby-users] FXProgressBar messages? In-Reply-To: <871widxdkx.fsf@pele.pele.cx> References: <871widxdkx.fsf@pele.pele.cx> Message-ID: <200704221050.53265.jeroen@fox-toolkit.org> On Saturday 21 April 2007 23:01, Shalon Wood wrote: > > I'm trying to subclass FXProgressBar and pervert it into a slider > (anyone who remembers the original Master of Orion game will > understand what I'm doing). Unfortunately, it doesn't seem to send > SEL_LEFTBUTTONPRESS or SEL_LEFTBUTTONRELEASE messages, despite being > derived from FXWindow via FXFrame. Am I mistaken in thinking that it > should send those messages? I assumed that that sort of behaviour > would be inherited... Enable the widget so that it'll pass mouse messages on to its target! - Jeroen -- +----------------------------------------------------------------------------+ | Copyright (C) 10:50 04/22/2007 Jeroen van der Zijp. All Rights Reserved. | +----------------------------------------------------------------------------+ From dstar at pele.cx Sun Apr 22 12:41:14 2007 From: dstar at pele.cx (Shalon Wood) Date: Sun, 22 Apr 2007 11:41:14 -0500 Subject: [fxruby-users] FXProgressBar messages? In-Reply-To: <200704221050.53265.jeroen@fox-toolkit.org> (Jeroen van der Zijp's message of "Sun, 22 Apr 2007 10:50:52 -0500") References: <871widxdkx.fsf@pele.pele.cx> <200704221050.53265.jeroen@fox-toolkit.org> Message-ID: <878xckwedx.fsf@pele.pele.cx> Jeroen van der Zijp writes: > On Saturday 21 April 2007 23:01, Shalon Wood wrote: >> >> I'm trying to subclass FXProgressBar and pervert it into a slider >> (anyone who remembers the original Master of Orion game will >> understand what I'm doing). Unfortunately, it doesn't seem to send >> SEL_LEFTBUTTONPRESS or SEL_LEFTBUTTONRELEASE messages, despite being >> derived from FXWindow via FXFrame. Am I mistaken in thinking that it >> should send those messages? I assumed that that sort of behaviour >> would be inherited... > > Enable the widget so that it'll pass mouse messages on to its target! Aha! Thanks! I'm just learning to use the toolkit, so I'd missed that I needed to do that. Another question: I want to make a sidebar with its own layout. I thought FXFrame would be the right thing to use, but I can't give it a FXPacker layout because it's not a FXComposite. What am I missing? Shalon Wood -- From vjoel at path.berkeley.edu Thu Apr 26 19:00:25 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 26 Apr 2007 16:00:25 -0700 Subject: [fxruby-users] FXSplitter width is 1 until created Message-ID: <46312F09.90306@path.berkeley.edu> Why is the width of an FXSplitter equal to 1 before the FXSplitter#create method is called? My splitter is configured to have LAYOUT_FILL_X, so wouldn't its width be determined before its children were created? It's not really a big deal, but I was configuring the split based on a preferences file during initialize, and couldn't make it work properly. Doing it in #create is an acceptable workaround. This isn't a problem with FX4Splitter. The splitting is implemented differently (and the split values have different meaning). Somehow, both hSplit and vSplit are available before create. -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From vjoel at path.berkeley.edu Thu Apr 26 19:10:57 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 26 Apr 2007 16:10:57 -0700 Subject: [fxruby-users] FXSplitter width is 1 until created In-Reply-To: <46312F09.90306@path.berkeley.edu> References: <46312F09.90306@path.berkeley.edu> Message-ID: <46313181.9090703@path.berkeley.edu> Joel VanderWerf wrote: > Why is the width of an FXSplitter equal to 1 before the > FXSplitter#create method is called? > > My splitter is configured to have LAYOUT_FILL_X, so wouldn't its width > be determined before its children were created? > > It's not really a big deal, but I was configuring the split based on a > preferences file during initialize, and couldn't make it work properly. > Doing it in #create is an acceptable workaround. > > This isn't a problem with FX4Splitter. The splitting is implemented > differently (and the split values have different meaning). Somehow, both > hSplit and vSplit are available before create. I'm sorry, that bit about FX4Splitter is nonsense. FX4Splitter has width==1 and height==1 before create, as well. What I should have said is that FX4Splitter's splitting mechanism (proportional rather than based on width) makes this irrelevant to my code, which really just wants to set the proportions, and not the widths of the children. I guess FXSplitter (as opp. FX4Splitter) can't work that way because it might have >2 children. So I'll stick with configuring it in #create. -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From vjoel at path.berkeley.edu Thu Apr 26 19:22:29 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Thu, 26 Apr 2007 16:22:29 -0700 Subject: [fxruby-users] FXSplitter width is 1 until created In-Reply-To: <46313181.9090703@path.berkeley.edu> References: <46312F09.90306@path.berkeley.edu> <46313181.9090703@path.berkeley.edu> Message-ID: <46313435.7030708@path.berkeley.edu> Joel VanderWerf wrote: ... > So I'll stick with configuring it in #create. Btw, ruby closures are a very clean way to do this. def on_create(&block) @create_actions ||= [] @create_actions << block end def do_create_actions @create_actions and @create_actions.each do |action| action.call end end def initialize(*) splitter = ... on_create do # <-- this is all I had to change in initialize # configure the splitter based on its width and the preferences # for split proportion end end def create super do_create_actions show end Ok, that's enough noise for a while. -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From lyle.johnson at gmail.com Fri Apr 27 11:56:26 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Fri, 27 Apr 2007 10:56:26 -0500 Subject: [fxruby-users] FXSplitter width is 1 until created In-Reply-To: <46313435.7030708@path.berkeley.edu> References: <46312F09.90306@path.berkeley.edu> <46313181.9090703@path.berkeley.edu> <46313435.7030708@path.berkeley.edu> Message-ID: <88F53679-2272-48C1-9E90-8ABD23D65A6A@gmail.com> On Apr 26, 2007, at 6:22 PM, Joel VanderWerf wrote: > Joel VanderWerf wrote: > ... >> So I'll stick with configuring it in #create. > > Btw, ruby closures are a very clean way to do this. This is a nice hack; I like that it keeps the splitter-specific configuration close to the spot where you actually construct the splitter. Thanks for sharing it! From vjoel at path.berkeley.edu Fri Apr 27 17:52:03 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Fri, 27 Apr 2007 14:52:03 -0700 Subject: [fxruby-users] mdiclient windows do not always activate on click Message-ID: <46327083.9040004@path.berkeley.edu> I just noticed that MDIClient windows do not automatically become current when they receive a mouse click, but only do so if the click happens inside of an enabled widget. This may very well be correct, but if so then what is the right way to handle it, if you want a more familiar window-manager behavior (click to focus)? For example, if you change the mditest.rb example like so... --- mditest.rb 2007-04-18 16:19:59.000000000 -0700 +++ mdi.rb 2007-04-27 14:44:54.000000000 -0700 @@ -134,7 +134,7 @@ scrollwindow = FXScrollWindow.new(mdichild, 0) scrollwindow.verticalScrollBar.setLine(@font.fontHeight) btn = FXButton.new(scrollwindow, TYGER, - :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 600, :height => 1000) + :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 100, :height => 100) btn.font = @font btn.backColor = FXColor::White mdichild ...and then click on the empty area within one of the windows behind the active child, then that window will not be made active. However, adding the line scrollwindow.enabled = true makes the behavior feel more normal (to me). Is there any drawback to enabling things like scroll windows (probably also frames and matrixes, but I haven't tried them)? Is there a better way to handle this? -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 From vjoel at path.berkeley.edu Fri Apr 27 18:13:24 2007 From: vjoel at path.berkeley.edu (Joel VanderWerf) Date: Fri, 27 Apr 2007 15:13:24 -0700 Subject: [fxruby-users] mdiclient windows do not always activate on click In-Reply-To: <46327083.9040004@path.berkeley.edu> References: <46327083.9040004@path.berkeley.edu> Message-ID: <46327584.4060502@path.berkeley.edu> Joel VanderWerf wrote: > I just noticed that MDIClient windows do not automatically become > current when they receive a mouse click, but only do so if the click > happens inside of an enabled widget. This may very well be correct, but > if so then what is the right way to handle it, if you want a more > familiar window-manager behavior (click to focus)? > > For example, if you change the mditest.rb example like so... > > --- mditest.rb 2007-04-18 16:19:59.000000000 -0700 > +++ mdi.rb 2007-04-27 14:44:54.000000000 -0700 > @@ -134,7 +134,7 @@ > scrollwindow = FXScrollWindow.new(mdichild, 0) > scrollwindow.verticalScrollBar.setLine(@font.fontHeight) > btn = FXButton.new(scrollwindow, TYGER, > - :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 600, > :height => 1000) > + :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 100, > :height => 100) > btn.font = @font > btn.backColor = FXColor::White > mdichild > > > ...and then click on the empty area within one of the windows behind the > active child, then that window will not be made active. > > However, adding the line > > scrollwindow.enabled = true > > makes the behavior feel more normal (to me). > > Is there any drawback to enabling things like scroll windows (probably > also frames and matrixes, but I haven't tried them)? > > Is there a better way to handle this? > Here's a candidate. In the FXMDIChild's create method, enable the content window (which I guess is everything but the title bar and border), and handle mousedown: def create(*) super contentWindow.enable contentWindow.connect(SEL_LEFTBUTTONPRESS) do parent.setActiveChild self false end end Unfortunately, a mouse click in (for example) a label inside of the content window doesn't get caught this way. Still looking for something better... -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407