fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] PragProg Ruby package 1.8.0 and printing

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

On 18 Nov 2003 20:40:00 -0000, "Tom Kunz"
<tku...@so...> wrote :

> When I attempt to print from Win2k, I bring up the printer dialog and
> click the "Print" button, and it immediately gives me "Unable to
> print".  If I try the same thing again and select a printer and click
> "Properties", it does nothing.
> 
> Any ideas?  Is this a problem just with the Pragmatic Programmers kit
> or something else?

As far as I know, FOX does not provide any support for connecting to a
Windows printer and printing directly from an application. So, best case,
you might be able to use the printer dialog to configure a print job but
you'd have to do the actual printing yourself.

[Fxruby-users] PragProg Ruby package 1.8.0 and printing

[Tom K. <tku...@so...>]

Hi,

I'm new to FXRuby, and I'm wondering about printing from Windows 2k.
I installed the Ruby 1.8.0 package from the Pragmatic Programmers for
Windows, which included FOX, and their sample program "dctest.rb" does
not work.

When I run dctest.rb from Linux, it prints except that the output
looks to be about 2x the size it should, and shift half a page up.
All I get is the bottom half of the screen.  The calls to lpr work
fine, just maybe something is wrong with the PS it generates.  I can
probably find a relatively easy way to fix this, so I'm not overly
concerned about it.

When I attempt to print from Win2k, I bring up the printer dialog and
click the "Print" button, and it immediately gives me "Unable to
print".  If I try the same thing again and select a printer and click
"Properties", it does nothing.

Any ideas?  Is this a problem just with the Pragmatic Programmers kit
or something else?

Thanks,
Tom

Re: [Fxruby-users] Edit FXTableItem?

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

Hans Fugal wrote:
> * oleg dashevskii [Tue, 11 Nov 2003 at 19:51 +0600]
> 
>>This question has already been asked 100 times, but there's still no
>>solution other than subclass FXItem (and FXTable itself, since it
>>contains a FXItem factory method). Pity enough. Many people have
>>attempted to go the subclassing way (as seen from FOX maillist
>>archives), but noone seems to have come up with a final solution -
>>neither in C++, nor in Ruby.
> 
> That's what I was afraid of. (part of me was just hoping my google
> skillz were on vacation)
>  
> 
>>I personally would be very happy to have an editing possibility. I even
>>made my own hak, but it's ugly. ;-( I look forward to replacing it with
>>something better. :-)
> 
> Has anyone settled for a second-best alternative they'd like to share?
> Basically I'm trying to edit a list of items, where each item is a row
> in the table (has several attributes). Something like
> http://falcon.fugal.net/fugalh/tmp/mc_recipe.jpg
> 
> Gosh, this feels like web programming all over again. :/
> 

hi,
maybe it would be best to forget completely about fxtable and implement 
a table that consists of two headers controling multiple rows of 
fxpackers inside of multiple columns of fxhorizontal frames or fxpackers 
in an fxmatrix.

then you would have an fxcomposite-derivative instead of an fxtableitem 
and you could add to it whatever you like.

-- henon

Re: [Fxruby-users] Edit FXTableItem?

[Hans F. <ha...@fu...>]

* oleg dashevskii [Tue, 11 Nov 2003 at 19:51 +0600]
> This question has already been asked 100 times, but there's still no
> solution other than subclass FXItem (and FXTable itself, since it
> contains a FXItem factory method). Pity enough. Many people have
> attempted to go the subclassing way (as seen from FOX maillist
> archives), but noone seems to have come up with a final solution -
> neither in C++, nor in Ruby.
That's what I was afraid of. (part of me was just hoping my google
skillz were on vacation)
=20
> I personally would be very happy to have an editing possibility. I even
> made my own hak, but it's ugly. ;-( I look forward to replacing it with
> something better. :-)
Has anyone settled for a second-best alternative they'd like to share?
Basically I'm trying to edit a list of items, where each item is a row
in the table (has several attributes). Something like
http://falcon.fugal.net/fugalh/tmp/mc_recipe.jpg

