The documentation says the FXListBox widget sends the SEL_COMMAND and
SEL_CHANGED messages. It doesn''t say anything about the SEL_PAINT
message, and my test code (below), if correct, shows that FXListBox
doesn''t send that message. Is there a way to cause that message to be
sent? I''m trying to alter the way an FXListBox displays itself.
David Peoples
--- test code start ---
#/usr/bin/env ruby
# Tested on Ruby 1.8.2, FXRuby 1.2.6, Windows XP and SuSE Linux
require ''fox12''
include Fox
class TestWindow < FXMainWindow
include Responder
ID_MYID = FXMainWindow::ID_LAST
def initialize(app)
super(app, "Generic Test", nil, nil, DECOR_ALL, 0, 0, 400, 200)
contents = FXHorizontalFrame.new(self,
LAYOUT_SIDE_TOP|FRAME_NONE|LAYOUT_FILL_X|LAYOUT_FILL_Y|PACK_UNIFORM_WIDTH)
myListBox = FXListBox.new(contents, self, ID_MYID,
FRAME_SUNKEN|FRAME_THICK|LISTBOX_NORMAL|LAYOUT_FIX_WIDTH,
0, 0, 220, 0)
myListBox.appendItem(''An example'')
myListBox.appendItem(''A longer example'')
myListBox.appendItem(''Short'')
myListBox.numVisible = myListBox.numItems
FXMAPFUNC(SEL_CHANGED, TestWindow::ID_MYID, "onChange")
FXMAPFUNC(SEL_PAINT, TestWindow::ID_MYID, "onPaint")
# I tested this originally using myListBox.connect(...)
# then switched to the FXMAPFUNC() version in case the connect()
# behind-the-scenes magic didn''t handle this situation.
end
def create
super
show(PLACEMENT_SCREEN)
end
def onPaint(sender, sel, ptr)
puts "TestWindow.onPaint called."
# This never gets called.
end
def onChange(sender, sel, ptr)
puts "TestWindow.onChange called."
# This gets called as expected.
end
end
application = FXApp.new("Generic Test", "FoxTest")
TestWindow.new(application)
application.create
application.run
--- test code end ---
--
David Peoples davidp@touringcyclist.com
The Touring Cyclist http://www.touringcyclist.com
11816 St. Charles Rock Road, Bridgeton, MO 63044
tel: 314-739-4648 fax: 314-739-4972
On Apr 27, 2005, at 1:21 PM, David Peoples wrote:> The documentation says the FXListBox widget sends the SEL_COMMAND and > SEL_CHANGED messages. It doesn''t say anything about the SEL_PAINT > message, and my test code (below), if correct, shows that FXListBox > doesn''t send that message. Is there a way to cause that message to be > sent? I''m trying to alter the way an FXListBox displays itself.Well, the problem is that FXListBox is what I sometimes refer to as a composite widget: it''s an FXPacker that basically houses a button to pop up an FXList. In fact, if you look at the FOX source code, you''ll see that the FXListBox class doesn''t even have an onPaint() method of its own; it just relies on its child widgets to paint themselves as they normally would. So the short answer is, there''s not a simple way to do this. But to get to the point, what is it about the way that FXListBox displays itself that you''d like to change? Maybe there''s another way to approach this problem...
Hello list,
Let''s pretend I need to create some sort of composite widget... like
a self-contained widget that had a series of other widgets built-in
internally, like combo boxes and textfields. Ideally, I would like
this composite widget to behave like a regular Fox widget and respond
to layout hints.
How would I go about this? Can I do it in FXRuby or does it have to be
done in Fox/C? Do I need to subclass some sort of surface/container widget like
FXScrollArea or FXWindow or can I just use a generic class?
Any direction is appreciated!
Thanks,
--
_/ _/ _/ Jacob Hanson
_/ _/_/_/ mailto:jacdx@jacobhanson.com
_/_/_/ _/ _/ http://www.jacobhanson.com
Jacob Hanson schrieb:>Hello list, > >Let''s pretend I need to create some sort of composite widget... like >a self-contained widget that had a series of other widgets built-in >internally, like combo boxes and textfields. Ideally, I would like >this composite widget to behave like a regular Fox widget and respond >to layout hints. > >How would I go about this? Can I do it in FXRuby or does it have to be >done in Fox/C? Do I need to subclass some sort of surface/container widget like >FXScrollArea or FXWindow or can I just use a generic class? > >Any direction is appreciated! > >Thanks > >Hello Jacob. Yu can actually do this in FXRuby. Usually, you''d subclass a container widget like FXPacker, FXMatrix or FXVerticalFrame. That''s the most preferable way to easily to manage and react child widgets. Even in C++ that''s the best solution since most of the child wigets are going to be automatically destroyed by their parent, then. Regards, Jannis
Sunday, May 8, 2005, 3:09:19 PM, you wrote> Hello Jacob. > Yu can actually do this in FXRuby.> Usually, you''d subclass a container widget like FXPacker, FXMatrix or > FXVerticalFrame. That''s the most > preferable way to easily to manage and react child widgets. Even in C++ > that''s the best solution since > most of the child wigets are going to be automatically destroyed by > their parent, then.Thanks Jannis, I have begun implementing it based off of FXVerticalFrame. Here''s a related question. This widget needs to expand/contract based on the number of items that have been added to it. I can do this after everything is created and call myframe.create; myframe.recalc to update the controls that need to be drawn or hidden and resize my frame accordingly. But! If I attempt to add or remove an item before the rest of the containing window is drawn for the first time, I get a segfault when trying to .create. Is there a way to test if I need to run .create or should I be doing something different? Thanks, Jacob
Jacob Hanson schrieb:>Sunday, May 8, 2005, 3:09:19 PM, you wrote > >>Hello Jacob. >>Yu can actually do this in FXRuby. >> > >>Usually, you''d subclass a container widget like FXPacker, FXMatrix or >>FXVerticalFrame. That''s the most >>preferable way to easily to manage and react child widgets. Even in C++ >>that''s the best solution since >>most of the child wigets are going to be automatically destroyed by >>their parent, then. >> > >Thanks Jannis, > >I have begun implementing it based off of FXVerticalFrame. Here''s a >related question. This widget needs to expand/contract based on the >number of items that have been added to it. I can do this after >everything is created and call myframe.create; myframe.recalc to >update the controls that need to be drawn or hidden and resize my >frame accordingly. But! If I attempt to add or remove an item >before the rest of the containing window is drawn for the first time, >I get a segfault when trying to .create. Is there a way to test if >I need to run .create or should I be doing something different? > >Thanks, > >Jacob >Hi Jacob, When adding/removing items before the parent widget is created you won''t have to call create on them. The creation of the parent widget does that automatically. But when adding/removing items after the parent''s creation you will have to call .create on each new item and call .recalc of the parent widget. The two ways: class YourWidget < FXVerticalFrame def initialize(parent, opts) super end def create super end def addLabel(text) FXLabel.new(self, text) do |label| label.create end self.recalc end end or class YourWidget < FXVerticalFrame def initialize(parent, opts) super texts = Array.new(["text1", "text2", "text3"]) texts.each do |txt| FXLabel.new(self, txt) end end def create super end # Of course, you could use the "addLabel" method here, too. end Hope this helps, Jannis
Thursday, May 12, 2005, 3:32:42 AM, you wrote:> When adding/removing items before the parent widget is created you won''t > have to call > create on them. The creation of the parent widget does that > automatically. But when > adding/removing items after the parent''s creation you will have to call > .create on each new > item and call .recalc of the parent widget.> The two ways:> class YourWidget < FXVerticalFrame > def initialize(parent, opts) > super > end> def create > super > end> def addLabel(text) > FXLabel.new(self, text) do |label| > label.create > end > self.recalc > end > endHi Jannis, This makes sense. This is how my widget is laid out. But, is there a way to make addLabel versatile enough so that I can call it before the parent widget is fully created (not call .create) and also be able to call it after the parent widget is created (do call create)? Or do I need to have two separate methods? The way I have it, if I remove .create from my addLabel method, it will create the initial items I need to create. But, since .create is gone, the items I add after everything is created (e.g. from user input) won''t draw. If I leave .create in, I get a segfault. Is there some sort of flag that tells me that .create has already been run? Thanks, Jacob