fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] A couple of questions

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

kel...@so... wrote:

> I have a couple of questions:
> 1) When I use PLACEMENT_MAXIMIZED (e.g., WT_MainWindow.new.show 
> PLACEMENT_MAXIMIZED) the window hides the Windows task bar and the 
> application's title bar is not fully visible.  Is this normal?  (Note 
> that this isn't what happens when you click on the maximize button in 
> the top right of the app's control box).

Will check this in awhile when I can get back to a Windows box...

> 2)  I'm not sure if this is a bug, but ... I've subclassed FXIconItem 
> (so I can do sorting).  If I want to create a new item, I can say 
> MySubClassedFXIconItem.new("string", myBigIcon, myMiniIcon, myObject).  
> The constructor for MySubClassedFXIconItem should be:
> def initialize(string, bigIcon, miniIcon, object)
> super(string, bigIcon, miniIcon, object)
> end
> but that gives a TypeError ("wrong argument type ... expected Data")
> However, this works:
> def initialize(string, bigIcon, miniIcon, object)
> super(string, bigIcon, miniIcon)
> self.data = object
> end
> so it's not a big deal.  But I think the first way is more elegant and 
> so I'm mentioning it.

This is definitely a bug, and I will add it to the list. Thanks very 
much for reporting this.

> 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

Hope this helps,

Lyle

Re: [Fxruby-users] changing overall behavior - was (re: [Foxgui-users]making fox a superior toolkit)

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

Recheis Meinrad wrote:

> i have asked you several times about this(changing the behavior of a widget) but it seems that you have misunderstood me or i have misunderstood you, or both.

Yes.

> what about this "first chance callbacks" jeroen talks about (see his post below)?
> i would like to know whether these can be used in FXRuby too.

Yes, this refers to the connect() method that I've referred to several 
times now.

> you once said (in other words for you, if i got you right): 
>> fox widgets catch events react and then block them.
>> so it is not possible to overwrite the default behavior for these events.

If I said this, I misspoke.

Let me describe the typical pattern for how events get processed by FOX, 
as I understand it. I will specifically focus on the things that happen 
when a user clicks on an FXButton widget, but I think this pattern is 
generally true for other kinds of events.

When you "click" on an FXButton in a FOX GUI with the left mouse button, 
two events are generated: a "left mouse button down" event and a "left 
mouse button up". FOX assigns the names SEL_LEFTBUTTONPRESS and 
SEL_LEFTBUTTONRELEASE, respectively.

The SEL_LEFTBUTTONPRESS message is always sent *directly* to the 
FXButton widget, first thing. And if you don't do anything special in 
your program, the FXButton *does* implement some default behavior in 
response to that message.

But you can circumvent this default behavior for SEL_LEFTBUTTONPRESS by 
taking advantage of what Jeroen referred to as "first-chance" callbacks, 
and you do this in your programs by attaching a handler block or method 
to the FXButton widget:

     theButton = FXButton.new(...)
     theButton.connect(SEL_LEFTBUTTONPRESS) {
     }

When you use the #connect method to attach a handler to the widget, you 
are asking the FXButton to call this block of code to handle the 
message, instead of relying on the default behavior. In other words, 
your code gets the "first chance" to handle the SEL_LEFTBUTTONPRESS message.

> it seems possible to override the default behavior in C++. A possibility that arises from that: you could 
> override the default behavior of all widgets (for right mouse click, for instance)
> this would be very useful to me. but it's not useful if i cannot pop up a menu on every widget (using right click).

I think I'm correct in saying that you can't override the default 
behavior for *all* widgets in one fell swoop, either in C++ or in Ruby. 
That is because most widgets already have customized behavior for those 
messages. To use a non-FOX example, pretend you've designed a library 
representing animals, with this base class:

     class Animal
       def speak
         ""
       end
     end

Then you start subclassing that for various animals:

     class Cat < Animal
       def speak
         "Meow!"
       end
     end

     class Dog < Animal
       def speak
         "Woof!"
       end
     end

     class Cow < Animal
       def speak
         "Moo!"
       end
     end

So now each of the subclasses has a customized behavior for #speak, with 
the result:

     Cat.new.speak # answers "Meow!"
     Dog.new.speak # answers "Woof!"
     Cow.new.speak # answers "Moo!"

But what if a user of your library decides that he wants each of the 
animals to instead stomp its foot on the ground when he calls #speak? 
You can't just change this behavior in one place -- you would need to 
modify each of the subclasses to update their behavior.

[Fxruby-users] A couple of questions

[<kel...@so...>]

Hi everyone, 

I have a couple of questions: 