Gosh, this feels like web programming all over again. :/

--=20
 Hans Fugal                 | De gustibus non disputandum est.
 http://hans.fugal.net/     | Debian, vim, mutt, ruby, text, gpg
 http://gdmxml.fugal.net/   | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460

Re: [Fxruby-users] Edit FXTableItem?

[oleg d. <be...@be...>]

On Wed, Nov 05, 2003 at 08:29:04AM -0700, Hans Fugal wrote:
> I'd like to use an FXTable as a data entry method. That is, I'd like to
> type text into the cells. I can't figure out how to do this - in all the
> examples I've seen and from the API I don't see anything that would make
> this possible (short of subclassing FXTableItem to duplicate the
> functionality of an FXText).
> 
> Any ideas?

This question has already been asked 100 times, but there's still no
solution other than subclass FXItem (and FXTable itself, since it
contains a FXItem factory method). Pity enough. Many people have
attempted to go the subclassing way (as seen from FOX maillist
archives), but noone seems to have come up with a final solution -
neither in C++, nor in Ruby.

I personally would be very happy to have an editing possibility. I even
made my own hak, but it's ugly. ;-( I look forward to replacing it with
something better. :-)

--
be9

RE: [Fxruby-users] FXScrollArea Weirdness

[Douglas H. <mi...@jr...>]

Oh my, I feel like a retard, ignore that last question. The scrollbar
receives the message, not FXImageView/ScrollArea and it's set at the
application level. 

[Fxruby-users] FXScrollArea Weirdness

[Douglas H. <mi...@jr...>]

Ok, I was writing a simple little app for viewing some specific images and
realized that scrolling an FXImageView object using the mouse wheel is
extraordinarily slow, so I wanted to override the SEL_MOUSEWHEEL handler
that FXScrollArea has built in. Only, when I define a handler for it, it
never gets executed and the built in handler continues to be called. Some
test code that illustrates this is:
 
@imageview = FXImageView.new(imagebox, nil, nil, 0,
LAYOUT_FILL_X|LAYOUT_FILL_Y|HSCROLLER_NEVER)
@imageview.connect(SEL_MOUSEWHEEL) { print "HAHAHAHAHHAHAHAHA!\n" }
 
Obviously not the most advanced code ever, but this is what I reverted to,
to test it after inheriting from FXImageView and trying to change the
handler within my new class.
 
I'm wondering if this is a bug or intentional? Or if maybe there's another
way to increase the speed at which using the mouse wheel scrolls the image.
 
--
Douglas Huff
aka mith
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (MingW32) - WinPT 0.5.13
Comment: For info see http://www.gnupg.org
 
