fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] Creating new frames

[Phil S. <ps...@oz...>]

Thank you.

I have been struggling with this *much* longer than I would care to admit.



On Wed, 8 Oct 2003, meinrad recheis wrote:

> Phil Sharp wrote:
> > I want to create different entry fields depending upon which button is
> > selected. I would like to do this by calling a function (see example
> > below, pressing <Add> should create one label and one text entry box).
> >
> > This does not work and I thought it was because it was created but hidden,
> > however adding a .show had no effect.
>
> you have to call the create method on all widgets that have been
> instanciated later than your call to application.create.
>
> also you have to call the reaclc method on the containing widget, in
> order to tell it, that it should make its layout new.

Re: [Fxruby-users] Creating new frames

[meinrad r. <mei...@gm...>]

Phil Sharp wrote:
> I want to create different entry fields depending upon which button is
> selected. I would like to do this by calling a function (see example
> below, pressing <Add> should create one label and one text entry box).
> 
> This does not work and I thought it was because it was created but hidden,
> however adding a .show had no effect. 

you have to call the create method on all widgets that have been 
instanciated later than your call to application.create.

also you have to call the reaclc method on the containing widget, in 
order to tell it, that it should make its layout new.
> If someone could enlighten me I
> would appreciate it.
> 
here is your working code:

#!/usr/bin/env ruby

require 'fox'

include Fox

class Test < FXMainWindow
   def initialize(app)
     super(app, "Test", nil, nil, DECOR_ALL, 0, 0, 640, 480, 0, 0)


    body = 
FXVerticalFrame.new(self,LAYOUT_SIDE_TOP|FRAME_RAISED|LAYOUT_FILL_X|LAYOUT_FILL_Y|PACK_UNIFORM_WIDTH 
)


 
topbuttons=FXHorizontalFrame.new(body,LAYOUT_SIDE_TOP|FRAME_RAISED|LAYOUT_FILL_X|PACK_UNIFORM_WIDTH, 
0, 0, 0, 0,20, 20, 20, 20)



     FXButton.new(topbuttons, "Add").connect(SEL_COMMAND) {add(body) }

     FXButton.new(topbuttons, "&Quit", nil, app, FXApp::ID_QUIT)

     end

   def add(body)

     lbl=FXLabel.new(body,"text 1")

     tf=FXTextField.new(body,numcolumns=20)

     lbl.create
     tf.create
     body.recalc
   end



   def create
     super
     show(PLACEMENT_SCREEN)
   end
end


application = FXApp.new("Test", "FoxTest")
Test.new(application)
application.create
application.run

regards,
-- henon

--------------
% cat "food in cans"
cat: can't open food in cans

[Fxruby-users] Creating new frames

[Phil S. <ps...@oz...>]

I want to create different entry fields depending upon which button is
selected. I would like to do this by calling a function (see example
below, pressing <Add> should create one label and one text entry box).

This does not work and I thought it was because it was created but hidden,
however adding a .show had no effect. If someone could enlighten me I
would appreciate it.



#!/usr/bin/env ruby

require 'fox'

include Fox

class Test < FXMainWindow
  def initialize(app)
    super(app, "Test", nil, nil, DECOR_ALL, 0, 0, 640, 480, 0, 0)


   body = FXHorizontalFrame.new(self,
LAYOUT_SIDE_TOP|FRAME_RAISED|LAYOUT_FILL_X|LAYOUT_FILL_Y|PACK_UNIFORM_WIDTH )


    topbuttons=FXHorizontalFrame.new(body,
LAYOUT_SIDE_TOP|FRAME_RAISED|LAYOUT_FILL_X|PACK_UNIFORM_WIDTH, 0, 0, 0, 0,
20, 20, 20, 20)



    FXButton.new(topbuttons, "Add").connect(SEL_COMMAND) {add(body) }

    FXButton.new(topbuttons, "&Quit", nil, app, FXApp::ID_QUIT)

    end


 def add(body)

   FXLabel.new(body,"text 1")

   FXTextField.new(body,numcolumns=20)

   body.show

   end



  def create
    super
    show(PLACEMENT_SCREEN)
  end
