fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] Icons: Are any standard? where?

[Hugh S. S. E. E. <hg...@dm...>]

On Tue, 15 Jul 2003, Lyle Johnson wrote:

> Sander Jansen wrote:
>
>  > Could you elaborate a little bit more on this? FOX Supports any size
> as far as
>  > I know...
>
> Whoops, Sander is absolutely right. Icons can be of any size. I must
> have been thinking about cursors (which IIRC must be 32x32).
>

OK, thanks.  And getting a huge cursor under X is a long story too!
(Been there, done that, send corrections to Blinux faq! :-))

        Hugh
>

Re: [Fxruby-users] Icons: Are any standard? where?

[Hugh S. S. E. E. <hg...@dm...>]

On Tue, 15 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > Now I have the beginnings of my TreeList working, I'd like to add
> > icons to it.  There are some folder icons in the examples.  Am I
> > free to use these in my software?
>
> Yes.

Thank you.
>
> > Are there stock icons that come with Fox which can be accessed portably?
>
> I wouldn't call them "stock" icons. If you look in various

Is that perjorative?  Onelook dictionary gives the meaning I meant:
adjective:   regularly and widely used or sold (Example: "A stock
item")
which doesn't seem perjorative.

> subdirectories of the FOX distribution you will find some image files
> that are used for application icons (e.g. those for the Adie text editor
> application), and you are free to use those.

I did see a few, but no evidence of a central place to keep them,
etc.
>
> > Are there any FXRuby icon editors out there yet, as I will
>  > need to roll some of my own anyway for this application?
>
> You don't need an FXRuby-specific icon editing program, as icons are

True, but I need a program from a reputable community, I bet Icon
editors and similar are a good way to pickup spyware...  The GNU
imaging programs, OTOH, seem to go:
get gtk+, which requires libungif, which requires libpng, which
requires zlib which I can't get to build.
[Harris, R: "The Court of King Caractacus"] :-)

> always constructed from standard image file formats (e.g. GIF, BMP, PNG,
> ...). There are about a million free icon/image editing programs out
> there, for both Windows and Linux. Or you can take my lazy man's

Bewildered by choice, also searching turns up MUCH shareware, and I
really don't want to get into the international money exchange
problem again!  :-)

> approach and just look for free icons that someone else has already drawn.

Tried that, but I've found it difficult to search the licencing
aspects as well as the image with Google.  Maybe a better engine
exists for this pupose?
>
> Do keep in mind that icons need to be either 16x16 or 32x32; these are
> standard sizes and IIRC it's a limitation of the underlying Window
> systems that they be this size.

thanks for this extra point.
>
> Hope this helps,
>
> Lyle
>
        Thank you.
        Hugh
>

Re: [Fxruby-users] Icons: Are any standard? where?

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

Sander Jansen wrote:

 >> Do keep in mind that icons need to be either 16x16 or 32x32; these are
 >> standard sizes and IIRC it's a limitation of the underlying Window
 >> systems that they be this size.
 >
 > Could you elaborate a little bit more on this? FOX Supports any size 
as far as
 > I know...

Whoops, Sander is absolutely right. Icons can be of any size. I must
have been thinking about cursors (which IIRC must be 32x32).

Re: [Fxruby-users] Icons: Are any standard? where?

[Sander J. <sx...@cf...>]

> Do keep in mind that icons need to be either 16x16 or 32x32; these are
> standard sizes and IIRC it's a limitation of the underlying Window
> systems that they be this size.

Could you elaborate a little bit more on this? FOX Supports any size as f=
ar as=20
I know...

=09Sander


>
> Hope this helps,
>
> Lyle
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users

Re: [Fxruby-users] Icons: Are any standard? where?

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

Hugh Sasse Staff Elec Eng wrote:

> Now I have the beginnings of my TreeList working, I'd like to add
> icons to it.  There are some folder icons in the examples.  Am I
> free to use these in my software?

Yes.

> Are there stock icons that come with Fox which can be accessed portably?

I wouldn't call them "stock" icons. If you look in various 
subdirectories of the FOX distribution you will find some image files 
that are used for application icons (e.g. those for the Adie text editor 
application), and you are free to use those.

> Are there any FXRuby icon editors out there yet, as I will
 > need to roll some of my own anyway for this application?

You don't need an FXRuby-specific icon editing program, as icons are 
always constructed from standard image file formats (e.g. GIF, BMP, PNG, 
...). There are about a million free icon/image editing programs out 
there, for both Windows and Linux. Or you can take my lazy man's 
approach and just look for free icons that someone else has already drawn.

Do keep in mind that icons need to be either 16x16 or 32x32; these are 
standard sizes and IIRC it's a limitation of the underlying Window 
systems that they be this size.

Hope this helps,

Lyle

[Fxruby-users] Icons: Are any standard? where?

[Hugh S. S. E. E. <hg...@dm...>]

Now I have the beginnings of my TreeList working, I'd like to add
icons to it.  There are some folder icons in the examples.  Am I
free to use these in my software?  Are there stock icons that come
with Fox which can be accessed portably?  Are there any FXRuby
icon editors out there yet, as I will need to roll some of my own
anyway for this application?

        Thank you,
        Hugh

Re: [Fxruby-users] random crashes with FXTable

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

Emmanuel Touzery wrote:

> since the crashes are random (i basically trigger them by clicking all over
> the place, scrolling etc for few minutes.. otherwise they happen anyway
> after a while of using the program), i don't really know what to do. i can
> give my script if you are interested, but it's 1400 lines (but it's very
> simple, really nothing complicated, most of the code is actually GUI code to
> place the buttons etc).

Yes, it would probably be best if you sent me the code off-line. Also 
some instructions (as specific as possible) about how to reproduce the 
problem. I can see from the Linux stack trace where it's crashing but 
that doesn't tell me *why* it's crashing there ;)

> i'm putting about 270 elements on two columns in the table.

That should be no problem.

> i'm using the windows version of ruby-fox given with the binary installer:
> 1.0.24.

Yes, that's the most recent release.

[Fxruby-users] Re: random crashes with FXTable

[Emmanuel T. <emm...@wa...>]