mQGiBD4wUHARBACVd7+P2r9dSlhmp4tdYUr4acs/wPM3pGFeYgC8PeiDI4Rg/EiH
Ke6bDvglr3UjaxvYkx9D7BRBC8pSeuMVrzKWaiNYUEU4AWJsx/n4/+q3hkQrvYwv
q+RWFOkCZUHwYsKQ1MHgvn8LfBQqwYpug13QWu34DRvughsCCeIBNo5f5wCgw8Ul
T1+onIgMSMD1feKCOm/U8TkEAIb+aPzDDE+wPaWlK1Pmu/9heQ8HDbEQLG9UNVOy
P5vCC2s3LAadF1U4hmYgwsaRv57q1tJOpwgBt0/PW18mgEAkHRzOBx9fnpBP8mxj
XXlnhGRo40b5hxh9o9kZaeLGneDeBfSPQoJgPa70bAIN1kq6dsQn+pxpdB11tINT
PNxTA/9pC2e18ObJdx3VNF0y00pLmvyqnlhqdD/S09X7d1q6/ukcyO9Rch62HJHu
zqJjRsoPq5rZk0O29JsMj2pbaIs4jgkt0bo4WVKQd7xEophcfK8XlrbZYEM3mt3l
2vOCuX8LhOi3Wp85Oq+OS6nmtjx+0kdKzRuLgpGKb0G6QD9co7QpRG91Z2xhcyBI
dWZmIChtaXRoKSA8bWl0aEBqcmJvYmRvYmJzLm9yZz6IVwQTEQIAFwUCPjBQcAUL
BwoDBAMVAwIDFgIBAheAAAoJEIrTojpfftR05FUAnjkIwnNEgSBgyWDNqfPAcCfv
Rp+TAKCUHU7obqxASbhnTzqhA7SsCZM1f7kCDQQ+MFB8EAgA69SKT7WPSbm5a3Zw
3Ck9MIM4df77/LX4T5m1uxAh+FdJms40L3XhIYfCt/qsgPMDWIjHbPZVHcW/yc9B
i55Qu/ChduyDLFcoMCtp0MyOWi9nilX+hBklfHY75Nai0B0b/ihnXKOB5LzxQweb
kWX43xkt+va6K2j5z+e+4RoRcPBl1qJ1WoEMgCU6ARfXZpwnjgGcnUZKanFn7qmD
8TkEoNzGTlKJoL/K0UpaZ8y6bqZgGUFYoZLbhF+op+PDFbtNKEaZ0fE8HU6dswnd
M5ANXap349/zBMtRZcTCnlLV+fH5T9GX4PtPzCqwk9fgE4BKyDiPBwySYg8N0DNt
nTm4XwADBQf/ZvQG5ZqLZjrQ0ZMek65uo5wUgvxdmVHZjrKye2pastwHNzue/f3j
4dNEYCEjl/rBNpqiQlK55cMYJdTR/RN8ltDJIkZRXFlUuNbozXTZi6t+zV6K6Oei
ir/yQQWMYJ4zFkvnzqAz5vsx1pP3WSvz6OtKffPSWAs6NrNNWeewiKUECrEKGV/G
IjxFmB7AYWD05h5cwpMP4B6WWUMyLqf2kXXheT6Rl58d89LkwPmTMNTroTgs/fy0
64QhlmGfnbr/aW+5haGPQ8rT1k/v3LtGGB6sbAxCaWLCEgUG0mrzaK69rHzHDTwA
s0CoYr7ufSf5LPJ5S73z7sPP+p8E/CBPgIhGBBgRAgAGBQI+MFB8AAoJEIrTojpf
ftR0KXcAoIgxRvMkfa7vMfR1WhSS5D5bDzm3AJ42AsBg5dvAUcttHk4UqxQunMh4
yA==
=RuXZ
-----END PGP PUBLIC KEY BLOCK-----
 

[Fxruby-users] FXScrollArea Weirdness

[Douglas H. <mi...@jr...>]

Ok, I was writing a simple little app for viewing some specific images and
realized that scrolling an FXImageView object using the mouse wheel is
extraordinarily slow, so I wanted to override the SEL_MOUSEWHEEL handler
that FXScrollArea has built in. Only, when I define a handler for it, it
never gets executed and the built in handler continues to be called. Some
test code that illustrates this is:
 
@imageview = FXImageView.new(imagebox, nil, nil, 0,
LAYOUT_FILL_X|LAYOUT_FILL_Y|HSCROLLER_NEVER)
@imageview.connect(SEL_MOUSEWHEEL) { print "HAHAHAHAHHAHAHAHA!\n" }
 
Obviously not the most advanced code ever, but this is what I reverted to,
to test it after inheriting from FXImageView and trying to change the
handler within my new class.
 
I'm wondering if this is a bug or intentional? Or if maybe there's another
way to increase the speed at which using the mouse wheel scrolls the image.
 
--
Douglas Huff
aka mith
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (MingW32) - WinPT 0.5.13
Comment: For info see http://www.gnupg.org
 