end


application = FXApp.new("Test", "FoxTest")
Test.new(application)
application.create
application.run

Re: [Fxruby-users] placing a FXCheckButton inside a FXTable cell

[meinrad r. <mei...@gm...>]

Brett S Hallett wrote:
> I'm trying to set up a FXTable column containing a FXCheckButton so that 
> a user can 'click' in the checkbox to select/deselect a particular row, 
> but I cant find out any details on how to do this.
> 
FXTableItem isn't a child of FXWindow so you cannot have a TableItem 
containing a FXCheckbox.

however, you can use the following method of FXTableItem
icon  	 [RW]   	Icon associated with this cell [FXIcon]
to display a *fake* checkbox.

on SEL_COMMAND of your table change the fake-checkbox-icon to display 
the current checkbox state.

this is a low cost workaround. maybe there are other ways to do it.
cheers,
-- henon

--------------
% cat "food in cans"
cat: can't open food in cans

[Fxruby-users] placing a FXCheckButton inside a FXTable cell

[Brett S H. <dra...@im...>]

I'm trying to set up a FXTable column containing a FXCheckButton so that 
a user can 'click' in the checkbox to select/deselect a particular row, 
but I cant find out any details on how to do this.

So I need to know

a) how to set up the checkbox in a column
b) how to test the boxes status

Any help appreaciated

Re: [Fxruby-users] FXSlider & FXDail

[Joel V. <vj...@PA...>]

meinrad recheis wrote:
> Robert McGovern wrote:
> 
>> Hi there,
>>
>> Came across my first frustration today, I need to be able to increment 
>> by 0.1 and neither FXSlider nor FXDail support that. I know I can get 
>> around this by rescaling the values being used but from my users point 
>> of view I unfortuatly need a "cleaner" solution.
>>
>> I assume this is a problem with Fox itself rather than FXRuby? If so I 
>> wonder if Joeren (?) is open to petition on this.
>>
>> Rob
>>
> hi,
> hey! you are using ruby. you can adopt nearly everything to your needs.
> 
> you could subclass  FXSlider and overwrite the methods so that they 
> accept and return float values. something like this should work (note: 
> untestet code without any errorchecking i.e. div by zero, 
> @float_increment.nil? ...)

I'm probably missing something in the docs or examples, but I'm 
wondering if it is possible to display tick marks along a slider with 
numeric values as accompanying text labels. If so, would it be possible 
to adapt this "fixed point" slider to display the correct labels?

Re: [Fxruby-users] FXSlider & FXDail

[meinrad r. <mei...@gm...>]

Robert McGovern wrote:

> Hi there,
> 
> Came across my first frustration today, I need to be able to increment by 0.1 
> and neither FXSlider nor FXDail support that. I know I can get around this by 
> rescaling the values being used but from my users point of view I unfortuatly 
> need a "cleaner" solution.
> 
> I assume this is a problem with Fox itself rather than FXRuby? If so I wonder 
> if Joeren (?) is open to petition on this.
> 
> Rob
> 
hi,
hey! you are using ruby. you can adopt nearly everything to your needs.

you could subclass  FXSlider and overwrite the methods so that they 
accept and return float values. something like this should work (note: 
untestet code without any errorchecking i.e. div by zero, 
@float_increment.nil? ...)

class Slider < FXSlider
def increment= increment
	super(1)
	@float_increment=increment	
end

def increment
	@float_increment
end

alias :old_value= :value=
alias :old_value :value

def value= set_value
	old_value=(set_value/@float_increment).to_i
end

def value
	oldvalue*@float_increment
end
end #class

others please correct me if i am wrong.
hope this helps,
- henon


--------------
% cat "food in cans"
cat: can't open food in cans

[Fxruby-users] FXSlider & FXDail

[Robert M. <ro...@ta...>]

Hi there,

Came across my first frustration today, I need to be able to increment by 0.1 
and neither FXSlider nor FXDail support that. I know I can get around this by 
rescaling the values being used but from my users point of view I unfortuatly 
need a "cleaner" solution.

