fxruby-users Mailing List for FXRuby (Page 28)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I recently upgraded to Ruby 1.8 , installed  OK, however I have now 
'lost' contact with FXRuby !!
Anybody else have this problem & how to recove my FOX access ??

On Sun, Aug 31, 2003 at 01:42:47AM +0700, oleg dashevskii wrote:

Finally solved the problem. I just forgot to enable the widget :-)
self.enable and voila!

> Well, I'm creating my own widget and it apart from anything else must
> respond to the keyboard.
> 
> As far as I could understand, in this case the widget should tell the
> top window it can receive focus, by redefining the canFocus virtual method.
> That's OK in C++, but when I'm trying to define it in my Ruby code, it
> (as well as canFocus?, but they are just the same, as seen from
> aliases.rb) is never called. So the focus is never gained and
> SEL_KEYPRESS messages don't come.
> 
> To solve this problem I put the setFocus() call to the SEL_ENTER handler
> and it works, but now accelerator keys (defined in the top window menu)
> don't.
> 
> Either this or that, but I want both of them :-)
> 
> --
> be9
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
--
be9

Hello,

Well, I'm creating my own widget and it apart from anything else must
respond to the keyboard.

As far as I could understand, in this case the widget should tell the
top window it can receive focus, by redefining the canFocus virtual method.
That's OK in C++, but when I'm trying to define it in my Ruby code, it
(as well as canFocus?, but they are just the same, as seen from
aliases.rb) is never called. So the focus is never gained and
SEL_KEYPRESS messages don't come.

To solve this problem I put the setFocus() call to the SEL_ENTER handler
and it works, but now accelerator keys (defined in the top window menu)
don't.

Either this or that, but I want both of them :-)

--
be9

Recheis Meinrad wrote:

> if you set padLeft for HorizontalSeparator the Separator is drawn padded 
> at both sides.
> if you set padRight for HorizontalSeparator this doesn't happen.
> analogously for VerticalSep with padTop. (copy-paste??)

Can you provide a short program which demonstrates this bug?

> why to hell did jeroen introduce extra vertical and horizontal classes 
> for separators and frames?

FOX 1.2 introduces a new FXSeparator base class for the 
FXHorizontalSeparator and FXVerticalSeparator classes in order to reduce 
some code duplication.

> makes things more complicated, more static less dynamic.
> and i don't understand why i can't set the separatorStyle dynamically.

Yes, this was an unfortunate omission from the FOX 1.0 API. It has also 
been corrected for FOX 1.2.

lyle,

if you set padLeft for HorizontalSeparator the Separator is drawn padded =
at both sides.
if you set padRight for HorizontalSeparator this doesn't happen.
analogously for VerticalSep with padTop. (copy-paste??)

top and bottom padding is ok for horiz.sep., and so is left and right =
padding with vertical separator.
i cannot tell whether this is a bug in fxruby or in Fox.

why to hell did jeroen introduce extra vertical and horizontal classes =
for separators and frames?
makes things more complicated, more static less dynamic.
and i don't understand why i can't set the separatorStyle dynamically.
ok, enough rant. dont take it seriously. nobody is perfect.

- regards, Henon

Fredrik Jagenheim wrote:

> Does anyone have a better solution to this?
> 
> I thought of downloading the FXRuby source and patch FXSegment.new
> myself, but figured there probably was a better solution I couldn't
> see...

First things first, I will definitely add this kind of constructor for 
both FXSegment and FXArc in the next release. But in the meantime, 
here's a workaround you can use in your code (i.e. that doesn't require 
you or your users to patch FXRuby itself). Add this somewhere at the top:

     require 'fox'

     module Fox
       class FXSegment
         alias old_initialize initialize
         def initialize(a, b, c, d)
           old_initialize
           self.x1 = a; self.y1 = b; self.x2 = c; self.y2 = d
         end
       end
     end

and it should do the trick.

Thanks for the suggestion, and hope this helps,

Lyle

