FXRuby : Setting Default Height/Width in an FXList

ruby-talk
1

(3) Hide the parent in an FXSwitcher, and expose the preprepared newParent.

The third stategy depends completely on how much you know at build time -
use an FXSwitcher pane and instead of destroying a frame, just switch the
other one in. Its probably easiest, risks a leak the least (not that there
would be one in FXRuby, of course), and has more clarity than throwing up
new bunches of widgets willy nilly.

HTH
David Naseby

···

-----Original Message-----
From: Jason Persampieri [mailto:jason@persampieri.net]
Sent: Wednesday, 11 December 2002 11:41 AM

Here’s my latest issue:

I’m attempting to wipe everything from one area and
replace it with some other widgets. I have two
strategies.

(1) delete and recreate the parent
(2) delete all the child widgets of parent

2

Yeah… Unfortunately, I’ll need many thousands of
these. And there’s either a memory or speed (or
both)issue with that :slight_smile: Not to mention the user will
be able to dynamically create these steps on their
own.

Jason

— David Naseby david.naseby@eonesolutions.com.au
wrote:

···

-----Original Message-----
From: Jason Persampieri
[mailto:jason@persampieri.net]
Sent: Wednesday, 11 December 2002 11:41 AM

Here’s my latest issue:

I’m attempting to wipe everything from one area and
replace it with some other widgets. I have two
strategies.

(1) delete and recreate the parent
(2) delete all the child widgets of parent
(3) Hide the parent in an FXSwitcher, and expose the
preprepared newParent.

The third stategy depends completely on how much you
know at build time -
use an FXSwitcher pane and instead of destroying a
frame, just switch the
other one in. Its probably easiest, risks a leak the
least (not that there
would be one in FXRuby, of course), and has more
clarity than throwing up
new bunches of widgets willy nilly.

HTH
David Naseby

3

David Naseby wrote:

···

-----Original Message-----
From: Jason Persampieri [mailto:jason@persampieri.net]
Sent: Wednesday, 11 December 2002 11:41 AM

Here’s my latest issue:

I’m attempting to wipe everything from one area and
replace it with some other widgets. I have two
strategies.

(1) delete and recreate the parent
(2) delete all the child widgets of parent
(3) Hide the parent in an FXSwitcher, and expose the preprepared newParent.

The third stategy depends completely on how much you know at build time -
use an FXSwitcher pane and instead of destroying a frame, just switch the
other one in. Its probably easiest, risks a leak the least (not that there
would be one in FXRuby, of course), and has more clarity than throwing up
new bunches of widgets willy nilly.

I agree with David. If you’re creating only a few widgets, the user
probably won’t notice it – FOX is pretty fast at keeping up with
changes in layout and so forth. But if it’s a lot of new widgets you
might want to consider a switcher instead for the reasons David
outlined. There’s an example of how to use the FXSwitcher widget in the
shutter.rb example program.

4

Jason Persampieri wrote:

Yeah… Unfortunately, I’ll need many thousands of
these. And there’s either a memory or speed (or
both)issue with that :slight_smile: Not to mention the user will
be able to dynamically create these steps on their
own.

If you truly need to change the GUI so frequently (i.e. adding and
removing lots of widgets on the fly) you might also consider creating a
lot of them up-front and then just showing or hiding the widgets instead
of actually removing them. With this scenario the memory use for your
application would stay pretty constant and the application should appear
more responsive – it’s very quick to just show and hide widgets :wink:

5

Hmmm… since I have to have a whole bunch of these,
and users can create or delete them, I don’t think
this is really an option… I’d still have a problem
when the user deletes a parameter.

I tried to redefine the getHeight method for my
container, but that didn’t seem to have any affect.
That is, I could call obj.getHeight and it would get
the value from my function, but the parent still sees
the height differently. Does that make sense?

Each widget is an FXParameterRow, which is a class I
made to show a key and value… the current
implementation is a GroupBox titled with the key
containing an FXText box with the edittable value…
whew.

I thought of another option though… If I could do
this as an FXList, that should handle all of the size
issues appropriately… however, it doesn’t seem like
a widget can be an FXListItem (even with
subclassing)… is this correct?

Anyway, I still think that there should be a way to
tell a container to re-evaluate it’s height… and it
should do so automatically after a child gets
destroyed. Wouldn’t that make sense?

Jason

···

— Lyle Johnson lyle@users.sourceforge.net wrote:

I agree with David. If you’re creating only a few
widgets, the user
probably won’t notice it – FOX is pretty fast at
keeping up with
changes in layout and so forth. But if it’s a lot of
new widgets you
might want to consider a switcher instead for the
reasons David
outlined. There’s an example of how to use the
FXSwitcher widget in the
shutter.rb example program.

6

Jason Persampieri wrote:

I tried to redefine the getHeight method for my
container, but that didn’t seem to have any effect.
That is, I could call obj.getHeight and it would get
the value from my function, but the parent still sees
the height differently. Does that make sense?

Yes. The getWidth() and getHeight() functions in the C++ library aren’t
virtual functions and so there’s no point in overriding them in your
Ruby classes. In other words, even if you were writing your GUI in C++
and not in Ruby there wouldn’t be any point in overriding either of
those functions.