1) When I use PLACEMENT_MAXIMIZED (e.g., WT_MainWindow.new.show 
PLACEMENT_MAXIMIZED) the window hides the Windows task bar and the 
application's title bar is not fully visible.  Is this normal?  (Note that 
this isn't what happens when you click on the maximize button in the top 
right of the app's control box). 

2)  I'm not sure if this is a bug, but ... I've subclassed FXIconItem (so I 
can do sorting).  If I want to create a new item, I can say 
MySubClassedFXIconItem.new("string", myBigIcon, myMiniIcon, myObject).  The 
constructor for MySubClassedFXIconItem should be: 

def initialize(string, bigIcon, miniIcon, object)
super(string, bigIcon, miniIcon, object)
end 

but that gives a TypeError ("wrong argument type ... expected Data") 

However, this works: 

def initialize(string, bigIcon, miniIcon, object)
super(string, bigIcon, miniIcon)
self.data = object
end 

so it's not a big deal.  But I think the first way is more elegant and so 
I'm mentioning it. 

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? 

Any help would be appreciated. 

Thanks, 

Karl. 

Re: [Fxruby-users] having FXTable contain widgets?

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

Recheis Meinrad wrote:

> do you think it is possible to subclass FXTable or FXTableItem (in Ruby) 
> in order to make a table of widgets possible?
> i am asking this, because i am not satisfied with making a sort of table 
> by nesting FXMatrices.

It *may* be possible, but I have the feeling that it's going to be very 
difficult. I know that some people have tried to do this in the past for 
the C++ library, with varying degrees of success. The basic problem is 
that the table items themselves are just data objects and not windows. 
That is, when you create an FXTable with 1000 cells, it is still just 
one *window* on the screen. As you know, it's different from an FXMatrix 
layout, where each individual "cell" in the matrix is its own window. A 
matrix with 1000 cells consists of 1001 windows.

If this is something that you seriously want to pursue, I think I'd 
start by looking at the FOX Extension Library (at 
http://foxdesktop.sourceforge.net). This *is* a C++ library, but I think 
they may have an "editable" table widget which may give you some ideas.

Hope this helps,

Lyle

[Fxruby-users] changing overall behavior - was (re: [Foxgui-users]making fox a superior toolkit)

[Recheis M. <Mei...@av...>]

hi lyle,

i have asked you several times about this(changing the behavior of a =
widget) but it seems that you have misunderstood me or i have =
misunderstood you, or both.

what about this "first chance callbacks" jeroen talks about (see his =
post below)?
i would like to know whether these can be used in FXRuby too.

you once said (in other words for you, if i got you right):=20
> fox widgets catch events react and then block them.
> so it is not possible to overwrite the default behavior for these =
events.

it seems possible to override the default behavior in C++. A possibility =
that arises from that: you could=20
override the default behavior of all widgets (for right mouse click, for =
instance)
this would be very useful to me. but it's not useful if i cannot pop up =
a menu on every widget (using right click).

hope you know what i am trying to say, and excuse for my bad english.
regards,
- Henon


jeroen wrote (on the Foxgui_users ML):
[snip]
> - giving the user a possibility to change the default behavior of =
widgets
> (this is very frustrating to ruby programmers, because we can simply
> overwrite behavior in base classes. but in fox, if i overwrite
> onLeftButtonPress in FXWindow to get the same behavior for any widget =
in
> the toolkit doesn't work with FXRuby. Don't know whether this is =
possible
> somehow in C++)

Most widgets bounce a "first chance callback" to their target (i.e. =
*your*
code), so that your own handler may override the normal widget =
translation.
You can do this without subclassing the C++ class so (and I have to =
defer
to Lyle here) if FXRuby allows for the handler to be caught you may =
actually
be able to do quite a bit of 'behaviour modification".

For example, if you press, move, release the left mouse button in some
widget then these messages are bounced of the widget's target first; if
the target's message handler returns 0, the translation of the messages
proceeds according to the widget's own internal logic.  However if the
target's handlers return 1 then the widget doesn't "see" these events
and your message handlers are basically in charge.

While you do need to be fairly familiar with the toolkit to use this
productively, it is certainly very nice to be able to do this as it
won't involve subclassing the widget (which, working form Ruby, you
are not able to do so easily).
[snip]

AW: [Fxruby-users] having FXTable contain widgets?

[Recheis M. <Mei...@av...>]

emmanuel:  i am afraid this helps not so much ...
i am reading the foxGui users list.  and that post you mention is a =
reply to a question i posted there.=20
here is the reason why i am posting here: to ask whether it is possible =
to subclass FXTableItem in ruby (in order to contain other widgets)!!!
i don't want to subclass FXTableItem in C++ (i hate c++)
- Henon


Emmanuel Touzery wrote:


Hello!

Recheis Meinrad wrote:

>hi lyle,
>
>do you think it is possible to subclass FXTable or FXTableItem (in =
Ruby) in order to make a table of widgets possible?
>i am asking this, because i am not satisfied with making a sort of =
table by nesting FXMatrices.
> =20
>
Jeroen (FOX maintainer) discussed than on the FOX ml today :O)
unfortunately the SF website seems down, with the ml archives, so i'll=20
copy-paste:

seen in thread " [Foxgui-users]making fox a superior toolkit", mail from =

je...@fo....

"
Mei...@av... wrote:

> - a grid layout manager with options to draw the gridlines like in a =
table
> (please, please!!) - different look and feels


We have FXTable, but this contains items (which are simple C++ objects,
not widgets.  FXTableItem is easily subclassed for custom drawing and/or
contents.

There is also FXMatrix, which arranges widgets in rows and columns; with
creative setting of colors and inter-child spacings you can also use it
as a (small) table.
"

HTH,

emmanuel

Re: [Fxruby-users] having FXTable contain widgets?

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

Hello!

Recheis Meinrad wrote:

>hi lyle,
>
>do you think it is possible to subclass FXTable or FXTableItem (in Ruby) in order to make a table of widgets possible?
>i am asking this, because i am not satisfied with making a sort of table by nesting FXMatrices.
>  
>
Jeroen (FOX maintainer) discussed than on the FOX ml today :O)
unfortunately the SF website seems down, with the ml archives, so i'll 
copy-paste:

seen in thread " [Foxgui-users]making fox a superior toolkit", mail from 
je...@fo....

"
Mei...@av... wrote:

> - a grid layout manager with options to draw the gridlines like in a table
> (please, please!!) - different look and feels


We have FXTable, but this contains items (which are simple C++ objects,
not widgets.  FXTableItem is easily subclassed for custom drawing and/or
contents.

There is also FXMatrix, which arranges widgets in rows and columns; with
creative setting of colors and inter-child spacings you can also use it
as a (small) table.
"

HTH,

emmanuel

[Fxruby-users] having FXTable contain widgets?

[Recheis M. <Mei...@av...>]

hi lyle,

do you think it is possible to subclass FXTable or FXTableItem (in Ruby) =
in order to make a table of widgets possible?
i am asking this, because i am not satisfied with making a sort of table =
by nesting FXMatrices.

- Henon

Re: [Fxruby-users] (unit) testing and FXRuby.

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

On Fri, 15 Aug 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > success using it with Ruby.  In Tk you could send messages from one
        [...]
>
> GUI testing in general is a gray area, no question about it. At last

It is tricky but without the hooks it is even more so! :-)

> that he'd considered titling his presentation, "How to test GUIs",
> because he knew that if he did that he was guaranteed to have a large
> audience ;)

Yes, that would be true!
>
> > Also, are there ways to interrogate the application so I can assert
> > that "clicking ThatWidget means ThisWidget is now visible", etc?
> > I'm thinking my debugging process might go more smoothly if I can
> > drive the UI consistently.  Are there idioms for this yet?
>
> No, we don't have any kind of higher-level framework for that kind of
> thing, although it sounds like a good idea. I wonder if you might be
> able to leverage some of the work from Xnee:

I'll have to explore these. I have not heard of them before.
>
>      http://www.gnu.org/software/xnee
>
> or maybe this Perl module:
>
>      http://sourceforge.net/projects/x11guitest
>
> Of course, those are both X-specific, but it's a start.

Thanks.
>
> Hope this helps,
>
> Lyle
>
        Hugh

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

Hugh Sasse Staff Elec Eng wrote:

> I have just had some interesting results.  I was explaining to
> someone that I have spent ages trying to do this, and, look, doesn't
> work, and when I double click on the treelist nothing happens, BUT
> IT DID!  I now find that my items are being added to the treeItem
> but the item is not actually opened/expanded.

I should have thought of that. Oh well, glad to hear that it's working.

> OK, I can work with this.  What is the semantic difference between
> opening and expanding in tree lists? At the moment when I want to
> open I open and expand, and conversely collapse and close together.
> What is the right thing to do for these?

I think that what you are doing is the right thing to do, for your 
application.

When you programmatically open or close an item (i.e. by calling the 
openItem() or closeItem() methods) it only changes that item's state 
from "opened" to "closed", or vice-versa. If that tree item has 
different icons for the open and closed state, such as an opened and 
closed file folder, this will be the only visible cue of the change.

There are some situations where it is useful to make this distinction 
(of opened versus closed); I'll describe one of them in a few 
paragraphs. But for your application, this may not be a useful 
distinction. In that, you may want to just use the same icon for both 
the opened and closed state and ignore that issue altogether (i.e. just 
worry about expanding or collapsing the subtrees at the appropriate times).