Fredrik Jagenheim wrote:
> Hi,
> 
> I'm going to draw an object which consists of three separate lines.
> 
> I thought of doing it like this:
> 
> (In initialize:)
> @segments = []
> @segments << FXSegment.new(x11, y11, x21, y21)
> @segments << FXSegment.new(x12, y12, x22, y22)
> @segments << FXSegment.new(x13, y13, x23, y23)
> (In draw:)
> gc.drawLineSegments(@segments)
> 
> I'm saving the segments list so I don't have to setup all the lines
> all the time (let's say they're hard to calculate).
> 
> This doesn't work, as FXSegments.new doesn't take arguments, so I'd
> probably have to do it like this:
> 
> segment = FXSegment.new
> segment.x1 = x11
> [...]
> @segments << segment
> segment = FXSegment.new
> [...]
> 
> But then I'd probably rewrite the earlier segment, so I have to:
> 
> segment1 = FXSegment.new
> segment1.x1 = x11
> [...]
> segments << segment1
> segment2 = FXSegment.new
> [...]
> 
> Which ends up quite verbose...
> 
> Does anyone have a better solution to this?
> 
> I thought of downloading the FXRuby source and patch FXSegment.new
> myself, but figured there probably was a better solution I couldn't
> see...

No need to patch, with ruby :) You could redefine FXSegment.new, or do 
something like:

class FXSegment # or put this in your own class or module
   def make_segment(x1,y1,x2,y2)
     seg = FXSegment.new
     seg.x1 = x11
     # etc.
     return seg
   end
end

Hi,

I'm going to draw an object which consists of three separate lines.

I thought of doing it like this:

(In initialize:)
@segments = []
@segments << FXSegment.new(x11, y11, x21, y21)
@segments << FXSegment.new(x12, y12, x22, y22)
@segments << FXSegment.new(x13, y13, x23, y23)
(In draw:)
gc.drawLineSegments(@segments)

I'm saving the segments list so I don't have to setup all the lines
all the time (let's say they're hard to calculate).

This doesn't work, as FXSegments.new doesn't take arguments, so I'd
probably have to do it like this:

segment = FXSegment.new
segment.x1 = x11
[...]
@segments << segment
segment = FXSegment.new
[...]

But then I'd probably rewrite the earlier segment, so I have to:

segment1 = FXSegment.new
segment1.x1 = x11
[...]
segments << segment1
segment2 = FXSegment.new
[...]

Which ends up quite verbose...

Does anyone have a better solution to this?

I thought of downloading the FXRuby source and patch FXSegment.new
myself, but figured there probably was a better solution I couldn't
see...

Thanks in advance,
//F

Recheis Meinrad wrote:

> i am having problems reading the alias attribute fxcolordialog#rgba.
> writing is no problem. also  fxcolordialog#getRGBA is working.
> 
> i have checked the aliases.rb file, but havent found any reason for this.

The reason it's not working is that I misspelled it in the aliases.rb 
file ;) Looks like I transposed the 'b' and the 'g' for both 
FXColorDialog#rgba and FXColorSelector#rgba. Thanks for reporting this bug!

hi,

i am having problems reading the alias attribute fxcolordialog#rgba.
writing is no problem. also  fxcolordialog#getRGBA is working.

i have checked the aliases.rb file, but havent found any reason for =
this.

- Henon

Nathaniel Talbott wrote:

> Well, to reply to myself, it appears that I've discovered the problem. As
> far as I can tell, SEL_UNMAP is called rather inconsistently under Windows
> [1]. However, I discovered that SEL_CONFIGURE will tell me everything I need
> to know (including the answer to the other question I was going to ask). So,
> I think I'm a happy camper for the time being.

Thanks for the bug report, Nathaniel. This sounds like a bug (or a 
"feature") in the FOX library, and so I can't make any guarantee about 
whether the problem with SEL_UNMAP could or would get fixed. Glad to 
hear that catching SEL_CONFIGURE solves the problem, though.

Nathaniel Talbott wrote:

> Hmmm... this problem seems to be getting stranger and=20
> stranger; I ran my main app once and had it NOT work, but=20
> couldn't repeat the problem. It's good to know that it should=20
> work, at least.

Well, to reply to myself, it appears that I've discovered the problem. =
As
far as I can tell, SEL_UNMAP is called rather inconsistently under =
Windows
[1]. However, I discovered that SEL_CONFIGURE will tell me everything I =
need
to know (including the answer to the other question I was going to ask). =
So,
I think I'm a happy camper for the time being.

Thanks,

Nathaniel

[1] Well, I know it's probably very consistent if you know what's it's
supposed to do, but I sure can't figure out what it's supposed to do.