I assume this is a problem with Fox itself rather than FXRuby? If so I wonder 
if Joeren (?) is open to petition on this.

Rob

-- 
Personal responsibility is battling extinction.

Re: [Fxruby-users] [ANN] fox-tool - interactive gui builder for fxruby

[Meinrad R. <mei...@gm...>]

Joel VanderWerf wrote:

> meinrad recheis wrote:
>
>> hi fellows,
>>
>> i am proud to be able to release a preview of "fox-tool" which is an 
>> interactive gui builder for fxruby.
>
>
> Hey, wow! Looking forward to using it. I'm trying to get some other 
> people at work to use fox/fxruby/ruby, and a tool like this could be 
> very helpful.
>
> One problem so far: some of the file names on disk are capitalized, 
> but referred to in lower case from the program. I guess it doesn't 
> matter to windows, but unix is picky that way....
>
i will fix this at once as i have also changed all newlines to unix style.
i am going to change the development platform to debian linux, but i am 
not quite at home there yet, so it will last some time until i manage to 
install fox and fxruby hence getting to test it there.

joel: thanks for the feedback!

- henon

--------------
% cat "food in cans"
cat: can't open food in cans
(this describes how i feel when using unix: i know the advantages, but i 
can't profit from them at once)

Re: [Fxruby-users] [ANN] fox-tool - interactive gui builder for fxruby

[Joel V. <vj...@PA...>]

meinrad recheis wrote:
> hi fellows,
> 
> i am proud to be able to release a preview of "fox-tool" which is an 
> interactive gui builder for fxruby.

Hey, wow! Looking forward to using it. I'm trying to get some other 
people at work to use fox/fxruby/ruby, and a tool like this could be 
very helpful.

One problem so far: some of the file names on disk are capitalized, but 
referred to in lower case from the program. I guess it doesn't matter to 
windows, but unix is picky that way....

> --------------
> % cat "food in cans"
> cat: can't open food in cans

Hehe.

[Fxruby-users] [ANN] fox-tool - interactive gui builder for fxruby

[meinrad r. <mei...@gm...>]

hi fellows,

i am proud to be able to release a preview of "fox-tool" which is an 
interactive gui builder for fxruby.
i have used it for the gui of my project at work, so i know it is fit 
enough for a preview. i think it is stable enough for you to play around 
with it (you will find some examples in the "examples" sub directory). 
while the core features are implemented there is still much missing and 
lots of little bugs to fix.


you can download the preview at:
	http://www.rubyforge.org/projects/fox-tool

there is a new baken home page including a users guide at:
	http://fox-tool.rubyforge.org

cheers,
- henon

p.s.: i didn't have time yet to test it on unix, so please let me know 
how it goes there.

--------------
% cat "food in cans"
cat: can't open food in cans

Re: [Fxruby-users] Re: FXRuby tree item bug resolved...

[Lyle J. <ly...@kn...>]

Kevin Burge wrote:

> I just changed my app to use TREELIST_BROWSESELECT (which is what I
> need), and now it chokes on the selectItem in FXTreeList::removeItem
> (right after the setFocus call) when closing the app. :)  (I'm not using
> the .27 CVS version you provided, since it was really just a workaround
> and my workaround (moving the focus on close) works too.)  At any rate,
> doing killSelection doesn't help (probably ignored with BROWSESELECT),
> nor does tree.selectItem(tree.firstItem).   The only workaround in Ruby
> is to call tree.removeItems on application close.  This works even for
> the setFocus problem, so I'm just doing that.

OK, sounds good. I am still playing around with the modifications to 
FXRuby that you suggested, since they seem (to me) to be the appropriate 
way to handle things. Hope to have these available for the next release.

Re: [Fxruby-users] FXTreeList as DND source

[Lyle J. <jl...@cf...>]

Dalibor Sramek wrote:

> May I have one more wish? Could you put down a short example of accessing
> either clipboard or the primary selection from a widget that does not have
> this capability by default.
> When I had no success with the DND I tried to put the data from FXTreeList
> to the clipboard. I looked at the FXText.cpp file for inspiration. However
> it seemed to me that FXTreeList could not acquire neither clipboard nor
> primary selection.
> I believe the mechanism is very similar to DND. Am I right?