[didn't receive back this message 50 min after sending it.. sending again]
Hello,

    I have a fxruby project in which i have random crashes definitely
connected to the FXTable widget. It might very well be my code, in the case
i would put invalid values in the table. but the crash is not happening when
i do anything to the table. the crash is in the FOX event loop, when my code
is doing nothing special. then FOX crashes. on the terminal is written:

-----------------
glossary.rbw:434: [BUG] Segmentation fault
ruby 1.6.7 (2002-03-01) [i586-mswin32]

abnormal program termination
-----------------

unfortunately at this line is :
application.run


since the crashes are random (i basically trigger them by clicking all over
the place, scrolling etc for few minutes.. otherwise they happen anyway
after a while of using the program), i don't really know what to do. i can
give my script if you are interested, but it's 1400 lines (but it's very
simple, really nothing complicated, most of the code is actually GUI code to
place the buttons etc).
i'm putting about 270 elements on two columns in the table.

could i get more info about the crash by doing some kind of "ruby -trace
glossary.rbw" or something like that?

i'm using the windows version of ruby-fox given with the binary installer:
1.0.24.

on a related note, i also get crashes on linux on the same application, but
with the most recent version of ruby-fox, compiled by hand. this time the
crashes are absolutely systematic and 100% reproductible, and they do depend
on the actions of my script (eg it crashes when i do things with the table),
so i guess they are different. but maybe it's the same cause, only this more
recent version of FXRuby reacts differently on my script. so for the
reference i mention it in this mail too.

i ran it with GDB, and got the following stack trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4531)]
0x00000029 in ?? ()
(gdb) bt
#0  0x00000029 in ?? ()
#1  0x08050f53 in search_method (klass=1086528144, id=33433,
origin=0xbfffdf64)
    at eval.c:275
#2  0x08050f9e in rb_get_method_body (klassp=0xbfffdfb0, idp=0xbfffdf94,
noexp=0xbfffdf
    at eval.c:293
#3  0x0805a824 in rb_call (klass=1086528144, recv=1086528444, mid=33433,
argc=6,
    argv=0xbfffdfd0, scope=1) at eval.c:4617
#4  0x0805ab89 in rb_funcall (recv=1086528444, mid=33433, n=6) at
eval.c:4714
#5  0x405dfd37 in void FXRbCallVoidMethod<FXTable const *, FXDC, int, int,
int, int> (
    recv=0x82cfdd0, func=33433, arg1=0x824bbd0, arg2=@0xbfffea50, arg3=0,
arg4=20,
    arg5=178, arg6=20) at include/FXRuby.h:346
#6  0x4052a211 in FXRbTableItem::draw (this=0x82cfdd0, table=0x824bbd0,
dc=@0xbfffea50,
    x=0, y=20, w=178, h=20) at impl.cpp:830
#7  0x40888ec1 in FXTable::drawCell () from /usr/local/lib/libFOX-1.0.so.0
#8  0x4052b21d in FXRbTable::public_drawCell (this=0x824bbd0,
dc=@0xbfffea50,
xlo=1,
    xhi=263, ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at
impl.cpp:838
#9  0x405d7234 in FXTable_drawCell (self=0x824bbd0, dc=@0xbfffea50, xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at
include/inlinestubs.h:837
#10 0x404ad8f5 in _wrap_FXTable_drawCell (argc=11, argv=0xbfffe420,
self=1086938632)
    at table_wrap.cpp:1758
#11 0x08059c29 in call_cfunc (
    func=0x404ad5b0 <_wrap_FXTable_drawCell(int, unsigned long *, unsigned
long)>,
    recv=1086938632, len=-1, argc=11, argv=0xbfffe420) at eval.c:4279
#12 0x0805a142 in rb_call0 (klass=1086585724, recv=1086938632, id=34881,
argc=11,
    argv=0xbfffe420, body=0x40c3df20, nosuper=1) at eval.c:4416
#13 0x0805a945 in rb_call (klass=1086585724, recv=1086938632, mid=34881,
argc=11,
    argv=0xbfffe420, scope=1) at eval.c:4640
#14 0x0805ab89 in rb_funcall (recv=1086938632, mid=34881, n=11) at
eval.c:4714
#15 0x405dfeb9 in
FXRbCallVoidMethod__H11Z4FXDCZiZiZiZiZiZiZiZiZiZi_P8FXObjectUlRX01X11X21X31X
41X51X61X71X81X91X_10_1_v
(recv=0x824bbd0, func=34881, arg1=@0xbfffea50, arg2=1,
    arg3=263, arg4=21, arg5=176, arg6=0, arg7=0, arg8=1, arg9=2, arg10=0,
arg11=1)
    at include/FXRuby.h:363
#16 0x4052b1d3 in FXRbTable::drawCell (this=0x824bbd0, dc=@0xbfffea50,
xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at impl.cpp:838
#17 0x4088948f in FXTable::drawRange () from /usr/local/lib/libFOX-1.0.so.0
#18 0x4052b2cd in FXRbTable::public_drawRange (this=0x824bbd0,
dc=@0xbfffea50,
xlo=1,
    xhi=263, ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2)
    at impl.cpp:838
#19 0x405d7304 in FXTable_drawRange (self=0x824bbd0, dc=@0xbfffea50, xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2)
    at include/inlinestubs.h:837
#20 0x404adc55 in _wrap_FXTable_drawRange (argc=11, argv=0xbfffe8b0,
self=1086938632)
    at table_wrap.cpp:1766
#21 0x08059c29 in call_cfunc (
    func=0x404ad910 <_wrap_FXTable_drawRange(int, unsigned long *, unsigned
long)>,
    recv=1086938632, len=-1, argc=11, argv=0xbfffe8b0) at eval.c:4279
#22 0x0805a142 in rb_call0 (klass=1086585724, recv=1086938632, id=34889,
argc=11,
    argv=0xbfffe8b0, body=0x40c3def8, nosuper=1) at eval.c:4416
#23 0x0805a945 in rb_call (klass=1086585724, recv=1086938632, mid=34889,
argc=11,
    argv=0xbfffe8b0, scope=1) at eval.c:4640
#24 0x0805ab89 in rb_funcall (recv=1086938632, mid=34889, n=11) at
eval.c:4714
#25 0x405dfeb9 in
FXRbCallVoidMethod__H11Z4FXDCZiZiZiZiZiZiZiZiZiZi_P8FXObjectUlRX01X11X21X31X
41X51X61X71X81X91X_10_1_v
(recv=0x824bbd0, func=34889, arg1=@0xbfffea50, arg2=1,
    arg3=263, arg4=21, arg5=176, arg6=0, arg7=0, arg8=1, arg9=263, arg10=0,
arg11=2)
    at include/FXRuby.h:363