<:((><

Joel VanderWerf wrote:

> I'm getting the UNMAPPED message when I minimize, at least with KDE...

Hmmm... this problem seems to be getting stranger and stranger; I ran my
main app once and had it NOT work, but couldn't repeat the problem. It's
good to know that it should work, at least.

BTW, I forgot to include this in my first email:

  C:\workspaces\se\se-1\win32>ver && ruby -ve 'require "fox"; p
[Fox::fxversion,
  Fox::fxrubyversion]'

  Microsoft Windows 2000 [Version 5.00.2195]
  ruby 1.8.0 (2003-08-04) [i386-mswin32]
  ["1.0.42", "1.0.25"]

Still investigating,

Nathaniel

<:((><

Nathaniel Talbott wrote:
> I feel like I'm going bananas here... I was going to build a simple example
> of another problem I'm having, but cannot for the life of me get my simple
> example to work! I have what I _think_ is the functional equivalent of the
> code below in my main app, and it works fine. However, when I run this code,
> I get the "PRESSED" message from the button but no matter how many times I
> minimize the window, I never get "UNMAPPED":
> 
>   require 'fox'
>   include Fox
> 
>   app = FXApp::new
>   window = FXMainWindow::new(app, "Test", nil, nil, DECOR_ALL, 0, 0, 100,
> 100)
>   window.connect(SEL_UNMAP){p "UNMAPPED"}
>   button = FXButton::new(window, "Test")
>   button.connect(SEL_COMMAND){p "PRESSED"}
>   app.create
>   window.show
>   app.run

I'm getting the UNMAPPED message when I minimize, at least with KDE...

I feel like I'm going bananas here... I was going to build a simple =
example
of another problem I'm having, but cannot for the life of me get my =
simple
example to work! I have what I _think_ is the functional equivalent of =
the
code below in my main app, and it works fine. However, when I run this =
code,
I get the "PRESSED" message from the button but no matter how many times =
I
minimize the window, I never get "UNMAPPED":

  require 'fox'
  include Fox

  app =3D FXApp::new
  window =3D FXMainWindow::new(app, "Test", nil, nil, DECOR_ALL, 0, 0, =
100,
100)
  window.connect(SEL_UNMAP){p "UNMAPPED"}
  button =3D FXButton::new(window, "Test")
  button.connect(SEL_COMMAND){p "PRESSED"}
  app.create
  window.show
  app.run

Oh, and it doesn't seem to matter what event I connect to on the window =
- I
don't get any of them <sigh>. Any help would be greatly appreciated.

Once I have my "Duh!" moment for this code, I'll post the original =
problem I
was having.

Thanks,

Nathaniel

<:((><

Lyle Johnson wrote:

> OK, let me know if I need to take a look at it. I just went back and ran 
> 'stress1.rb', one of the stress test cases from the FXRuby/tests 
> subdirectory and it seemed to hold up fine. [That one basically creates 
> and then trashes a large number of tree items, trying to smoke out 
> GC-related problems.]

I don't think it's a GC problem this time--GC.disable doesn't fix it. 
(Or does ruby always turns GC back on during finalizers?)

Here's the valgrind output, with GC disabled and the -v and 
'-error-limit=no' options:

http://PATH.Berkeley.EDU/~vjoel/tree-bug/tree-no-gc.err

Turning GC off shortens this output to the point where I can read the 
whole thing, but I don't see anything in there that's obviously relevant.

If you want to take a look at the code itself, it's at:

http://PATH.Berkeley.EDU/~vjoel/tree-bug/observable-0.3-alpha.tgz
http://PATH.Berkeley.EDU/~vjoel/tree-bug/foxtails-0.2-alpha.tgz

The buggy code is in foxtails/examples/tree.rb.

You can run it without installing anything. Just unpack both of the 
tarballs under the same dir and then:

cd foxtails-0.2/examples
RUBYLIB='../lib:../../observable-0.3/lib' ruby tree.rb

If you quit immediately (Ctl-Q), there is no segfault.

If you select the first tree item, and then quit, it segfaults, but only 
with ruby 1.8, not 1.7.3.

(BTW, the tree example is kinda interesting, before it dies. It lets you 
have multiple synchronized browsers of trees or even of directed acyclic 
graphs, and it makes it easier to use existing data structures with 
their own child/parent relations and not worry about how they are mapped 
into list items. The browsers are synchronized in the sense that model 
changes (as opp. visual changes) propagate to all browsers. Currently 
the example only has one browser, but I'll make it a MDI before release. 
I'll be releasing this with the next foxtails.)

Lyle Johnson wrote:
> Joel VanderWerf wrote:
> 
>> Has anyone seen this? I'm getting a segfault in a finalizer for a 
>> FXTreeList. It happens in 1.8.0, but not 1.7.3.
>>
>> Here's the backtrace:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
>> 3924        JUMP_TAG(tag);
>> (gdb) bt
>> #0  0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
>> #1  0x080594f1 in rb_exc_raise (mesg=1087374512) at eval.c:3931
>> #2  0x080bfe08 in rb_raise (exc=1075655904,
>>     fmt=0x80dafe0 "wrong argument type %s (expected %s)") at error.c:694
>> #3  0x080befb4 in rb_check_type (x=0, t=135298648) at error.c:254
>> #4  0x40339825 in SWIG_ConvertPtr (obj=1087378452, ptr=0xbfffede0,
>>     ty=0x406d0580, flags=1) at librb.c:403
>> #5  0x405a00c2 in _wrap_FXTreeItem_setFocus (argc=1, argv=0xbfffeff0,
>>     self=1087378452) at treelist_wrap.cpp:685
> 
> 
> <snip>
> 
> I snipped it here because this part alone has some questionable stuff 
> going on. At frame #5, we see that _wrap_FXTreeItem_setFocus() called 
> SWIG_ConvertPtr(), to extract the pointer to the C++ FXTreeItem object 
> from the Ruby FXTreeItem instance. In both frames 4 and 5, the Ruby 
> instance has a VALUE of 1087378452. But then by the time we get to the 
> call to rb_check_type() at frame #3, this value has become zero (x=0).
> 
> Are you running under Linux? Have you tried to valgrind it yet?

Linux Mandrake 9.1. I've never learned to use valgrind (maybe this would 
be a good excuse to do so :))

As you point out, this is very strange. The pc at frame #4 is inside the 
DataGetStruct(obj, ...) macro, which calls rb_check_type() with obj as 
the first arg. But at that point the value has been clobbered somehow.

I'll give valgrind a shot...

Joel VanderWerf wrote:

> Has anyone seen this? I'm getting a segfault in a finalizer for a 
> FXTreeList. It happens in 1.8.0, but not 1.7.3.
> 
> Here's the backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
> 3924        JUMP_TAG(tag);
> (gdb) bt
> #0  0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
> #1  0x080594f1 in rb_exc_raise (mesg=1087374512) at eval.c:3931
> #2  0x080bfe08 in rb_raise (exc=1075655904,
>     fmt=0x80dafe0 "wrong argument type %s (expected %s)") at error.c:694
> #3  0x080befb4 in rb_check_type (x=0, t=135298648) at error.c:254
> #4  0x40339825 in SWIG_ConvertPtr (obj=1087378452, ptr=0xbfffede0,
>     ty=0x406d0580, flags=1) at librb.c:403
> #5  0x405a00c2 in _wrap_FXTreeItem_setFocus (argc=1, argv=0xbfffeff0,
>     self=1087378452) at treelist_wrap.cpp:685