Yes, the mechanism is very similar to DnD, but obviously a little 
simpler. Attached is an example of how you might copy something from a 
tree list to the clip board, although as you will see, the fact that the 
clipboard owner is an FXTreeList doesn't have all that much bearing on 
the problem. The key steps are:

  1. Deciding on some mechanism that the user will use to copy
     some application data to the clipboard. By convention, you'll
     probably want to use the Ctrl+C keypress, plus maybe some other
     options like a "Copy" menu command or a toolbar. But that's
     really an orthogonal issue.

  2. First you need to acquire ownership of the clipboard by
     calling acquireClipboard() on some window. As with beginDrag(),
     you use this opportunity to "advertise" what data format(s)
     (a.k.a. drag types) they can request from you.

  3. The clipboard owner sends a SEL_CLIPBOARD_GAINED message to
     its message target to indicate that yes, you acquired the
     clipboard. I don't *think* there's any way for this to fail, so
     it's probably just a formality. But there you go.

  4. The important message is SEL_CLIPBOARD_REQUEST. Like the
     SEL_DND_REQUEST message, this tells you that someone is requesting
     the data and you should cough it up by calling setDNDData().
     Note that in this case, the first argument to setDNDData() is
     FROM_CLIPBOARD instead of FROM_DRAGNDROP.

  5. Finally, if (when) some other window claims the clipboard,
     you'll get a SEL_CLIPBOARD_LOST message.

The attached example is short and sweet, but hopefully it demonstrates 
the important parts.

Hope this helps,

Lyle

[Fxruby-users] Re: FXRuby tree item bug resolved...

[Kevin B. <kev...@sy...>]

Lyle and All,

I just changed my app to use TREELIST_BROWSESELECT (which is what I
need), and now it chokes on the selectItem in FXTreeList::removeItem
(right after the setFocus call) when closing the app. :)  (I'm not using
the .27 CVS version you provided, since it was really just a workaround
and my workaround (moving the focus on close) works too.)  At any rate,
doing killSelection doesn't help (probably ignored with BROWSESELECT),
nor does tree.selectItem(tree.firstItem).   The only workaround in Ruby
is to call tree.removeItems on application close.  This works even for
the setFocus problem, so I'm just doing that.

Kevin

[Fxruby-users] FXTreeList as DND source

[Dalibor S. <da...@in...>]

On Fri, Oct 03, 2003 at 10:54:45AM -0500, Lyle Johnson wrote:
> Yes, it is definitely possible to use a tree list (or most any other 
> widget) as a drag source for DND-aware applications. I apologize that 
> the DnD tutorial in the FXRuby User's Guide really only scratches the 
> surface of how to integrate DnD into applications, etc. -- this is a 
> known shortcoming.

Thank you. I am looking forward to try your code. I think I will just copy it
verbatim to my app ;-)

May I have one more wish? Could you put down a short example of accessing
either clipboard or the primary selection from a widget that does not have
this capability by default.
When I had no success with the DND I tried to put the data from FXTreeList
to the clipboard. I looked at the FXText.cpp file for inspiration. However
it seemed to me that FXTreeList could not acquire neither clipboard nor
primary selection.
I believe the mechanism is very similar to DND. Am I right?

Thanks in advance

Dalibor Sramek

-- 
Dalibor Sramek  http://www.insula.cz/dali  |  In the eyes of cats,
                dal...@in...   |  all things belong to cats.

Re: [Fxruby-users] FXTreeList as DND source

[Lyle J. <jl...@cf...>]

Kevin Burge wrote:

> I'm working on an Explorer-ish interface to our product.  Since I'd like
> to have DND, I'd definitely like to know how this is resolved.  I
> haven't tried DND yet, but I'd like to if possible.  Does fox DND
> interact with the Windows desktop?  I haven't researched that.

Please see the other response to Dalibor about how to manage 
drag-and-drop with a tree list. And of course the DnD documentation at 
the FOX web site, as well as the DnD tutorial in the FXRuby User's Guide.