#26 0x4052b283 in FXRbTable::drawRange (this=0x824bbd0, dc=@0xbfffea50,
xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2) at
impl.cpp:838
#27 0x40889a33 in FXTable::onPaint () from /usr/local/lib/libFOX-1.0.so.0
#28 0x408849f0 in FXTable::handle () from /usr/local/lib/libFOX-1.0.so.0
#29 0x403af3e9 in FXRbTable::handle (this=0x824bbd0, sender=0x8223c98,
key=1048576,
    ptr=0x8223d24) at include/impl.h:147
#30 0x40780c00 in FXApp::dispatchEvent () from
/usr/local/lib/libFOX-1.0.so.0
#31 0x407831ad in FXApp::runOneEvent () from /usr/local/lib/libFOX-1.0.so.0
#32 0x40782eb3 in FXApp::run () from /usr/local/lib/libFOX-1.0.so.0
#33 0x403dc682 in _wrap_FXApp_run (argc=0, argv=0x0, self=1086941032)
    at core_wrap.cpp:2027
#34 0x08059c29 in call_cfunc (
    func=0x403dc610 <_wrap_FXApp_run(int, unsigned long *, unsigned long)>,
    recv=1086941032, len=-1, argc=0, argv=0x0) at eval.c:4279
#35 0x0805a142 in rb_call0 (klass=1075556540, recv=1086941032, id=5713,
argc=0, argv=0x0,
    body=0x401babf8, nosuper=1) at eval.c:4416
#36 0x0805a945 in rb_call (klass=1075556540, recv=1086941032, mid=5713,
argc=0, argv=0x0,
    scope=0) at eval.c:4640
#37 0x08055a2c in rb_eval (self=1075670240, n=0x401c9a40) at eval.c:2572
#38 0x0805241c in ruby_run () at eval.c:1230
#39 0x08050bbe in main (argc=2, argv=0xbffff65c, envp=0xbffff668) at
main.c:50
#40 0x400960de in __libc_start_main () from /lib/libc.so.6

i really love what i saw about fxruby so far, please help me on this!

emmanuel

[Fxruby-users] random crashes with FXTable

[Emmanuel T. <emm...@wa...>]

Hello,

    I have a fxruby project in which i have random crashes definitely
connected to the FXTable widget. It might very well be my code, in the case
i would put invalid values in the table. but the crash is not happening when
i do anything to the table. the crash is in the FOX event loop, when my code
is doing nothing special. then FOX crashes. on the terminal is written:

-----------------
glossary.rbw:434: [BUG] Segmentation fault
ruby 1.6.7 (2002-03-01) [i586-mswin32]

abnormal program termination
-----------------

unfortunately at this line is :
application.run


since the crashes are random (i basically trigger them by clicking all over
the place, scrolling etc for few minutes.. otherwise they happen anyway
after a while of using the program), i don't really know what to do. i can
give my script if you are interested, but it's 1400 lines (but it's very
simple, really nothing complicated, most of the code is actually GUI code to
place the buttons etc).
i'm putting about 270 elements on two columns in the table.

could i get more info about the crash by doing some kind of "ruby -trace
glossary.rbw" or something like that?

i'm using the windows version of ruby-fox given with the binary installer:
1.0.24.

on a related note, i also get crashes on linux on the same application, but
with the most recent version of ruby-fox, compiled by hand. this time the
crashes are absolutely systematic and 100% reproductible, and they do depend
on the actions of my script (eg it crashes when i do things with the table),
so i guess they are different. but maybe it's the same cause, only this more
recent version of FXRuby reacts differently on my script. so for the
reference i mention it in this mail too.

i ran it with GDB, and got the following stack trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 4531)]
0x00000029 in ?? ()
(gdb) bt
#0  0x00000029 in ?? ()
#1  0x08050f53 in search_method (klass=1086528144, id=33433,
origin=0xbfffdf64)
    at eval.c:275
#2  0x08050f9e in rb_get_method_body (klassp=0xbfffdfb0, idp=0xbfffdf94,
noexp=0xbfffdf
    at eval.c:293
#3  0x0805a824 in rb_call (klass=1086528144, recv=1086528444, mid=33433,
argc=6,
    argv=0xbfffdfd0, scope=1) at eval.c:4617
#4  0x0805ab89 in rb_funcall (recv=1086528444, mid=33433, n=6) at
eval.c:4714
#5  0x405dfd37 in void FXRbCallVoidMethod<FXTable const *, FXDC, int, int,
int, int> (
    recv=0x82cfdd0, func=33433, arg1=0x824bbd0, arg2=@0xbfffea50, arg3=0,
arg4=20,
    arg5=178, arg6=20) at include/FXRuby.h:346
#6  0x4052a211 in FXRbTableItem::draw (this=0x82cfdd0, table=0x824bbd0,
dc=@0xbfffea50,
    x=0, y=20, w=178, h=20) at impl.cpp:830
#7  0x40888ec1 in FXTable::drawCell () from /usr/local/lib/libFOX-1.0.so.0
#8  0x4052b21d in FXRbTable::public_drawCell (this=0x824bbd0,
dc=@0xbfffea50,
xlo=1,
    xhi=263, ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at
impl.cpp:838
#9  0x405d7234 in FXTable_drawCell (self=0x824bbd0, dc=@0xbfffea50, xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at
include/inlinestubs.h:837
#10 0x404ad8f5 in _wrap_FXTable_drawCell (argc=11, argv=0xbfffe420,
self=1086938632)
    at table_wrap.cpp:1758
#11 0x08059c29 in call_cfunc (
    func=0x404ad5b0 <_wrap_FXTable_drawCell(int, unsigned long *, unsigned
long)>,
    recv=1086938632, len=-1, argc=11, argv=0xbfffe420) at eval.c:4279
#12 0x0805a142 in rb_call0 (klass=1086585724, recv=1086938632, id=34881,
argc=11,
    argv=0xbfffe420, body=0x40c3df20, nosuper=1) at eval.c:4416
#13 0x0805a945 in rb_call (klass=1086585724, recv=1086938632, mid=34881,
argc=11,
    argv=0xbfffe420, scope=1) at eval.c:4640