If you want a window to have a fixed height, pass in the
LAYOUT_FIX_HEIGHT layout hint when you create it and then set its height
to whatever (fixed) value you like:

 fixedHeightLabel = FXLabel.new(parent, "Label", nil,
     LABEL_NORMAL | LAYOUT_FIX_HEIGHT)
 fixedHeightLabel.height = 50

Each widget is an FXParameterRow, which is a class I
made to show a key and value… the current
implementation is a GroupBox titled with the key
containing an FXText box with the edittable value…
whew.

This sounds fine, but just out of curiosity, you do know that there is
both an FXTextField widget (for single-line text inputs) and FXText (for
multi-line text), right? For what you’re describing, FXTextField is
probably the appropriate choice – it’s like Tk’s Entry widget (but
not like Tk’s Text widget).

I thought of another option though… If I could do
this as an FXList, that should handle all of the size
issues appropriately… however, it doesn’t seem like
a widget can be an FXListItem (even with
subclassing)… is this correct?

Correct. An FXListItem is, more or less, a basic data object and not a
widget as such. It is not (ultimately) derived from FXWindow like
regular widgets are.

Anyway, I still think that there should be a way to
tell a container to re-evaluate it’s height… and it
should do so automatically after a child gets
destroyed. Wouldn’t that make sense?

Generally speaking, containers do re-evaluate their width and height
when a child widget is added or removed (… or hidden or shown, etc.)
If this doesn’t seem to be happening you can force a widget to
recalculate its layout by calling recalc(), e.g.

 FXLabel.new(aContainer, "myLabel")
 FXTextField(aContainer, 6)
 aContainer.recalc

but as I said this usually isn’t necessary.

7

Generally speaking, containers do re-evaluate
their width and height
when a child widget is added or removed (… or
hidden or shown, etc.)
If this doesn’t seem to be happening you can force a
widget to
recalculate its layout by calling recalc(), e.g.

 FXLabel.new(aContainer, "myLabel")
 FXTextField(aContainer, 6)
 aContainer.recalc

but as I said this usually isn’t necessary.

ok… try this… it shows what I’m talking about.
When the FXText’s are deleted, the scrollbar doesn’t
change.

require ‘fox’
include Fox

class MyMainWindow < FXMainWindow
def initialize(app)
super(app, “Delete Children Test”, nil, nil,
DECOR_ALL, 0, 0, 200, 100)

	#layout screen
	button = FXButton.new(self, "Push me.")
	scrollFrame = FXScrollWindow.new(self,

LAYOUT_FILL_X|LAYOUT_FILL_Y)
@frame = FXVerticalFrame.new(scrollFrame,
FRAME_SUNKEN)
FXText.new(@frame)
FXText.new(@frame)
FXText.new(@frame)
FXText.new(@frame)
FXText.new(@frame)
FXText.new(@frame)

	button.connect(SEL_COMMAND, method(:onButton))
end

def create
	super
	show(PLACEMENT_SCREEN)
end

def onButton(sender, sel, item)
	0.upto(@frame.numChildren-1) do |childNum|
		@frame.childAtIndex(childNum).destroy
	end
	@frame.recalc
end

end

theApp = FXApp.new(“Foo”)
theApp.init(ARGV)

myWindow = MyMainWindow.new(theApp)

theApp.create
theApp.run

8

Jason Persampieri wrote:

ok… try this… it shows what I’m talking about.
When the FXText’s are deleted, the scrollbar doesn’t
change.

I’m assuming you have not yet read one of my previous responses in this
thread about using FXWindow#removeChild instead of FXWindow#destroy.
(Unfortunately it looks to be too recent to have been archived on
ruby-talk so I can’t post a link to it :wink:

In any event, change your onButton() method to look like this:

 def onButton(sender, sel, ptr)
   (@frame.numChildren - 1).downto(0) do |childNum|
     @frame.removeChild(@frame.childAtIndex(childNum))
   end
 end

and you should get the expected result. To find out why, wait for that
response to show up on your news server (or to get gated to the mailing
list).

9

Woot!

This completely fixes my problem.

I KNEW a method like that had to exist, but it wasn’t
documented in the ‘class index’ on the official FOX
site. Is there a more complete FOX/FXRuby reference
around (besides trudging through the code)?

Jason

···

— Lyle Johnson lyle@users.sourceforge.net wrote:

Jason Persampieri wrote:

ok… try this… it shows what I’m talking about.

When the FXText’s are deleted, the scrollbar
doesn’t
change.

I’m assuming you have not yet read one of my
previous responses in this
thread about using FXWindow#removeChild instead of
FXWindow#destroy.
(Unfortunately it looks to be too recent to have
been archived on
ruby-talk so I can’t post a link to it :wink:

In any event, change your onButton() method to look
like this:

 def onButton(sender, sel, ptr)
   (@frame.numChildren - 1).downto(0) do

childNum>

@frame.removeChild(@frame.childAtIndex(childNum))
end
end

and you should get the expected result. To find out
why, wait for that
response to show up on your news server (or to get
gated to the mailing
list).

10

Jason Persampieri wrote:

I KNEW a method like that had to exist, but it wasn’t
documented in the ‘class index’ on the official FOX
site. Is there a more complete FOX/FXRuby reference
around (besides trudging through the code)?

Nope. I am, very slowly, putting together some RDoc-style documentation
for the FXRuby API. It’s very similar to the regular C++ library API but
there are little differences like this one.