As for the question about FOX DnD interacting with the Windows desktop, 
I'm less sure. FOX *definitely* doesn't use the OLE DnD interfaces (or 
ActiveX, or whatever name it goes by these days). So I suspect you'd 
need to do a lot of homework to figure out how to drag from FOX-based 
applications into non-FOX Windows applications, if it's possible at all.

Re: [Fxruby-users] FXTreeList as DND source

[Lyle J. <jl...@cf...>]

Dalibor Sramek wrote:

> I would like to make DND source from a FXTreeList. I copied the canvas example 
> from Lyle's DND tutorial and replaced the canvas with my FXTreeList. Then I 
> found that FXTreeList did not get any SEL_MOTION messages. So is it possible to 
> make FXTreeList aDND source in the current FXRuby implementation?

Yes, it is definitely possible to use a tree list (or most any other 
widget) as a drag source for DND-aware applications. I apologize that 
the DnD tutorial in the FXRuby User's Guide really only scratches the 
surface of how to integrate DnD into applications, etc. -- this is a 
known shortcoming.

The good news is that for some FOX widgets, including the FXTreeList, a 
some of the lower-level details of the DnD protocol are hidden away and 
it makes things *slightly* easier than they were for the FXCanvas-based 
example used in the tutorial. Since the coordination of 
SEL_LEFTBUTTONPRESS, SEL_MOTION and SEL_LEFTBUTTONRELEASE on an 
FXTreeList is much more complex than it was for the (basically passive) 
FXCanvas widget, the tree list instead sends SEL_BEGINDRAG, SEL_DRAGGED 
and SEL_ENDDRAG messages to its target. You will only get these messages 
if the user is trying to drag a draggable tree item, and you don't need 
to worry about grabbing (or ungrabbing) the mouse, trying to avoid the 
autoscroll features of the tree list, etc.

Attached is a replacement for the dragsource.rb example program; per 
your request, this one uses a tree list as the source instead of a 
canvas. You should be able to use this version of dragsource.rb along 
with the dragdrop.rb example (i.e. the drop site) as-is, but this time 
you're dragging from tree items with names of colors ("Red", "Green" and 
"Blue"). If you drag the "Blue" tree item and drop it on top of 
dragdrop.rb's canvas, the canvas should turn blue.

Hope this helps,

Lyle

Re: [Fxruby-users] FXTreeList as DND source

[Kevin B. <kev...@sy...>]

Dear All,

I'm working on an Explorer-ish interface to our product.  Since I'd like
to have DND, I'd definitely like to know how this is resolved.  I
haven't tried DND yet, but I'd like to if possible.  Does fox DND
interact with the Windows desktop?  I haven't researched that.

Thanks,

Kevin

On Fri, 2003-10-03 at 04:40, Dalibor Sramek wrote:
> Hi.
> 
> I would like to make DND source from a FXTreeList. I copied the canvas example 
> from Lyle's DND tutorial and replaced the canvas with my FXTreeList. Then I 
> found that FXTreeList did not get any SEL_MOTION messages. So is it possible to 
> make FXTreeList aDND source in the current FXRuby implementation?
> 
> Any success stories with DND?
> 
> Thanks
> 
> Dalibor Sramek

[Fxruby-users] FXTreeList as DND source

[Dalibor S. <da...@in...>]

Hi.

I would like to make DND source from a FXTreeList. I copied the canvas example 
from Lyle's DND tutorial and replaced the canvas with my FXTreeList. Then I 
found that FXTreeList did not get any SEL_MOTION messages. So is it possible to 
make FXTreeList aDND source in the current FXRuby implementation?

Any success stories with DND?

Thanks

Dalibor Sramek

-- 
Dalibor Sramek  http://www.insula.cz/dali  |  In the eyes of cats, 
                dal...@in...   |  all things belong to cats. 

[Fxruby-users] re: accessing FXTable fields

[Brett S H. <dra...@im...>]