#14 0x0805ab89 in rb_funcall (recv=1086938632, mid=34881, n=11) at
eval.c:4714
#15 0x405dfeb9 in
FXRbCallVoidMethod__H11Z4FXDCZiZiZiZiZiZiZiZiZiZi_P8FXObjectUlRX01X11X21X31X
41X51X61X71X81X91X_10_1_v
(recv=0x824bbd0, func=34881, arg1=@0xbfffea50, arg2=1,
    arg3=263, arg4=21, arg5=176, arg6=0, arg7=0, arg8=1, arg9=2, arg10=0,
arg11=1)
    at include/FXRuby.h:363
#16 0x4052b1d3 in FXRbTable::drawCell (this=0x824bbd0, dc=@0xbfffea50,
xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, sr=1, er=2, sc=0, ec=1) at impl.cpp:838
#17 0x4088948f in FXTable::drawRange () from /usr/local/lib/libFOX-1.0.so.0
#18 0x4052b2cd in FXRbTable::public_drawRange (this=0x824bbd0,
dc=@0xbfffea50,
xlo=1,
    xhi=263, ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2)
    at impl.cpp:838
#19 0x405d7304 in FXTable_drawRange (self=0x824bbd0, dc=@0xbfffea50, xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2)
    at include/inlinestubs.h:837
#20 0x404adc55 in _wrap_FXTable_drawRange (argc=11, argv=0xbfffe8b0,
self=1086938632)
    at table_wrap.cpp:1766
#21 0x08059c29 in call_cfunc (
    func=0x404ad910 <_wrap_FXTable_drawRange(int, unsigned long *, unsigned
long)>,
    recv=1086938632, len=-1, argc=11, argv=0xbfffe8b0) at eval.c:4279
#22 0x0805a142 in rb_call0 (klass=1086585724, recv=1086938632, id=34889,
argc=11,
    argv=0xbfffe8b0, body=0x40c3def8, nosuper=1) at eval.c:4416
#23 0x0805a945 in rb_call (klass=1086585724, recv=1086938632, mid=34889,
argc=11,
    argv=0xbfffe8b0, scope=1) at eval.c:4640
#24 0x0805ab89 in rb_funcall (recv=1086938632, mid=34889, n=11) at
eval.c:4714
#25 0x405dfeb9 in
FXRbCallVoidMethod__H11Z4FXDCZiZiZiZiZiZiZiZiZiZi_P8FXObjectUlRX01X11X21X31X
41X51X61X71X81X91X_10_1_v
(recv=0x824bbd0, func=34889, arg1=@0xbfffea50, arg2=1,
    arg3=263, arg4=21, arg5=176, arg6=0, arg7=0, arg8=1, arg9=263, arg10=0,
arg11=2)
    at include/FXRuby.h:363
#26 0x4052b283 in FXRbTable::drawRange (this=0x824bbd0, dc=@0xbfffea50,
xlo=1,
xhi=263,
    ylo=21, yhi=176, xoff=0, yoff=0, rlo=1, rhi=263, clo=0, chi=2) at
impl.cpp:838
#27 0x40889a33 in FXTable::onPaint () from /usr/local/lib/libFOX-1.0.so.0
#28 0x408849f0 in FXTable::handle () from /usr/local/lib/libFOX-1.0.so.0
#29 0x403af3e9 in FXRbTable::handle (this=0x824bbd0, sender=0x8223c98,
key=1048576,
    ptr=0x8223d24) at include/impl.h:147
#30 0x40780c00 in FXApp::dispatchEvent () from
/usr/local/lib/libFOX-1.0.so.0
#31 0x407831ad in FXApp::runOneEvent () from /usr/local/lib/libFOX-1.0.so.0
#32 0x40782eb3 in FXApp::run () from /usr/local/lib/libFOX-1.0.so.0
#33 0x403dc682 in _wrap_FXApp_run (argc=0, argv=0x0, self=1086941032)
    at core_wrap.cpp:2027
#34 0x08059c29 in call_cfunc (
    func=0x403dc610 <_wrap_FXApp_run(int, unsigned long *, unsigned long)>,
    recv=1086941032, len=-1, argc=0, argv=0x0) at eval.c:4279
#35 0x0805a142 in rb_call0 (klass=1075556540, recv=1086941032, id=5713,
argc=0, argv=0x0,
    body=0x401babf8, nosuper=1) at eval.c:4416
#36 0x0805a945 in rb_call (klass=1075556540, recv=1086941032, mid=5713,
argc=0, argv=0x0,
    scope=0) at eval.c:4640
#37 0x08055a2c in rb_eval (self=1075670240, n=0x401c9a40) at eval.c:2572
#38 0x0805241c in ruby_run () at eval.c:1230
#39 0x08050bbe in main (argc=2, argv=0xbffff65c, envp=0xbffff668) at
main.c:50
#40 0x400960de in __libc_start_main () from /lib/libc.so.6

i really love what i saw about fxruby so far, please help me on this!

emmanuel

Re: [Fxruby-users] FXTreeLists....

[Hugh S. S. E. E. <hg...@dm...>]

On Tue, 8 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > Looking at the examples for FXTreeLists, there are some things that
> > stand out.
> >
> > Firstly, an item in an FXTreeList is not an FXTreeList, but an
> > FXTreeItem. This seems contrary to customary computer science
>
> It is important not to confuse the FXTreeList widget with a "tree"
> abstract data type.
>
> Every widget in FOX is some kind of window, and FXTreeList must thus be
> a window as well. But it wouldn't make sense for the FXTreeList widget
> to have other widgets (windows) as its children, and that's why the

Well, most of the other widgets have widgets as children, I suppose
it is a design decision.

> FXTreeItem class exists. FXTreeItem is a kind of data object (i.e. it is
> *not* a widget) that the FXTreeList manipulates, and FXTreeItem objects
> have most of the "structural" properties that I think you'd expect to
> see in a tree data type.

except for adding descendants, etc, which actually belong to the
Treelist itself.
>
> > Secondly, FXTreeLists allow [...] "user data" with the object.  This
> > data can be any Ruby object, can it?
>
> Yes, right. This makes it more convenient to attach some
> application-specific data to a tree item, in situations when subclassing
> FXTreeItem would be overkill.

Thanks. I think I can make some more progress now.
>
> > I can use the FXTreeList to structure auxilliary data if I wish,
> > without having to have two data structures to keep in synch.  Is
> > that correct?

> Yes, that's also true.
>

> > Thirdly, once I start manipulating the data held in each
> > FXTreeItem, if I wish to expand items below it for example,
> > [...]how is this sort of thing normally handled?