<snip>

I snipped it here because this part alone has some questionable stuff 
going on. At frame #5, we see that _wrap_FXTreeItem_setFocus() called 
SWIG_ConvertPtr(), to extract the pointer to the C++ FXTreeItem object 
from the Ruby FXTreeItem instance. In both frames 4 and 5, the Ruby 
instance has a VALUE of 1087378452. But then by the time we get to the 
call to rb_check_type() at frame #3, this value has become zero (x=0).

Are you running under Linux? Have you tried to valgrind it yet?

Joel VanderWerf wrote:

> If you want to take a look at the code itself, it's at:
> 
> http://PATH.Berkeley.EDU/~vjoel/tree-bug/observable-0.3-alpha.tgz
> http://PATH.Berkeley.EDU/~vjoel/tree-bug/foxtails-0.2-alpha.tgz
> 
> The buggy code is in foxtails/examples/tree.rb.

I can reproduce the bug, but so far haven't been able to track down the 
root cause. I did notice that if I quit the program using the File->Quit 
menu option instead the Ctrl+Q accelerator that I don't get the 
segfault, but the significance of this is still unclear.

At the time of the crash we can see that it's trying to call 
FXTreeItem::setFocus() on one of the tree items. I added some print 
statements to see which tree items are getting garbage-collected (and 
when) and it appears that this tree item is indeed still "alive" at this 
point, so I concur that it doesn't seem to be a GC-related problem.