Thanks for the input on this subject, I solved the problem using Lyles 
.connect code example.
I  also checked out Dalibor's dbtable
program -- a very useful program for all you Ruby SQL programmers by the 
way.

Thanks again

Re: [Fxruby-users] bug: descending FXTreeItem causes coredump? [LONG]

[Kevin B. <kev...@sy...>]

The short synopsis of the solution is, "make sure that the link between 
> the deceased Ruby object and the still-living C++ object gets broken at 
> the right time", and I'm still trying to decide when that right time is. 
> But I should be able to get a fix in the next day or so, at the latest.

As I mentioned, I have written my own Ruby extension.  I had (and am
still having in one place) the same problem as FXRuby.  The API I
wrapped (manually, not with SWIG) does not keep track of object
references (no parent->child connection, only child->parent), and
expects the programmer to destroy objects in an orderly fashion.  Of
course, Ruby choked on this, since, as you said, at finalization, it
destroys the objects (almost) randomly.  My solution was to make all the
objects remember each other, and whenever a child is destroy, it has the
parent remove it from it's "children", and if the parent is destroyed it
tells all the children to destroy themselves first.

The difference from FXRuby is that I DESTROY the items, even though the
Ruby object may still exist.  The Ruby VALUEs outlive the C objects they
point to, whereas in FXRuby, the C++ objects outlive their Ruby VALUEs.

My reasoning was: as long as I have the marking right, I'll never have
Ruby VALUEs pointing to uninitialized C objects.  At finalization, the
Ruby VALUEs will never be used again, so it doesn't matter at that
point.

Not fully comprehending the FXRuby internals (though I have looked at it
quite a bit):

What I think should happen is that any owned object must use it's
"owner" to remove itself and/or unregister itself.  I.e. in
"delete_if_not_owned", there should be a call to "owner->remove(self)"
just before FXRbUnregisterRubyObj.

Said differently, if Ruby destroys an owned object, the owner should
first UNOWN the object.  So, in the case of the above:

If 4 items are added as children of one another, and the first is freed
by Ruby, it's freefunc should call the TreeList->removeItem(self) BEFORE
it unregisters itself.  This will remove all the children items (and
their unregistering their Ruby objects), etc., etc.

I'd help if I had time.  Gotta finish my FXRuby app! :)

Kevin

Re: [Fxruby-users] bug: descending FXTreeItem causes coredump? [LONG]

[Lyle J. <jl...@cf...>]

Kevin Burge wrote:

> It ONLY fails if the item selected is a DIRECT subitem of an item added
> with addItemList(nil, FXTreeItem.new(...)).

Yes, it turns out that this is just a symptom of a more general problem. 
I think I have identified the basic problem and so now I need to decide 
what is the best solution (decision-making currently in progress ;)

The problem is that when the Ruby interpreter shuts down, it finalizes 
all of the still-alive objects in a more or less random order. In our 
case, it is first finalizing the two tree items, and later the tree list 
itself.

At the time the tree items are finalized in the Ruby interpreter, Ruby 
doesn't "own" the underlying C++ FXTreeItem objects and thus doesn't 
have permission to call the C++ objects' destructors. This situation is 
correctly accounted for in the FXRuby GC code; the Ruby instances go 
away, but the C++ objects hang around. It's not a memory leak since the 
FXTreeList owns those two tree item objects and will dispose of them 
later, when it is destroyed. So far, so good.

Time passes, and now it's time to finalize the tree list in the Ruby 
interpreter. As you have perhaps seen in the FOX source code, the main 
business of FXTreeList's destructor is to recursively destroy all of its 
tree items in a sort of depth-first manner. So it burrows down and 
deletes the lowest-level tree item. And since that item was the current 
item and had the focus, FOX wants to transfer the focus to the new 
current item, namely, the root-level item. It does so by calling the 
root item's virtual setFocus() member function, and that's where the 
trouble starts.

Since setFocus() is a virtual C++ member function, and since it is 
possible that you (the application writer) have overridden that virtual 
function in your Ruby code, we look up the Ruby instance associated with 
this C++ FXTreeItem object. You may recall that this Ruby object was 
finalized earlier and no longer exists, but we still find it in our map 
of C++ objects to Ruby objects, so FXRuby goes ahead and tries to invoke 
a method call (for the potentially-overridden setFocus) on it. This is 
where the seg fault occurs.