> I think most people just hang on to a reference to the tree list

OK, it seemed a bit messy that way, but...

> [...] For that matter, I don't suppose
> there's a problem with sticking a reference to the tree list in
> that bundle of user data that you attach to the tree items.

...that seems a good place to hide this sort of bird's nest wiring :-)
>
>
        Thank you,
        Hugh

Re: [Fxruby-users] FXTreeLists....

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

Hugh Sasse Staff Elec Eng wrote:

> Looking at the examples for FXTreeLists, there are some things that
> stand out.
> 
> Firstly, an item in an FXTreeList is not an FXTreeList, but an
> FXTreeItem. This seems contrary to customary computer science
> practice where trees and operations on them are defined recursively.
> I suspect that knowing why they are designed differently will help
> me understand them better, so if this design has positive benefits
> I'd be interested in hearing about them.

It is important not to confuse the FXTreeList widget with a "tree" 
abstract data type.

Every widget in FOX is some kind of window, and FXTreeList must thus be 
a window as well. But it wouldn't make sense for the FXTreeList widget 
to have other widgets (windows) as its children, and that's why the 
FXTreeItem class exists. FXTreeItem is a kind of data object (i.e. it is 
*not* a widget) that the FXTreeList manipulates, and FXTreeItem objects 
have most of the "structural" properties that I think you'd expect to 
see in a tree data type.

> Secondly, FXTreeLists allow you to add an item below another item,
> and supply "data", defined as "user data" with the object.  This
> data can be any Ruby object, can it?

Yes, right. This makes it more convenient to attach some 
application-specific data to a tree item, in situations when subclassing 
FXTreeItem would be overkill.

> The examples of use with
> FXTreeList seem to use a pre-constructed data structure in parallel
> with the FXTreeList, but this would seem to suggest I can use the
> FXTreeList to structure auxilliary data if I wish, without having to
> have two data structures to keep in synch.  Is that correct?

Yes, that's also true.

> Thirdly, once I start manipulating the data held in each FXTreeItem,
> if I wish to expand items below it for example, FXTreeItem doesn't
> seem to have a reference to its tree, only its immediate parent, but
> modifications to the tree structure don't take place at that level.
> how is this sort of thing normally handled?

I think most people just hang on to a reference to the tree list 
somewhere else in the application (e.g. as member data in the main 
window class, or whatever). For that matter, I don't suppose there's a 
problem with sticking a reference to the tree list in that bundle of 
user data that you attach to the tree items.

[Fxruby-users] FXTreeLists....

[Hugh S. S. E. E. <hg...@dm...>]

Looking at the examples for FXTreeLists, there are some things that
stand out.

Firstly, an item in an FXTreeList is not an FXTreeList, but an
FXTreeItem. This seems contrary to customary computer science
practice where trees and operations on them are defined recursively.
I suspect that knowing why they are designed differently will help
me understand them better, so if this design has positive benefits
I'd be interested in hearing about them.

Secondly, FXTreeLists allow you to add an item below another item,
and supply "data", defined as "user data" with the object.  This
data can be any Ruby object, can it?   The examples of use with
FXTreeList seem to use a pre-constructed data structure in parallal
with the FXTreeList, but this would seem to suggest I can use the
FXTreeList to structure auxilliary data if I wish, without having to
have two data structures to keep in synch.  Is that correct?

Thirdly, once I start manipulating the data held in each FXTreeItem,
if I wish to expand items below it for example, FXTreeItem doesn't
seem to have a reference to its tree, only its immediate parent, but
modifications to the tree structure don't take place at that level.
how is this sort of thing normally handled?

        Thank you,
        Hugh

[Fxruby-users] Re: API documentation (was: Dialogues, and create)

[Hugh S. S. E. E. <hg...@dm...>]

On Thu, 3 Jul 2003, Lyle Johnson wrote:

> > -- I was feeling frustrated earlier trying to find out where show()
> > came from, because it is used by FXDialogueBox, but comes from
> > FXTopWindow, but FXTopWindow.methods doesn't reveal it, only
> > FXTopWindow.instance_methods does.
>
> Right, but this is just a Ruby thing. Object#methods returns a list of

Yes, and may be wider, for OO languages in general.

> but of course this isn't very useful. What you *really* want to know is,
> if you have my hands on an FXTopWindow object (an instance of class

or a descendent of it,
> "FXTopWindow"), what methods can you call on that? So then your choices are:
>
>      aTopWindow = FXTopWindow.new(...)
>      aTopWindow.methods
>
> or the more convenient:
>
>      FXTopWindow.instance_methods

Yes, did both of those.
>
> Sure. Good automated documentation tools like RDoc are great to have,
> but they can't write the meat of the text for you. As you say, they
> cannot divine the semantics of a particular method given its name, or
> its argument list; some human being has to fill in those blanks ;)

I wonder if that can be facilitated in some way?  Objects are
supposed to be re-useable, but without docs they won't be.  Maybe
common usage "patterns" might be helpful.

For example, with a teaspoon you can stir tea with it, or eat with
it, and you want to wash it afterwards.  This doesn't mean you can't
use it as a tyre lever when mending a puncture on a bicycle, but at
least the common things inherited from spoon and cutlery are to hand
in the docs.

I'd hope that the tool could search the usual inheritance paths to
find thes methods and link to them, which would save on duplication,
and cope with some ancestor overriding its parent's methods later.

This would be too naive in the case of singletons, but is it worth
consideration, in the general case?  It would not be perfert, but
would it be enough of an improvement to try?

        Hugh

[Fxruby-users] Re: API documentation (was: Dialogues, and create)

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

Hugh Sasse Staff Elec Eng wrote:

>> > Ah, just "clicked" about getApp(), avoids repeoting a ref to the
>> > application object.  getApp doesn't seem to appear in the methods
>> > pane of http://www.fxruby.org/doc/api/
>>
>> It *is* listed as a "readable" attribute of FXId:
> 
> Oh! it's one of those! :-)
> 
>> value. But that's a separate discussion, whether we should be listing
>> both the "getter" and "setter" methods as well as the "attr_reader" and
>> "attr_writer" methods in the API docs ;)
> 
> yes, this may really fall into the "who is RDoc's audience?" area:
> -- I was feeling frustrated earlier trying to find out where show()
> came from, because it is used by FXDialogueBox, but comes from
> FXTopWindow, but FXTopWindow.methods doesn't reveal it, only
> FXTopWindow.instance_methods does.