Expanding and collapsing parts of the tree is a separate action and is 
independent of the "root" item's opened or closed state. That is, you 
can expand the subtree under an item without actually "opening" it.

I'm not sure I can give you a precise description of the /semantics/ of 
open/close versus expand/collapse.

This feature of the tree list was specifically added for developing 
Windows Explorer-like widgets, where there's a tree list on the left and 
a different view of the current item's contents on the right. So, if the 
user clicks *once* on a directory folder in the tree list (e.g. "My 
Documents"), that tree item is *opened*, and that folder's contents are 
shown in the right-hand pane; but the tree item is not *expanded* unless 
the user double-clicks on it.

Hope this helps,

Lyle

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

On Fri, 15 Aug 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > IT DID!  I now find that my items are being added to the treeItem
> > but the item is not actually opened/expanded.
>
> I should have thought of that. Oh well, glad to hear that it's working.

I have made it default to doing that now.
>
> > OK, I can work with this.  What is the semantic difference between
> > opening and expanding in tree lists? At the moment when I want to
> > open I open and expand, and conversely collapse and close together.
> > What is the right thing to do for these?
>
> I think that what you are doing is the right thing to do, for your
> application.

Yes, I suspect so.
>
> When you programmatically open or close an item (i.e. by calling the
> openItem() or closeItem() methods) it only changes that item's state
> from "opened" to "closed", or vice-versa. If that tree item has
> different icons for the open and closed state, such as an opened and
> closed file folder, this will be the only visible cue of the change.

OK, so it doesn't do anything else. Fair enough.
>
> There are some situations where it is useful to make this distinction
> (of opened versus closed); I'll describe one of them in a few

Yes, Windows Explorer does this with the left pane you can open the
directory in the right without expanding on the left.  It's this
sort of feel I wanted to supply to users, so this is good.

> paragraphs. But for your application, this may not be a useful
> distinction. In that, you may want to just use the same icon for both

In fact I haven't drawn or found icons yet, that can wait, but I
agree.
>
>
> I'm not sure I can give you a precise description of the /semantics/ of
> open/close versus expand/collapse.

I think you have actually, but since there is no comment about this
that I can find... I'll have to poke about in the FXRuby 1.0.25 dist
and add some rdocs for others who tread this way, and bowl a patch
in your direction.
>
> This feature of the tree list was specifically added for developing
> Windows Explorer-like widgets, where there's a tree list on the left and
> a different view of the current item's contents on the right. So, if the

Right. This ability to carry experience over is good.

> user clicks *once* on a directory folder in the tree list (e.g. "My
> Documents"), that tree item is *opened*, and that folder's contents are
> shown in the right-hand pane; but the tree item is not *expanded* unless
> the user double-clicks on it.

Thanks.  and the + signs behave slightly differently I think, in
Win, but I'll have to stop "using it by coincidence" and actually
note what happens next time!
>
> Hope this helps,

Yes, that's the info I was after.
>
> Lyle
>
        Hugh

Re: [Fxruby-users] (unit) testing and FXRuby.

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

Hugh Sasse Staff Elec Eng wrote:

> Before I started on FOX I used to use Tk, though I have not had much
> success using it with Ruby.  In Tk you could send messages from one
> program to another, or even within the same program, and buttons had
> an action command that effectively clicked the button.  If I want to
> drive a GUI programmatically in FXRuby, what should I be using?

I'm not all that familiar with Tk, and certainly not this aspect of Tk 
that you're describing, so I'm not sure what to say about it. I don't 
guess that FOX has any built-in capabilities for inter-process 
communication between FOX applications (other than of course things like 
drag-and-drop).

GUI testing in general is a gray area, no question about it. At last 
year's Ruby Conference in Seattle, Nathaniel Talbott gave a talk on 
acceptance testing. During the introductory remarks he jokingly remarked 
that he'd considered titling his presentation, "How to test GUIs", 
because he knew that if he did that he was guaranteed to have a large 
audience ;)

> Also, are there ways to interrogate the application so I can assert
> that "clicking ThatWidget means ThisWidget is now visible", etc?
> I'm thinking my debugging process might go more smoothly if I can
> drive the UI consistently.  Are there idioms for this yet?

No, we don't have any kind of higher-level framework for that kind of 
thing, although it sounds like a good idea. I wonder if you might be 
able to leverage some of the work from Xnee:

     http://www.gnu.org/software/xnee

or maybe this Perl module:

     http://sourceforge.net/projects/x11guitest

Of course, those are both X-specific, but it's a start.

Hope this helps,

Lyle

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

I have just had some interesting results.  I was explaining to
someone that I have spent ages trying to do this, and, look, doesn't
work, and when I double click on the treelist nothing happens, BUT
IT DID!  I now find that my items are being added to the treeItem
but the item is not actually opened/expanded.

OK, I can work with this.  What is the semantic difference between
opeing and expanding in tree lists? At the moment when I want to
open I open and expand, and conversely collapse and close together.
What is the right thing to do for these?

My other problem is that the files do not seem to be being created
correctly on the disk, but that is my fault entirely, not a
misunderstanding about FXRuby, so I'm further than I was.

        Thank you.
        Hugh

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

On Thu, 14 Aug 2003, ly...@kn... wrote:

>
> On Thu, 14 Aug 2003 10:42:01 +0100 (BST), Hugh Sasse Staff Elec Eng
> <hg...@dm...> wrote :
>
> > Thank you, but before I trouble you with that, is there any way to
> > get Fox to produce lots of logging?
>
> If you're running under Linux/Unix, and if you didn't build your FOX library

Solaris at the moment....
>
>     ruby hello.rb -tracelevel 101

Thanks, I'll give that a spin and let you know if this helps.
>
> I'm not sure where that output goes on Windows (if it's printed at all)
> since you usually don't have a console present. And for that matter, I don't