The short synopsis of the solution is, "make sure that the link between 
the deceased Ruby object and the still-living C++ object gets broken at 
the right time", and I'm still trying to decide when that right time is. 
But I should be able to get a fix in the next day or so, at the latest.

Re: [Fxruby-users] bug: descending FXTreeItem causes coredump?

[Kevin B. <kev...@sy...>]

Just did some more testing based on this response:


On Tue, 2003-09-30 at 09:47, Lyle Johnson wrote: 
> Guys,
> 
> Next, I tried using the other 
> overload of FXTreeList#addItemLast, i.e.
> 
>      item = tree.addItemLast(@tree, "... just fine")
>      item = tree.addItemLast(item,  "... choke")
> 
> and this version does *not* crash. This suggests (at least) a couple of 
> possibilities that I need to investigate. Will let you know as soon as I 
> have something for you.

It ONLY fails if the item selected is a DIRECT subitem of an item added
with addItemList(nil, FXTreeItem.new(...)).

I.e.:

item = tree.addItemLast(nil, '... just fine')
item = tree.addItemLast(item, FXTreeItem.new('... just fine'))
item = tree.addItemLast(item, '... choke')
item = tree.addItemLast(item, '... just fine')

Hope that helps!

Kevin

Re: [Fxruby-users] bug: descending FXTreeItem causes coredump?

[Lyle J. <jl...@cf...>]

Joel VanderWerf wrote:
> 
> Kevin Burge wrote:
> 
>> To All,
>>
>> I'm having a problem with using descedants of FXTreeItem.  Whatever is
>> causing the problem is hosing FXTreeList::removeItem.  
> 
> 
> I think that's the same bug that I reported here about a month ago, but 
> couldn't isolate very well.

Guys,

Sorry I didn't respond sooner, but I have been sick the last few days. I 
have only started looking at the problem again this morning, but have 
already found one interesting thread to follow. Since both of you were 
using custom subclasses of FXTreeItem, I tried replacing the MyTreeItem 
instances in Kevin's example with regular tree items, i.e.

     item = tree.addItemLast(@tree, FXTreeItem.new("... just fine"))
     item = tree.addItemLast(item,  FXTreeItem.new("... choke"))

The program still crashes as before. Next, I tried using the other 
overload of FXTreeList#addItemLast, i.e.

     item = tree.addItemLast(@tree, "... just fine")
     item = tree.addItemLast(item,  "... choke")

and this version does *not* crash. This suggests (at least) a couple of 
possibilities that I need to investigate. Will let you know as soon as I 
have something for you.

Thanks for your patience,

Lyle

Re: [Fxruby-users] bug: descending FXTreeItem causes coredump?

[Kevin B. <kev...@sy...>]

Joel,

Thanks for the response.  Definitely sounds like the same problem. 
Possible reason that Ctrl-Q and File->Quit act differently: the tree no
longer has the focus.  It ONLY happens when the tree has the focus and a
subitem is selected.

FWIW, I also have developed a Ruby extension (for commerical use).  I
believe there is some kind of bug in Ruby 1.8's cleanup that causes an
infinite loop whenever you try to use rb_io_write (via rb_warn, etc.)
when ruby_finalize_0 has been called, which FXRuby also encounters after
the bad call to SetFocus.  I haven't been able to isolate that, but, it
sure does make finding the actual cause of the MY (and FXRuby's problem)
more difficult.  I ran into this problem because memory was being
trashed (because I was not forcing my objects to clean up orderly, no
matter what object the GC cleaned up first.)

Kevin

On Mon, 2003-09-29 at 16:27, Joel VanderWerf wrote:
> Joel VanderWerf wrote:
> 
> > I think that's the same bug that I reported here about a month ago, but 
> > couldn't isolate very well. Attached is Lyle's response.
> 
> Well, now it is :)
> 
> ______________________________________________________________________