Right, but this is just a Ruby thing. Object#methods returns a list of 
methods available for the object. Since FXTopWindow is itself an object 
(it is an instance of class "Class"), you can call methods on it to get 
a list of its methods:

     FXTopWindow.methods

but of course this isn't very useful. What you *really* want to know is, 
if you have my hands on an FXTopWindow object (an instance of class 
"FXTopWindow"), what methods can you call on that? So then your choices are:

     aTopWindow = FXTopWindow.new(...)
     aTopWindow.methods

or the more convenient:

     FXTopWindow.instance_methods

> I'm beginning to think that there maybe needs to be another template
 > for RDoc for behaviour discovery. This leads into the dark and
 > twisty passages about respond_to?() being insufficient to specify
 > type because it doesn't cover semantics. So I can't think about adding
 > this to RDoc myself when it is probably not the solution.

Sure. Good automated documentation tools like RDoc are great to have, 
but they can't write the meat of the text for you. As you say, they 
cannot divine the semantics of a particular method given its name, or 
its argument list; some human being has to fill in those blanks ;)

Re: [Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

On Thu, 3 Jul 2003, Lyle Johnson wrote:

> Yes, the GUIs are quite efficient (IMO). One of the pathological cases
> that we had for awhile here at work was an application that built up its
> GUI dynamically (based on the contents of a configuration file) and for
> some cases was constructing thousands and thousands of widgets. Despite
> that unusually large size, it was still pretty responsive and so forth.

Thank you, that is reassuring.
>
> Widgets are very quick to construct and destroy, and don't seem to use
> that much memory. In C++-based FOX applications it's standard practice
> to just construct dialog boxes (e.g. file dialogs) as temporary objects,

That seems reasonable, and better than what I was considering:
constructing them all at the start, doing the one create() call, and
hiding most of them.

> on the stack. We never used to do that in older Motif applications
> because it was so slow. As you noted, times (and memory constraints)
> have changed a lot since the 80's ;)

Yes :-)  I still admire what people did with 32K though!
>
>
        Thank you,
        Hugh

Re: [Fxruby-users] Dialogues, and create.

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

Hugh Sasse Staff Elec Eng wrote:

> So these GUIs are pretty efficient then.  So do people tend to just
> use show and hide then, and just let normal garbage collection take
> its course?  Maybe the effort isn't worth it now, and I should
> forget habits about tight memory budgets picked up in the 1980's!

Yes, the GUIs are quite efficient (IMO). One of the pathological cases 
that we had for awhile here at work was an application that built up its 
GUI dynamically (based on the contents of a configuration file) and for 
some cases was constructing thousands and thousands of widgets. Despite 
that unusually large size, it was still pretty responsive and so forth.

Widgets are very quick to construct and destroy, and don't seem to use 
that much memory. In C++-based FOX applications it's standard practice 
to just construct dialog boxes (e.g. file dialogs) as temporary objects, 
on the stack. We never used to do that in older Motif applications 
because it was so slow. As you noted, times (and memory constraints) 
have changed a lot since the 80's ;)

Re: [Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

On Thu, 3 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > When would you want to do [detach], then?
>
> Please see the FAQ "What's the difference between detach and delete?":
>
> 	http://www.fox-toolkit.org/faq.html#DETACH

Thanks, I'll do that.
>
> > So you can call create on the FXObject to get it back again if you
> > wish?  Is this common practice to reduce memory usage whilst keeping
> > performance high, or something? I'm thinking in my current
        [...]
> Yes, you can call create on the object to get it back again, but no, it
> isn't common practice to create and tear down windows to reduce memory
> use. I cannot think of a single time when I have called destroy()
        [...]
So these GUIs are pretty efficient then.  So do people tend to just
use show and hide then, and just let normal garbage collection take
its course?  Maybe the effort isn't worth it now, and I should
forget habits about tight memory budgets picked up in the 1980's!

        [...]
> need to display a GUI. For example, maybe at first it does display a GUI
> and allow the user to interact, set some parameters. At some point, the
> user clicks the "Go" button and we call FXApp#destroy to tear down all
> of the GUI parts, so that the program can continue to run in the
> background even if the X server is killed or something like that. Again,
> I've never needed to do this, so I'm just going from memory here.

Thanks, that is an interesting idea.
>
        [...]
> >>      anIcon = FXPNGIcon.new(getApp(), ...)
> >
> > Ah, just "clicked" about getApp(), avoids repeoting a ref to the
> > application object.  getApp doesn't seem to appear in the methods
> > pane of http://www.fxruby.org/doc/api/
>
> It *is* listed as a "readable" attribute of FXId:

Oh! it's one of those! :-)

> value. But that's a separate discussion, whether we should be listing
> both the "getter" and "setter" methods as well as the "attr_reader" and
> "attr_writer" methods in the API docs ;)

yes, this may really fall into the "who is RDoc's audience?" area:
-- I was feeling frustrated earlier trying to find out where show()
came from, because it is used by FXDialogueBox, but comes from
FXTopWindow, but FXTopWindow.methods doesn't reveal it, only
FXTopWindow.instance_methods does.  I'm beginning to think that
there maybe needs to ba another template for RDoc for behaviour
discovery.  This leads into the dark and twisty passages about
respond_to?() being insufficient to specify type because it doesn't
cover semantics.  So I can't think about adding this to Rdoc myeslf
when it is probably not the solution.

>
> -- Lyle
>
>
        Hugh

Re: [Fxruby-users] Dialogues, and create.

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

Hugh Sasse Staff Elec Eng wrote:

>> Calling detach() on a FOX object reverses part of the effect of
>> create(); it breaks this binding between the FOX object and its
>> window-system entity, but it doesn't actually destroy either of them.
> 
> When would you want to do that, then?

Please see the FAQ "What's the difference between detach and delete?":

	http://www.fox-toolkit.org/faq.html#DETACH

>> Calling destroy() goes one step further (if you want to think of it that
>> way) and actually destroys the window-system entity. Note that it
>> doesn't destroy (garbage-collect) the FOX object, just the X window or
> 
> So you can call create on the FXObject to get it back again if you
> wish?  Is this common practice to reduce memory usage whilst keeping
> performance high, or something? I'm thinking in my current
> application I will have many possible dialogues, and am wondering
> about when to new()...GC or create()...destroy() or show()...hide()
> them, and what [de]merits there are of each strategy.  I think I've
> just listed them in increasing order of memory usage.  I'm not sure
> if I should worry about that at all, I expect the windowing systems
> are pretty efficient in terms of memory nowadays[?].