mQGiBD4wUHARBACVd7+P2r9dSlhmp4tdYUr4acs/wPM3pGFeYgC8PeiDI4Rg/EiH
Ke6bDvglr3UjaxvYkx9D7BRBC8pSeuMVrzKWaiNYUEU4AWJsx/n4/+q3hkQrvYwv
q+RWFOkCZUHwYsKQ1MHgvn8LfBQqwYpug13QWu34DRvughsCCeIBNo5f5wCgw8Ul
T1+onIgMSMD1feKCOm/U8TkEAIb+aPzDDE+wPaWlK1Pmu/9heQ8HDbEQLG9UNVOy
P5vCC2s3LAadF1U4hmYgwsaRv57q1tJOpwgBt0/PW18mgEAkHRzOBx9fnpBP8mxj
XXlnhGRo40b5hxh9o9kZaeLGneDeBfSPQoJgPa70bAIN1kq6dsQn+pxpdB11tINT
PNxTA/9pC2e18ObJdx3VNF0y00pLmvyqnlhqdD/S09X7d1q6/ukcyO9Rch62HJHu
zqJjRsoPq5rZk0O29JsMj2pbaIs4jgkt0bo4WVKQd7xEophcfK8XlrbZYEM3mt3l
2vOCuX8LhOi3Wp85Oq+OS6nmtjx+0kdKzRuLgpGKb0G6QD9co7QpRG91Z2xhcyBI
dWZmIChtaXRoKSA8bWl0aEBqcmJvYmRvYmJzLm9yZz6IVwQTEQIAFwUCPjBQcAUL
BwoDBAMVAwIDFgIBAheAAAoJEIrTojpfftR05FUAnjkIwnNEgSBgyWDNqfPAcCfv
Rp+TAKCUHU7obqxASbhnTzqhA7SsCZM1f7kCDQQ+MFB8EAgA69SKT7WPSbm5a3Zw
3Ck9MIM4df77/LX4T5m1uxAh+FdJms40L3XhIYfCt/qsgPMDWIjHbPZVHcW/yc9B
i55Qu/ChduyDLFcoMCtp0MyOWi9nilX+hBklfHY75Nai0B0b/ihnXKOB5LzxQweb
kWX43xkt+va6K2j5z+e+4RoRcPBl1qJ1WoEMgCU6ARfXZpwnjgGcnUZKanFn7qmD
8TkEoNzGTlKJoL/K0UpaZ8y6bqZgGUFYoZLbhF+op+PDFbtNKEaZ0fE8HU6dswnd
M5ANXap349/zBMtRZcTCnlLV+fH5T9GX4PtPzCqwk9fgE4BKyDiPBwySYg8N0DNt
nTm4XwADBQf/ZvQG5ZqLZjrQ0ZMek65uo5wUgvxdmVHZjrKye2pastwHNzue/f3j
4dNEYCEjl/rBNpqiQlK55cMYJdTR/RN8ltDJIkZRXFlUuNbozXTZi6t+zV6K6Oei
ir/yQQWMYJ4zFkvnzqAz5vsx1pP3WSvz6OtKffPSWAs6NrNNWeewiKUECrEKGV/G
IjxFmB7AYWD05h5cwpMP4B6WWUMyLqf2kXXheT6Rl58d89LkwPmTMNTroTgs/fy0
64QhlmGfnbr/aW+5haGPQ8rT1k/v3LtGGB6sbAxCaWLCEgUG0mrzaK69rHzHDTwA
s0CoYr7ufSf5LPJ5S73z7sPP+p8E/CBPgIhGBBgRAgAGBQI+MFB8AAoJEIrTojpf
ftR0KXcAoIgxRvMkfa7vMfR1WhSS5D5bDzm3AJ42AsBg5dvAUcttHk4UqxQunMh4
yA==
=RuXZ
-----END PGP PUBLIC KEY BLOCK-----
 

Re: [Fxruby-users] FXRuby with FOX development ..

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

Riccardo Giannitrapani wrote:

> it seems to me that this question has been already formulated (and 
> replied) on this mailing list or on the web, but I've not managed to 
> find it, so please apologize me if I ask it again :) .. do you know if 
> it is possible to build FXRuby out of the box with the last Development 
> version of FOX (1.1.41)?