I also did a quick build against the latest CVS sources for Ruby (post 
1.8.0) but this didn't change anything.

I'm sort-of shooting in the dark at the moment, but will let you know if 
I can figure it out :(

Joel VanderWerf wrote:

> Linux Mandrake 9.1. I've never learned to use valgrind (maybe this would 
> be a good excuse to do so :))

Like most tools, valgrind works great for some debugging expeditions and 
not so well for others. But it is not too hard to use (no recompilation 
or other "instrumentation" of your code required) and is a good one to 
be familiar with.

> As you point out, this is very strange. The pc at frame #4 is inside the 
> DataGetStruct(obj, ...) macro, which calls rb_check_type() with obj as 
> the first arg. But at that point the value has been clobbered somehow.
> 
> I'll give valgrind a shot...

OK, let me know if I need to take a look at it. I just went back and ran 
'stress1.rb', one of the stress test cases from the FXRuby/tests 
subdirectory and it seemed to hold up fine. [That one basically creates 
and then trashes a large number of tree items, trying to smoke out 
GC-related problems.]

Lyle Johnson wrote:

> Are you running under Linux? Have you tried to valgrind it yet?

I'm getting a lot of errors just with 'valgrind ruby hello.rb', but 
'valgrind ruby -e 1' is ok. I guess some of the "uninitialized value" 
warnings are to be expected?

I don't see any "clobbered stack" warnings for my program, but that may 
just be because valgrind stopped showing errors at some point.

Do you have a suppressions file for working with fox?

Has anyone seen this? I'm getting a segfault in a finalizer for a 
FXTreeList. It happens in 1.8.0, but not 1.7.3.

Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
3924        JUMP_TAG(tag);
(gdb) bt
#0  0x0805947b in rb_longjmp (tag=6, mesg=0) at eval.c:3924
#1  0x080594f1 in rb_exc_raise (mesg=1087374512) at eval.c:3931
#2  0x080bfe08 in rb_raise (exc=1075655904,
     fmt=0x80dafe0 "wrong argument type %s (expected %s)") at error.c:694
#3  0x080befb4 in rb_check_type (x=0, t=135298648) at error.c:254
#4  0x40339825 in SWIG_ConvertPtr (obj=1087378452, ptr=0xbfffede0,
     ty=0x406d0580, flags=1) at librb.c:403
#5  0x405a00c2 in _wrap_FXTreeItem_setFocus (argc=1, argv=0xbfffeff0,
     self=1087378452) at treelist_wrap.cpp:685
#6  0x080660b6 in call_cfunc (func=0x405a006c <_wrap_FXTreeItem_setFocus>,
     recv=1087378452, len=0, argc=1, argv=0xbfffeff0) at eval.c:4769
#7  0x0805b37f in rb_call0 (klass=1087138004, recv=1087378452, id=18049,
     oid=0, argc=1, argv=0xbfffeff0, body=0x40cc6460, nosuper=0) at 
eval.c:4906
#8  0x0805bb47 in rb_call (klass=1087138004, recv=1087378452, mid=18049,
     argc=1, argv=0xbfffeff0, scope=1) at eval.c:5123
#9  0x0805bdbd in rb_funcall (recv=1087378452, mid=18049, n=1) at ruby.h:626
#10 0x405392e5 in void FXRbCallVoidMethod<unsigned char>(FXObject*, 
unsigned long, unsigned char) (recv=0x82cc160, func=18049, arg=1 '\001')
     at include/FXRuby.h:285
#11 0x405365a8 in FXRbTreeItem::setFocus(unsigned char) (this=0x82cc160,
     focus=1 '\001') at impl.cpp:901
#12 0x408f9f93 in FXTreeList::removeItem(FXTreeItem*, unsigned char) ()
    from /usr/local/lib/libFOX-1.0.so.0
#13 0x408fa041 in FXTreeList::removeItems(FXTreeItem*, FXTreeItem*, 
unsigned cha---Type <return> to continue, or q <return> to quit---li
r) () from /usr/local/lib/libFOX-1.0.so.0
#14 0x408f9cd6 in FXTreeList::removeItem(FXTreeItem*, unsigned char) ()
    from /usr/local/lib/libFOX-1.0.so.0