Yes, you can call create on the object to get it back again, but no, it 
isn't common practice to create and tear down windows to reduce memory 
use. I cannot think of a single time when I have called destroy() 
explicitly in one of my FOX applications. [As the previously referenced 
FAQ notes, destroy() gets called as a side effect when the FOX object is 
garbage-collected, but I'm excluding those cases.]

I would not worry about using this as a memory management technique. One 
way it might be useful (and I think some people have used it for this) 
is to build an application that runs continuously but doesn't always 
need to display a GUI. For example, maybe at first it does display a GUI 
and allow the user to interact, set some parameters. At some point, the 
user clicks the "Go" button and we call FXApp#destroy to tear down all 
of the GUI parts, so that the program can continue to run in the 
background even if the X server is killed or something like that. Again, 
I've never needed to do this, so I'm just going from memory here.

>> its recursive behavior. Specifically, calling destroy() on a widget will
>> not destroy any of its shared resources, like fonts or icons. Suppose
>> you create an icon:
>>
>>      anIcon = FXPNGIcon.new(getApp(), ...)
> 
> Ah, just "clicked" about getApp(), avoids repeoting a ref to the
> application object.  getApp doesn't seem to appear in the methods
> pane of http://www.fxruby.org/doc/api/

It *is* listed as a "readable" attribute of FXId:

	http://www.fxruby.org/doc/api/classes/Fox/FXId.html

which means that there's also a getApp() method that returns the same 
value. But that's a separate discussion, whether we should be listing 
both the "getter" and "setter" methods as well as the "attr_reader" and 
"attr_writer" methods in the API docs ;)

-- Lyle

Re: [Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

On Thu, 3 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > The next thing I'll need to know is: Where can I generalize this
> > behaviour: are there other calls that propagate like this?
>
> The other two that immediately come to mind are the detach() and
> destroy() methods.
>
> You may already understand that the purpose of calling create() is to
> create and then bind a native windowing-system entity (e.g. a X window,
> or a Win32 GDI font) to an already-existing FOX object (like an FXWindow
> or FXFont instance).

Yes, I have an idea about that, but am not au fait with the details.
I don't think I need to be yet!
>
> Calling detach() on a FOX object reverses part of the effect of
> create(); it breaks this binding between the FOX object and its
> window-system entity, but it doesn't actually destroy either of them.

When would you want to do that, then?

> And like create(), detach() does its thing recursively, from parent to
> child windows.
>
> Calling destroy() goes one step further (if you want to think of it that
> way) and actually destroys the window-system entity. Note that it
> doesn't destroy (garbage-collect) the FOX object, just the X window or

So you can call create on the FXObject to get it back again if you
wish?  Is this common practice to reduce memory usage whilst keeping
performance high, or something? I'm thinking in my current
application I will have many possible dialogues, and am wondering
about when to new()...GC or create()...destroy() or show()...hide()
them, and what [de]merits there are of each strategy.  I think I've
just listed them in increasing order of memory usage.  I'm not sure
if I should worry about that at all, I expect the windowing systems
are pretty efficient in terms of memory nowadays[?].

> whatever that was backing it up. An important distinction, though, is
> that destroy() is not as aggressive as create() and detach() in terms of
> its recursive behavior. Specifically, calling destroy() on a widget will
> not destroy any of its shared resources, like fonts or icons. Suppose
> you create an icon:
>
>      anIcon = FXPNGIcon.new(getApp(), ...)

Ah, just "clicked" about getApp(), avoids repeoting a ref to the
application object.  getApp doesn't seem to appear in the methods
pane of http://www.fxruby.org/doc/api/
>
> and then associate it with two different widgets (a label and a button):
 [...]
> Now suppose that at some point later you call destroy() on the button:
 [...]
> It is clear that you want to blow away the X window (or Win32 window)
> underlying that FXButton instance, but you don't want to destroy the
> icon too since someone else may still be using that resource. And in

that flexibility is useful.
>
> There are other behaviors in FOX that are recursive, e.g. the manner in
> which the layout algorithm works, but right offhand I can't think of any
> other APIs that you'd deal with directly that have a recursive nature. I

OK, thanks, this is probably enough for now. :-)

> am sure that as soon as I send this post, someone will point out some
> cases I forgot about, though ;)
>
> Hope this helps,

Yes, thank you again.
>
> Lyle
>
        Hugh

Re: [Fxruby-users] Dialogues, and create.

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

Hugh Sasse Staff Elec Eng wrote:

> The next thing I'll need to know is: Where can I generalize this
> behaviour: are there other calls that propagate like this?

The other two that immediately come to mind are the detach() and 
destroy() methods.

You may already understand that the purpose of calling create() is to 
create and then bind a native windowing-system entity (e.g. a X window, 
or a Win32 GDI font) to an already-existing FOX object (like an FXWindow 
or FXFont instance).

Calling detach() on a FOX object reverses part of the effect of 
create(); it breaks this binding between the FOX object and its 
window-system entity, but it doesn't actually destroy either of them. 
And like create(), detach() does its thing recursively, from parent to 
child windows.

Calling destroy() goes one step further (if you want to think of it that 
way) and actually destroys the window-system entity. Note that it 
doesn't destroy (garbage-collect) the FOX object, just the X window or 
whatever that was backing it up. An important distinction, though, is 
that destroy() is not as aggressive as create() and detach() in terms of 
its recursive behavior. Specifically, calling destroy() on a widget will 
not destroy any of its shared resources, like fonts or icons. Suppose 
you create an icon:

     anIcon = FXPNGIcon.new(getApp(), ...)

and then associate it with two different widgets (a label and a button):

     aLabel.icon = anIcon
     aButton.icon = anIcon

Now suppose that at some point later you call destroy() on the button:

     aButton.destroy

It is clear that you want to blow away the X window (or Win32 window) 
underlying that FXButton instance, but you don't want to destroy the 
icon too since someone else may still be using that resource. And in 
this case, of course, that "someone else" is the label.

There are other behaviors in FOX that are recursive, e.g. the manner in 
which the layout algorithm works, but right offhand I can't think of any 
other APIs that you'd deal with directly that have a recursive nature. I 
am sure that as soon as I send this post, someone will point out some 
cases I forgot about, though ;)