Might be OK with rb files, but not rbw... Something to try later...

[....]
> > [If only one could ask it things, like SHRDLU!]
>
> Indeed.
>
> You know, it's funny, there was a Slashdot article just yesterday asking
> what people's expectations were for computers ten years ago (i.e. ten years
> ago, what were your expectations for computers in the year 2003?) And wasn't

I think I expected more full-parallax 3D displays, but didn't expect
the huge disk sizes so common now.  Better quality synthetic speech, too.

> the work on SHRDLU done in the sixties or something? I do wonder a little

1968. Other revisions up till about 73 from what I can find briefly
with google.

> bit about what the remaining challenges are that /do/ prevent us from just
> asking the computer questions and getting a response.

I think it is limited by how much the human writing the code can
hold in their head.  A constraint that varies from person to person!
>
> Of course, like Dilbert's pointy-haired boss, since I don't understand it, I
> assume it must be easy to do ;)

A bit like "Anything is possible for the person who doesn't have to
do it themselves" :-)  I gather that the parsing of English requires
info from the higher, semantic, levels and this increased the
complexity of the code in this case.  But I wouldn't mind asking it
using Ruby: it is the ability to respond_to?() methods like why()
that would really help! Keeping a history of decisions....
>

        Hugh

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

On Thu, 14 Aug 2003, ly...@kn... wrote:

>
>
>     ruby hello.rb -tracelevel 101

This produced no new output at all.

        Hugh (more puzzled)

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

On Thu, 14 Aug 2003, Hugh Sasse Staff Elec Eng wrote:

> Well you're right this time, it didn't result in any items getting
> added to the tree. :-(


further study shows from

        @add_cat_btn.connect(SEL_COMMAND) {
            data = EntryData.new(ops_panel,"New Category")
            result = NameEntryDialog.new(data).execute
            unless result.zero?
                newname = data.value.value
                #Which item was selected from the tree...
                if treelist.currentItem
                    path = File.join(treelist.currentItem.full_path, Base36code.new($freelist.next).representation)
                    puts "item is #{treelist.currentItem.inspect}, children=#{treelist.currentItem.numChildren}"
                    @treeview[path] = treelist.addItemLast(treelist.currentItem, newname,
                    nil, nil, TreeData.new(treelist, path))
                    puts "item is #{treelist.currentItem.inspect}, children=#{treelist.currentItem.numChildren}"
                    treelist.recalc     # tell treelist it has changed...
                                        # Message-ID:
                                        # <3F3...@cf...>
                else
                    ; # raise "No item selected."
                end
            end
        }

I get

item is equipment, children=0
TreeData.new("/home/hgs/stores_loans/data/equipment/00b1bb0")
./stores_loans.rb:318:in `new'
./stores_loans.rb:318:in `initialize'
./stores_loans.rb:309:in `call'
/usr/local/lib/ruby/site_ruby/1.6/fox/responder2.rb:57:in
`onHandleMsg'
./stores_loans.rb:393:in `execute'
./stores_loans.rb:393:in `initialize'
./stores_loans.rb:388:in `call'
/usr/local/lib/ruby/site_ruby/1.6/fox/responder2.rb:57:in
`onHandleMsg'
./stores_loans.rb:461:in `run'
./stores_loans.rb:461
DirIndex.new("/home/hgs/stores_loans/data/equipment/00b1bb0" class:
String)
item is equipment, children=1
called catdialog.create()

Which shows that the number of children is now 1, rather than 0, but
none are displayed.

        Hugh

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

On Wed, 13 Aug 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > expressed as base 36 codes.  When I add a name on its own, I can add
> > to the tree, but if I put the data in, the item doesn't get added to
> > the tree.  I've missed something, but I've been staring at this so
>
> <snip>
>
>
> OK, so you are /sure/ that it's getting inside the if-check inside the
> SEL_COMMAND handler for @add_cat_btn?

Yes, I added the puts just before your recalc suggestion.
>
> If we've confirmed that, please see what happens if you add a call to
> FXTreeList#recalc immediately following that:
>
>      @treeview[path] = treelist.addItemLast(...)
>      treelist.recalc
>
> Calling recalc() marks a widget's layout as "dirty", meaning it nudges
> the parent layout manager to recalculate the layout for that widget and
> its siblings. At first glance, I don't see why this should be necessary,

Agreed: I think additem should trigger that....

> and so I'm skeptical that it's going to make a difference. But I've been
> wrong before ;)

Well you're right this time, it didn't result in any items getting
added to the tree. :-(
>
> If that doesn't work, let me know if you'd like me to take a closer look
> at the code.

Thank you, but before I trouble you with that, is there any way to
get Fox to produce lots of logging?  [If only one could ask it
things, like SHRDLU!]
>
> Hope this helps,
>
> Lyle

        Hugh

Re: [Fxruby-users] Treelist -- can't add new items with data.

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

Hugh Sasse Staff Elec Eng wrote:

> I have a tree list, which is supposed to hold a cross platform
> directory structure: thus it maps names with spaces onto numbers
> expressed as base 36 codes.  When I add a name on its own, I can add
> to the tree, but if I put the data in, the item doesn't get added to
> the tree.  I've missed something, but I've been staring at this so
> long I can't see what it is.  The thing isn't happening when the
> "add category" button is pressed.  The crucial code is here.

<snip>

> I know that an item is selected, because when I had bugs in that
> branch of the code the thing crashed.  Do I need to fire off some
> kind of event, or something, to see the change to the tree?  When I
> just did treelist.additem(treelist.current, "name") name got added.

OK, so you are /sure/ that it's getting inside the if-check inside the 
SEL_COMMAND handler for @add_cat_btn?

     @add_cat_btn.connect(SEL_COMMAND) {
       # collect info from dialog box
       unless result.zero?
         if treelist.currentItem
           puts "Yes, I am here!"
           @treeview[path] = treelist.addItemLast(...)
         end
       end
     }

If we've confirmed that, please see what happens if you add a call to 
FXTreeList#recalc immediately following that:

     @treeview[path] = treelist.addItemLast(...)
     treelist.recalc

Calling recalc() marks a widget's layout as "dirty", meaning it nudges 
the parent layout manager to recalculate the layout for that widget and 
its siblings. At first glance, I don't see why this should be necessary, 
and so I'm skeptical that it's going to make a difference. But I've been 
wrong before ;)

If that doesn't work, let me know if you'd like me to take a closer look 
at the code.

Hope this helps,

Lyle

Re: [Fxruby-users] New FXRuby developer needing some direction...

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

Marc Cartright wrote:

> 	I'm trying to use FXRuby to create a graphical image markup tool,
> and being new to Fox and FXRuby, I'm having some trouble getting FXRuby to play
> nicely. I'm trying to make a program to open a TIFF image, draw it on a
> FXCanvas as a sort of background, and allow for "highlighting" of parts of the
> image (basically translucent rectangles on certain locations of the image).

OK.

> Here are the major roadblocks I'm currently having:
> 
> 	- The rectangles I draw seem to ignore any alpha setting I set on
> 		a FXColor. I use FXRGBA, and no matter what I set the alpha to,
> 		the rectangles are completely opaque. Does alpha not work
> 		in the Fox library, or am I missing something?

I think for what you are trying to accomplish, you need to change the 
"blit" mode used for drawing those rectangles over the existing image. 
You can do this using the setFunction() method for the FXDC, i.e.

     dc = FXDCWindow.new(theCanvas)
     dc.setFunction(BLT_SRC_XOR_DST)
     dc.fillRect(...)

The constants representing the different blit modes, and their logical 
meaning, are shown here:

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

Unfortunately, I am not knowledgeable enough about this to know for sure 
which one is the one you're looking for. The default, BLT_SRC, does what 
you've already described: copy everything from the "source" to the 
"destination", and don't keep any of the bits from the destination 
bitmap. Obviously, that's not the right choice ;) If your 
experimentation with a few different blit modes doesn't pan out, I would 
recommend re-posting the question to the foxgui-users mailing list 
(where you will probably get a more knowledgeable response). [This is of 
course not an FXRuby-specific problem.]

> 	- I want to place the FXCanvas in a FXScrollWindow, and get it to 
> 		scroll over the image. It more or less works when I load an
> 		image, but if I resize the main window it just crops the 
> 		image to the window size, and that's it. I can't get the whole
> 		image to display again in the scroll window. How can I get the
> 		FXCanvas size to stay static even if I resize the FXMainWindow/
> 		FXScrollWindow?

The FXCanvas isn't persistent, i.e. it doesn't "remember" its contents. 
It relies on its message target to do all of the drawing. Without 
actually seeing your code, I would guess that whenever a new part of the 
canvas scrolls into or out of view in the scroll window, the canvas is 
firing off SEL_PAINT messages -- but no one is handling those messages.

For an example of what I'm talking about, look at the scribble.rb 
program that comes with FXRuby. You can scribble down a nice little 
sketch, but if you resize the window or do something to "trash" the 
picture, it will be lost. Think "Etch-A-Sketch" ;) Since scribble.rb 
doesn't actually record the various strokes you made to create the drawing.

> 	- I would also like to set a "zoom level" on the image, so that by
> 		setting the level, the image would get rescaled (along with
> 		the rectangles that have been drawn up to that point). I got the
> 		math worked out, but using either FXImage::scale or 
> 		FXDrawable::resize, the canvas just goes black on the resize. Anyone
> 		know why it would be doing that?

The resize() method resizes the client-side pixel buffer used by the 
drawable object (in this case, an FXImage instance) but doesn't 
otherwise do anything interesting. The scale() method should be closer 
to what you're looking for: it not only resizes the buffer, but then 
"stretches" or "shrinks" the current image to fit the new width and height.

I am not 100% sure that FXImage#scale will give you the result that 
you're going for, but in the worst case I wouldn't expect to get a 
"black" image on the other side. If there's any code you can send to 
reproduce the (potential) bug, I'd be glad to take a look.

Hope this helps,

Lyle

[Fxruby-users] (unit) testing and FXRuby.

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

Before I started on FOX I used to use Tk, though I have not had much
success using it with Ruby.  In Tk you could send messages from one
program to another, or even within the same program, and buttons had
an action command that effectively clicked the button.  If I want to
drive a GUI programmatically in FXRuby, what should I be using?
Also, are there ways to interrogate the application so I can assert
that "clicking ThatWidget means ThisWidget is now visible", etc?
I'm thinking my debugging process might go more smoothly if I can
drive the UI consitently.  Are there idioms for this yet?

        Hugh

Re: [Fxruby-users] on/Event/ methods

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

On Tue, 12 Aug 2003 16:24:47 +0200, "Recheis Meinrad"
<Mei...@av...> wrote :

> several on... Methods are available in the module when i browse through
it. now i ask myself wether i can use them or not???

The onXXX() methods for a given class are its message handling methods for
different messages. That is to say, when the widget is sent a particular FOX
message (such as SEL_KEYPRESS), this is the method that will provide the
default behavior for that message, assuming that the widget has no target or
the target doesn't handle the message.

Message handler methods do not have to conform to any particular naming
scheme, but in most cases you can deduce which message a particular method
was intended to handle (e.g. "onMotion" handles SEL_MOTION messages).

In most cases you don't want to call the onXXX() methods directly. If you
want to change the default behavior for some message, you just #connect that
message to some handler block of code, or a method, i.e.

    aWidget.connect(SEL_KEYPRESS) {
        ...
    }

I guess the only time you'd want to call one of the onXXX() methods would be
when you actually subclass a widget. In that case, you might override the
onXXX() method in your derived class, then call the base class method using
super():

    def onMotion(sender, sel, ptr)
      # First, do some custom behavior in response to SEL_MOTION.
      puts "foo"

      # OK, now do the default behavior...
      super
    end

> i would like to alias onRightButtonPress in FXWindow in order to have a
Popup opening when i click on any widget of my gui.

There is no way to just globally change this behavior for every single
widget, since many of them already intercept (and possibly filter out) the
SEL_RIGHTBUTTONPRESS and SEL_RIGHTBUTTONRELEASE messages. But for a
particular widget of interest, you can catch this message and do something
about it with, for example,

    someWidget.connect(SEL_RIGHTBUTTONRELEASE) {
        ...
    }

Hope this helps,

Lyle

[Fxruby-users] Treelist -- can't add new items with data.

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

I think I am being terminally stupid here or something. I have been
fiddling with this thing for far longer than I care to mention.

I have a tree list, which is supposed to hold a cross platform
directory structure: thus it maps names with spaces onto numbers
expressed as base 36 codes.  When I add a name on its own, I can add
to the tree, but if I put the data in, the item doesn't get added to
the tree.  I've missed something, but I've been staring at this so
long I can't see what it is.  The thing isn't happening when the
"add category" button is pressed.  The crucial code is here.


        @treeview = Hash.new()
        @treeview[""] = FXTreeList.new(contents, 10)
        treelist = @treeview[""]
        treelist.listStyle |= TREELIST_SHOWS_LINES | TREELIST_SHOWS_BOXES | TREELIST_ROOT_BOXES
        treelist.layoutHints |=  LAYOUT_FILL_X|LAYOUT_FILL_Y
        @treeview["#{$equipdir}"] =
        treelist.addItemLast(nil,
        "equipment",nil, # openIcon
        nil, # closedIcon
        TreeData.new(treelist, "#{$equipdir}" ) # data
        )
        # If an item is doubleclicked, we want to expand or contract
        # it as appropriate
        treelist.connect(SEL_DOUBLECLICKED) { |sender, selector, data|
            # puts "data is #{data.inspect} : #{data.class}"
            puts "data.data is #{data.data.inspect} : #{data.data.class}"
            treelist.selectItem(data)
            if treelist.itemOpened?(data)
                # true if open
                treelist.collapseTree(data)
                treelist.closeItem(data)
            else
                # false  if closed
                treelist.openItem(data)
                treelist.expandTree(data)
                obtain_tree_entry(data.data)
            end
        }
        ops_panel = FXVerticalFrame.new(contents)
        @add_cat_btn = FXButton.new(ops_panel, "add Category")
        @add_cat_btn.connect(SEL_COMMAND) {
            data = EntryData.new(ops_panel,"New Category")
            result = NameEntryDialog.new(data).execute
            unless result.zero?
                newname = data.value.value
                #Which item was selected from the tree...
                if treelist.currentItem
                    path = File.join(treelist.currentItem.full_path, Base36code.new($freelist.next).representation)
                    @treeview[path] = treelist.addItemLast(treelist.currentItem, newname,
                    nil, nil, TreeData.new(treelist, path))
                else
                    ; # raise "No item selected."
                end
            end
        }


I know that an item is selected, because when I had bugs in that
branch of the code the thing crashed.  Do I need to fire off some
kind of event, or something, to see the change to the tree?  When I
just did treelist.additem(treelist.current, "name") name got added.

        Hugh

[Fxruby-users] on/Event/ methods

[Recheis M. <Mei...@av...>]

hi

what's up with the on- methods?
several on... Methods are available in the module when i browse through =
it. now i ask myself wether i can use them or not???

i would like to alias onRightButtonPress in FXWindow in order to have a =
Popup opening when i click on any widget of my gui.
you know what i mean. but it doesn't work.
lyle: what are those on methods for in FXRuby?

- henon

[Fxruby-users] New FXRuby developer needing some direction...

[Marc C. <ma...@is...>]

Hi,

	I'm trying to use FXRuby to create a graphical image markup tool,
and being new to Fox and FXRuby, I'm having some trouble getting FXRuby to play
nicely. I'm trying to make a program to open a TIFF image, draw it on a
FXCanvas as a sort of background, and allow for "highlighting" of parts of the
image (basically translucent rectangles on certain locations of the image).

Here are the major roadblocks I'm currently having:

	- The rectangles I draw seem to ignore any alpha setting I set on
		a FXColor. I use FXRGBA, and no matter what I set the alpha to,
		the rectangles are completely opaque. Does alpha not work
		in the Fox library, or am I missing something?

	- I want to place the FXCanvas in a FXScrollWindow, and get it to 
		scroll over the image. It more or less works when I load an
		image, but if I resize the main window it just crops the 
		image to the window size, and that's it. I can't get the whole
		image to display again in the scroll window. How can I get the
		FXCanvas size to stay static even if I resize the FXMainWindow/
		FXScrollWindow?

	- I would also like to set a "zoom level" on the image, so that by
		setting the level, the image would get rescaled (along with
		the rectangles that have been drawn up to that point). I got the
		math worked out, but using either FXImage::scale or 
		FXDrawable::resize, the canvas just goes black on the resize. Anyone
		know why it would be doing that?


Any advice anyone can give would be greatly appreciated. At this point, I'm not even sure
if the Fox library (the C version) can do what I'm trying to do. Am I just implementing this
thing the wrong way, or am I trying to do the impossible with the library as it is?



					- Marc Cartright

Re: [Fxruby-users] gdb and FXRuby

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

Joel VanderWerf wrote:

> There's no cost in calling create twice on an icon or other widget is 
> there?

No, not really. I think that all of the create() functions are 
structured like:

    if (!xid) {
       ... create resource ...
       xid = ... handle to created resource...
    }

and so you're just "paying" for the if check.