#15 0x408fa041 in FXTreeList::removeItems(FXTreeItem*, FXTreeItem*, 
unsigned char) () from /usr/local/lib/libFOX-1.0.so.0
#16 0x408fa08c in FXTreeList::clearItems(unsigned char) ()
    from /usr/local/lib/libFOX-1.0.so.0
#17 0x408fa87a in FXTreeList::~FXTreeList() ()
    from /usr/local/lib/libFOX-1.0.so.0
#18 0x403c47a8 in ~FXRbTreeList (this=0x82c1b70) at 
include/FXRbTreeList.h:193
#19 0x4059a44d in FXRbObject::freefunc(FXObject*) (self=0x82c1b70)
     at markfuncs.cpp:78
#20 0x0806c59a in rb_gc_call_finalizer_at_exit () at gc.c:1607
#21 0x08053609 in ruby_finalize_0 (exp=0xbffff3b0) at eval.c:1333
#22 0x0805377b in ruby_cleanup (ex=0) at eval.c:1368
#23 0x0805388f in ruby_stop (ex=0) at eval.c:1395
#24 0x080538d4 in ruby_run () at eval.c:1407
#25 0x08051c01 in main (argc=2, argv=0xbffff454, envp=0xbffff460) at 
main.c:50
#26 0x400877f7 in __libc_start_main () from /lib/i686/libc.so.6

-- 
Joel VanderWerf                          California PATH, UC Berkeley
mailto:vj...@pa...                     Ph. (510) 231-9446
http://www.path.berkeley.edu                       FAX (510) 231-9565

All,

This is probably stating the obvious, but SourceForge is experiencing 
some pretty serious problems with its mailing list services. It's not 
mentioned (yet) on their "Site Status" page, but I did a quick scan of 
the recent support requests and it looks like there has been an 
avalanche of ML-related problems over the last few days. I don't know if 
this is a SourceForge-specific problem, or if it's just another symptom 
of the malaise that has fallen over the internet in the last week or so ;)

So, please be patient if your posts to the ML seem to be greatly delayed 
-- or worse, rejected -- during this period. They are definitely aware 
of the problem and I'm sure they are working to deal with it as quickly 
as possible.

Thanks,

Lyle

kel...@so... wrote:

> Yup!  I've added the line "icon.create if !icon.created?" before I set 
> the icon and it now works as expected.

It is always safe (and cheap) to call FXIcon#create, even if the icon 
has already been created, so you can drop the "if !icon.created?" part 
if you wish.

As an aside, one of the things I love about Ruby's expressiveness is 
that you could just as well have written that line:

     icon.create unless icon.created?

Sometimes I think 'unless' is one of my favorite Ruby keywords ;)

Cheers,

Lyle

Lyle Johnson writes: 

> kel...@so... wrote: 
> 
>> 3)  I'm a using a "downArrow" and "upArrow" icon to show the header 
>> that's being sorted in my FXIconList.  I create the icons (hold a 
>> reference in an instance variable: ie, @upArrowIcon = 
>> FXICOIcon.new(myApp, File.open("uparrow.ico", "rb").read())) but I don't 
>> use them until a user clicks on the header.  But when I try to set the 
>> icon, I get
>> abnormal program termination
>> WT_App.rb:22: [BUG] Segmentation fault
>> ruby 1.8.0 (2003-08-04) [i386-mswin32]
>> However, if I create the icons and attach them to, say, a menu item, I 
>> can now use them when the user clicks on a header (without changing 
>> anything else).  Is this a GC issue?  Or is it that I'm doing something 
>> wrong?
> 
> You probably need to call create() on those icons first. Please see this 
> question from the FAQ: 
> 
>     http://fox-toolkit.org/faq.html#ILLEGALICON

Yup!  I've added the line "icon.create if !icon.created?" before I set the 
icon and it now works as expected.  Thanks Lyle! 

Karl. 

2003	Jan	Feb	Mar	Apr	May	Jun (75)	Jul (90)	Aug (61)	Sep (56)	Oct (56)	Nov (39)	Dec (83)
2004	Jan (56)	Feb (45)	Mar (61)	Apr (40)	May (95)	Jun (79)	Jul (63)	Aug	Sep (4)	Oct	Nov	Dec

fxruby-users Mailing List for FXRuby (Page 28)

fxruby-users — General-purpose discussion list for FXRuby