Hope this helps,

Lyle

Re: [Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

On Wed, 2 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> >> Isn't the create() call propagated from parent to child?
> >
> > Then why isn't it always?  I have found that I have to call create on
> > the children before the parent, in the few cases I have done this so
> > far.
>
> Hugh,
>
> Sorry for the delayed response. Joel was correct in his response that
> when you call create() on a parent window, it recursively calls create()
> on all of its child windows that exist at that time. Also, even though
> FXApp is not itself a "window", calling FXApp#create will call create()
> on all of the top-level windows (e.g. main windows and dialog boxes)
> that exist at the time create() is called.

OK, that is clear now....
>
        [...]
> I'm trying to think of any exceptions to the rule and I don't know that
> there are any. What may be tripping you up, and what frequently throws
> people, is that create() only realizes widgets that exist at the time
> that create() is called. In other words, say you construct a dialog box:

This could be what happened to me. I will have another look at my
code to see if that is true.  Thank you.

The next thing I'll need to know is: Where can I generalize this
behaviour: are there other calls that propagate like this?
>
> or, since calls to create() are recursive, you could call create() on
> the dialog again:
>
>      dialog.create

Could I call it on FXApp again?   Hmm, what about

class Class
  alias_method :old_new,  :new
  def new(*args)
     result = old_new(*args)
     $fxapp.create if self.ancestors.include?(FXObjectt)
     return result
   end
end

or something?

>
> Calling create() repeatedly on the same object is safe, at least for the
> built-in FOX classes. They will still recurse through the list of child
> windows, but only actually create the windows that haven't been realized
> yet.
>
> Hope this helps,

Yes, this is clear now. thnak you.
>
> Lyle
>

Re: [Fxruby-users] Dialogues, and create.

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

Hugh Sasse Staff Elec Eng wrote:

>> Isn't the create() call propagated from parent to child?
> 
> Then why isn't it always?  I have found that I have to call create on
> the children before the parent, in the few cases I have done this so
> far.

Hugh,

Sorry for the delayed response. Joel was correct in his response that 
when you call create() on a parent window, it recursively calls create() 
on all of its child windows that exist at that time. Also, even though 
FXApp is not itself a "window", calling FXApp#create will call create() 
on all of the top-level windows (e.g. main windows and dialog boxes) 
that exist at the time create() is called.

So for the dialog.rb example program, the call to FXApp#create triggers 
calls to both DialogTester#create and FXTestDialog#create, since they 
are top-level windows and they have been instantiated before the call to 
FXApp#create. In turn those calls to DialogTester#create and 
FXTestDialog#create trigger recursive calls to create() for all of those 
windows' child windows.

> OK, but how do I use this?  I mean, I realise my heuristic was
> wrong, because the code works, but how do I revise it to fit with
> reality? :-)  Are there whole families of widgets and windows for
> which I can forget about the create() calls?  How do I look this
> information up?

I'm trying to think of any exceptions to the rule and I don't know that 
there are any. What may be tripping you up, and what frequently throws 
people, is that create() only realizes widgets that exist at the time 
that create() is called. In other words, say you construct a dialog box:

     dialog = FXTestDialog.new(...)

and then create it:

     dialog.create

Now if you were to add a new button to the dialog box immediately after 
you called FXDialogBox#create:

     button = FXButton.new(dialog, ...)

That button doesn't automatically get "created", because it didn't exist 
when you previously called create. You must go back and either call 
create() on the button itself:

     button.create

or, since calls to create() are recursive, you could call create() on 
the dialog again:

     dialog.create

Calling create() repeatedly on the same object is safe, at least for the 
built-in FOX classes. They will still recurse through the list of child 
windows, but only actually create the windows that haven't been realized 
yet.

Hope this helps,

Lyle

Re: [Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

On Tue, 1 Jul 2003, Joel VanderWerf wrote:

> Hugh Sasse Staff Elec Eng wrote:
> > I have learned the heuristic that for a widget hierarchy to be
> > operative it must be constructed and created, and the create() calls
> > must be done on the child widgets before the parent widget.
> >
> > So now I have been looking at dialog.rb from the examples.
> > application is an FXApp, and application.create is called, but
> > FXTestDialog's create method never seems to be called, nor does
> > DialogTester's.  The child widgets (buttons, menus) don't seem to be
> > create()d either.
>
> Isn't the create() call propagated from parent to child?

Then why isn't it always?  I have found that I have to call create on
the children before the parent, in the few cases I have done this so
far.
>
> In fact, if I add some debugging code to DialogTester#create:
>
        [...]
>      puts "FOO"
        [...]
>
> then I see FOO on stdout when the main window appears.
>
> I'll bet you could verify that FXTestDialog#create is being called, too.
>

OK, but how do I use this?  I mean, I realise my heuristic was
wrong, because the code works, but how do I revise it to fit with
reality? :-)  Are there whole families of widgets and windows for
which I can forget about the create() calls?  How do I look this
information up?

        Hugh

Re: [Fxruby-users] Dialogues, and create.

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

Hugh Sasse Staff Elec Eng wrote:
> I have learned the heuristic that for a widget hierarchy to be
> operative it must be constructed and created, and the create() calls
> must be done on the child widgets before the parent widget.
> 
> So now I have been looking at dialog.rb from the examples.
> application is an FXApp, and application.create is called, but
> FXTestDialog's create method never seems to be called, nor does
> DialogTester's.  The child widgets (buttons, menus) don't seem to be
> create()d either.

Isn't the create() call propagated from parent to child?

In fact, if I add some debugging code to DialogTester#create:

def create
     super
     puts "FOO"
     show(PLACEMENT_SCREEN)
   end
end

then I see FOO on stdout when the main window appears.

I'll bet you could verify that FXTestDialog#create is being called, too.

[Fxruby-users] Dialogues, and create.

[Hugh S. S. E. E. <hg...@dm...>]

I have learned the heuristic that for a widget hierarchy to be
operative it must be constructed and created, and the create() calls
must be done on the child widgets before the parent widget.

So now I have been looking at dialog.rb from the examples.
application is an FXApp, and application.create is called, but
FXTestDialog's create method never seems to be called, nor does
DialogTester's.  The child widgets (buttons, menus) don't seem to be
create()d either.

What have I missed?

        Thank you
        Hugh