No, there will not be a version of FXRuby that is compatible with FOX 
1.1.x until the API for that branch is frozen (i.e. when it is released 
as FOX 1.2). It is just too much work to try to track all of the changes 
from release to release.

[Fxruby-users] FXRuby with FOX development ..

[Riccardo G. <ric...@fi...>]

Dear Lyle and all

it seems to me that this question has been already formulated (and 
replied) on this mailing list or on the web, but I've not managed to 
find it, so please apologize me if I ask it again :) .. do you know if 
it is possible to build FXRuby out of the box with the last Development 
version of FOX (1.1.41)?

Thanks in advance, Riccardo :)

-- 
+--------------------------------------------------------------+
| Riccardo Giannitrapani                                       |
|                                                              |
| Dipartimento di Fisica - Room L1-14-BE                       |
| Universita` di Udine - Via delle Scienze, 206  Udine (Italy) |
| Tel (Home): +39-0432-470011 -- (Office): +39-0432-558209     |
| Home Page: http://www.fisica.uniud.it/~riccardo              |
| ICQ# 86590904                                                |
+--------------------------------------------------------------+

[Fxruby-users] Edit FXTableItem?

[Hans F. <ha...@fu...>]

I'd like to use an FXTable as a data entry method. That is, I'd like to
type text into the cells. I can't figure out how to do this - in all the
examples I've seen and from the API I don't see anything that would make
this possible (short of subclassing FXTableItem to duplicate the
functionality of an FXText).

Any ideas?

--=20
 Hans Fugal                 | De gustibus non disputandum est.
 http://hans.fugal.net/     | Debian, vim, mutt, ruby, text, gpg
 http://gdmxml.fugal.net/   | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460

Re: [Fxruby-users] request: a smarter connect method

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

meinrad recheis wrote:

> i want to be able to add code to existing event handling code.
> for example i want to synchronously scroll some FXLists using one of the 
> list's own scrollbars (while hiding the other's). when i do this with 
> connect, the scrollbar forget's its original event handling code. that 
> is bad because then it doesn't scroll his list anymore and thus nothing 
> gets scrolled at all.
> 
> i don't know whether it is possible, but the solution to any problem of 
> this kind would be a connect method that adds event handling 
> functionality without overwriting the original.

I think I understand what you're asking (and I have a workaround in 
mind), but could you maybe post some sample code for me to take a look at?

[Fxruby-users] Re: Maximizing an MDI child window in a FXRuby application

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

Stephan Kämper wrote:

> I'm trying to figure out how to write a small application that's just 
> capable of displaying some text in child windows. (I reduced the 
> "mditest.rbw" script that comes with FXRuby to show the problem I have).
> 
> My problem is:
> If I run the script below and maximize the chlid window, there's no way 
> to resize it.
> The three widgets on the top right (child) window corner will dissaprear 
> (The "under score", "square" and "X" icons to minimize, close and 
> maximize the window).

Well, the short answer is, compare your reduced program to the original 
mditest.rbw example and figure out what you took out ;)

But here's a hint: look at the section of the original mditest.rb 
example program that begins with the comment "MDI buttons in menu..." 
and copy the code that creates any of the buttons that you're interested 
in. In your case, it sounds like you want to add an FXMDIDeleteButton, 
FXMDIRestoreButton and FXMDIMinimizeButton to the main menu bar.

[Fxruby-users] request: a smarter connect method

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

hi,

i want to be able to add code to existing event handling code.
for example i want to synchronously scroll some FXLists using one of the 
list's own scrollbars (while hiding the other's). when i do this with 
connect, the scrollbar forget's its original event handling code. that 
is bad because then it doesn't scroll his list anymore and thus nothing 
gets scrolled at all.

i don't know whether it is possible, but the solution to any problem of 
this kind would be a connect method that adds event handling 
functionality without overwriting the original.

now i gotta find a workaround for my problem ...

cheers,
-- meinrad

Re: [Fxruby-users] FXList: a very little bug

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

SIMOKAWA hajime wrote:

> I can't find 
> 
>   class FXList
>     def currentItem=(*args); setCurrentItem(*args); end
> 
> in aliases.rb

Yep, you're right. Thanks very much for reporting this omission; it has 
been fixed for the next release.

[Fxruby-users] FXList: a very little bug

[SIMOKAWA h. <h-s...@aa...>]

Hello all.

FXRuby 1.0.26

I can't find 

  class FXList
    def currentItem=(*args); setCurrentItem(*args); end

in aliases.rb

SIMOKAWA, hajime (male,japan)

Re: [Fxruby-users] Usage FXList : makeItemVisible

[SIMOKAWA h. <h-s...@aa...>]

Hello all, and thanks for all.

I understand and the 'makeItemVisible' is working very well.



Lyle Johnson <jl...@cf...> wrote:

> SIMOKAWA hajime wrote:
> 
> > Another Question:
> > The 'makeItemVisible' is not working just after 'clearItems'.
> > A 'create' is need before 'makeItemVisible'.
> 
> When you call clearItems() and, subsequently appendItem(), on the list, 
> the list's layout is marked as dirty but it is not immediately 
> reconciled. FOX uses a technique of delayed layout, which is described 
> on this page from the FOX documentation:
> 
> 	http://www.fox-toolkit.org/guiupdate.html
> 
> Under normal circumstances, the GUI layout will not actually be 
> reconciled until we return to the main FOX event loop, i.e. until we 
> exit the callback for @btnV9. The problem in your case is that 
> makeItemVisible() assumes that the list's layout has already been 
> reconciled, which it hasn't. So the solution is to do *something* to 
> force the layout to be reconciled immediately, before the call to 
> makeItemVisible(). Calling create() on the main window is one way to do 
> this, but the more proper way is to call the FXApp#forceRefesh method:
> 
> 	@btnV9.connect(SEL_COMMAND) {
> 		update_list
> 		app.forceRefresh	# reconcile layout immediately!
> 		@lst.makeItemVisible 9
> 	}
> 
> > But when not just after, the 'create' is needless.
> 
> Correct. In this case, the calls to clearItems() and appendItem() in 
> @btnUp's callback:
> 
> 	@btnUp.connect(SEL_COMMAND) {
> 		update_list
> 	}
> 
> Mark the list's layout as dirty, and shortly after we re-enter FOX's 
> main event loop, the GUI layout is reconciled. Now any subsequent call 
> to makeItemVisible() will work properly.
> 
> Hope this helps,
> 
> Lyle
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users


┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏

    下川 肇 （しもかわ はじめ）mailto：h-simokawa＠aandd.co.jp
    株式会社 エー・アンド・デイ 設計開発本部 １３２課

    住所 埼玉県北本市朝日１−２４３ （郵便番号 ３６４−８５８５）
    電話 ０４８-５９３−１８２７（１３２課直通）
    ＦＡＸ ０４８-５９３−１１１９
┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏┏

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

SIMOKAWA hajime wrote:

> Another Question:
> The 'makeItemVisible' is not working just after 'clearItems'.
> A 'create' is need before 'makeItemVisible'.

When you call clearItems() and, subsequently appendItem(), on the list, 
the list's layout is marked as dirty but it is not immediately 
reconciled. FOX uses a technique of delayed layout, which is described 
on this page from the FOX documentation:

	http://www.fox-toolkit.org/guiupdate.html

Under normal circumstances, the GUI layout will not actually be 
reconciled until we return to the main FOX event loop, i.e. until we 
exit the callback for @btnV9. The problem in your case is that 
makeItemVisible() assumes that the list's layout has already been 
reconciled, which it hasn't. So the solution is to do *something* to 
force the layout to be reconciled immediately, before the call to 
makeItemVisible(). Calling create() on the main window is one way to do 
this, but the more proper way is to call the FXApp#forceRefesh method:

	@btnV9.connect(SEL_COMMAND) {
		update_list
		app.forceRefresh	# reconcile layout immediately!
		@lst.makeItemVisible 9
	}

> But when not just after, the 'create' is needless.

Correct. In this case, the calls to clearItems() and appendItem() in 
@btnUp's callback:

	@btnUp.connect(SEL_COMMAND) {
		update_list
	}

Mark the list's layout as dirty, and shortly after we re-enter FOX's 
main event loop, the GUI layout is reconciled. Now any subsequent call 
to makeItemVisible() will work properly.

Hope this helps,

Lyle

Re: [Fxruby-users] Usage FXList : makeItemVisible

[SIMOKAWA h. <h-s...@aa...>]

Hello all.
Thanks for Dalibor Sramek and meinrad recheis.

I have confirmed that the 'makeItemVisible' works after 'show'.

Another Question:
The 'makeItemVisible' is not working just after 'clearItems'.
A 'create' is need before 'makeItemVisible'.
But when not just after, the 'create' is needless.

Below is my code.
If you delete line#2, btnV9 is not work.
If you delete line#1 and #2, btnV9 is work after pushing btnUp.

Thanks for the help in advance

SIMOKAWA, hajime (male,japan)



require 'fox'
include Fox

class ListTestWindow < FXMainWindow
  def initialize(app)
    super(app, "fxtest", nil, nil, DECOR_ALL, 0, 0, 100)

    @btnV0 = FXButton.new(self,'visible 0',nil,nil,0,BUTTON_NORMAL |LAYOUT_FILL_X)
    @lst = FXList.new(self,4,nil,0,LIST_NORMAL |LAYOUT_FILL_X)
    @btnV9 = FXButton.new(self,'visible 9',nil,nil,0,BUTTON_NORMAL |LAYOUT_FILL_X)
    @btnUp = FXButton.new(self,'update',nil,nil,0,BUTTON_NORMAL |LAYOUT_FILL_X)
    self.update_list

    @btnV0.connect(SEL_COMMAND){
      @lst.makeItemVisible 0
    } 
    @btnV9.connect(SEL_COMMAND){
      update_list  #1 when 'update' put here,
      create       #2 'create' must be after update
      @lst.makeItemVisible 9
    } 
    @btnUp.connect(SEL_COMMAND){
      update_list;  #3 'create' is needless
    } 
  end
  
  def update_list
    @lst.clearItems
    @lst.appendItem '0'
    @lst.appendItem '1'
    @lst.appendItem '2'
    @lst.appendItem '3'
    @lst.appendItem '4'
    @lst.appendItem '5'
    @lst.appendItem '6'
    @lst.appendItem '7'
    @lst.appendItem '8'
    @lst.appendItem '9'
  end

  def create
    super
    show(PLACEMENT_SCREEN)
  end
end

if __FILE__ == $0
  app = FXApp.new("FoxTest", "FoxTest")
  ListTestWindow.new(app)
  app.create
  app.run
end

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

meinrad recheis wrote:

> lyle: could it be implemented that makeItemVisible takes both an item or 
> an index?

Yes, I think this kind of overloading makes sense for FXIconList and 
FXList. Not sure that it is really useful for FXTreeList since that's 
not a flat list.

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

Quoting meinrad recheis <mei...@gm...>:
> > The method makeItemVisible takes a tree item as the argument - not the
> item
> > index.
> dalibor: where did you get this information?
> 
> here is what the online documentation for FXList#makeItemVisible says
> 
> ------------------------------------------------
> makeItemVisible(index)
> 
> Scroll to bring item into view. Raises IndexError if index is out of bounds.
> -----------------------------------------------

Oops. I have been looking at FXTreeList.
I am sorry. I spent a couple of hours playing with the FXTreeList recently so my
brain took it automaticaly.

Dalibor

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

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

Dalibor Sramek wrote:

> Hi.
> 
> The method makeItemVisible takes a tree item as the argument - not the item
> index.

[...]

ah, i see. you had treelist in mind.
actually this is an inconsistency issue that should be addressed to lyle.

FXTreeList#makeItemVisible(item)
FXList#makeItemVisible(index)

lyle: could it be implemented that makeItemVisible takes both an item or 
an index?

> 
> Regards,
> 
> Dalibor
> 

- henon

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

Dalibor Sramek wrote:
> Hi.
> 
> The method makeItemVisible takes a tree item as the argument - not the item
> index.
dalibor: where did you get this information?

here is what the online documentation for FXList#makeItemVisible says

------------------------------------------------
makeItemVisible(index)

Scroll to bring item into view. Raises IndexError if index is out of bounds.
-----------------------------------------------

> Try replacing your code with:
> 
> item7 = @lst.appendItem '7'
> @lst.appendItem '8'
> @lst.appendItem '9'
> @lst.makeItemVisible item7
> 
> Regards,
> 
> Dalibor

-- henon
> 

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

SIMOKAWA hajime wrote:

> Hello all,
>   
hi,

>  I am trying to do something with FxRuby, but it is not working for me. 
> I want to scroll to bring a item into view, but I cannot it. 
> Below is my code.

the line
@lst.makeItemVisible 7
works well for me when inserted after show(PLACEMENT_SCREEN)
obviously this can only be used after creation of the list.
> 
> Thanks for the help in advance
> 
> SIMOKAWA, hajime (male,japan)
> 
regards,
-- henon
> 
> 
> require 'fox'
> include Fox
> 
> class ListTestWindow < FXMainWindow
>   def initialize(app)
>     super(app, "fxtest", nil, nil, DECOR_ALL, 0, 0, 100, 100)
> 
>     @lst = FXList.new(self,4,nil,0,LIST_NORMAL |LAYOUT_FILL_X)
>     @lst.appendItem '0'
>     @lst.appendItem '1'
>     @lst.appendItem '2'
>     @lst.appendItem '3'
>     @lst.appendItem '4'
>     @lst.appendItem '5'
>     @lst.appendItem '6'
>     @lst.appendItem '7'
>     @lst.appendItem '8'
>     @lst.appendItem '9'
> 
>     @lst.makeItemVisible 7 
> 
>   end
> 
>   def create
>     super
>     show(PLACEMENT_SCREEN)
       @lst.makeItemVisible 7

>   end
> end
> 
> if __FILE__ == $0
>   app = FXApp.new("FoxTest", "FoxTest")
>   ListTestWindow.new(app)
>   app.create
>   app.run
> end
> 
> 

Re: [Fxruby-users] Usage FXList : makeItemVisible

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

Hi.

The method makeItemVisible takes a tree item as the argument - not the item
index.
Try replacing your code with:

item7 = @lst.appendItem '7'
@lst.appendItem '8'
@lst.appendItem '9'
@lst.makeItemVisible item7

Regards,

Dalibor

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



Quoting SIMOKAWA hajime <h-s...@aa...>:

> Hello all,
>   
>  I am trying to do something with FxRuby, but it is not working for me. 
> I want to scroll to bring a item into view, but I cannot it. 
> Below is my code.
> 
> Thanks for the help in advance
> 
> SIMOKAWA, hajime (male,japan)
> 
> 
> 
> require 'fox'
> include Fox
> 
> class ListTestWindow < FXMainWindow
>   def initialize(app)
>     super(app, "fxtest", nil, nil, DECOR_ALL, 0, 0, 100, 100)
> 
>     @lst = FXList.new(self,4,nil,0,LIST_NORMAL |LAYOUT_FILL_X)
>     @lst.appendItem '0'
>     @lst.appendItem '1'
>     @lst.appendItem '2'
>     @lst.appendItem '3'
>     @lst.appendItem '4'
>     @lst.appendItem '5'
>     @lst.appendItem '6'
>     @lst.appendItem '7'
>     @lst.appendItem '8'
>     @lst.appendItem '9'
> 
>     @lst.makeItemVisible 7 
> 
>   end
> 
>   def create
>     super
>     show(PLACEMENT_SCREEN)
>   end
> end
> 
> if __FILE__ == $0
>   app = FXApp.new("FoxTest", "FoxTest")
>   ListTestWindow.new(app)
>   app.create
>   app.run
> end
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users
>