fxruby-users — General-purpose discussion list for FXRuby

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

On Fri, 13 Jun 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> >> The ID_OPEN_FIRST message identifier tells the shutter to open its first
> >> item, so let's make that the message identifier (or selector):
> >>
> >>      openFirstButton.setSelector(FXShutter::ID_OPEN_FIRST)
> >>
> >> So now, when the user clicks this button, it will send a (SEL_COMMAND,
> >> ID_OPEN_FIRST) message to the shutter.
> >
> > So this is sending the ID_OPEN_FIRST selector in the data part of
> > the (sender, message, data) triple?
>
> No. The part of the (sender, message, data) triple is a number that
> incorporates both the message type and identifier. In a previous e-mail,

Oh, so that is why there was that stuff about MIN_ and MAX_ for
these, sowhere in the docs (I can't remember where just now),
because certain bitfields or ranges of number are allocated to each
semantic part.  OK, I'll have to poke about in the C++ with this
partial knowledge, and I may get this....

> Sander referred to two methods you can use to extract the type and
> identifier from the "message" value:
>
>      def someMessage(sender, sel, data)
>        messageType = Fox.SELTYPE(sel)
>        messageId   = Fox.SELID(sel)

Yes, I remember this now.  At the time I thought it was overkill if
one could get the infomation from two separate parmeters! :-)
>        ...
>      end
>
> In most cases you actually don't need to do this, but the information's
> there if you want it. I say that you don't need to do this because,
        [you know where you've been]
>
> > (Incidentally, I don't see setSelector in the http://www.fxruby.org/doc/api/ but that's BTW.)
>
> Yeah, this isn't spelled out clearly in the README part of the API docs,
> but it should be. For all of the getter and setter methods (including
> FXWindow#getSelector and FXWindow#setSelector) there are aliases that
> instead make them look like regular Ruby attr_reader and attr_writer
> methods. So if you look at the documentation for FXWindow:

Hmm. Is this something we should talk to Dave about, options to Rdoc
to make it flag up attrs in the methods pane?  Thanks for this info.
Would people coming to Ruby from FOX in C++ appreciate an alias for
this? (Not that I can remember if RDoc includes aliases in the
methods pane).

>      aWidget.selector = xxx
>
> which I thought was more compact.

And more idiomatic for rubyists.
>
> Hope this helps,

Yes, it is getting clearer. Thank you again.
>
> Lyle
>
>
        Hugh

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

Hugh Sasse Staff Elec Eng wrote:

>> The ID_OPEN_FIRST message identifier tells the shutter to open its first
>> item, so let's make that the message identifier (or selector):
>>
>>      openFirstButton.setSelector(FXShutter::ID_OPEN_FIRST)
>>
>> So now, when the user clicks this button, it will send a (SEL_COMMAND,
>> ID_OPEN_FIRST) message to the shutter.
> 
> So this is sending the ID_OPEN_FIRST selector in the data part of
> the (sender, message, data) triple?

No. The part of the (sender, message, data) triple is a number that 
incorporates both the message type and identifier. In a previous e-mail, 
Sander referred to two methods you can use to extract the type and 
identifier from the "message" value:

     def someMessage(sender, sel, data)
       messageType = Fox.SELTYPE(sel)
       messageId   = Fox.SELID(sel)
       ...
     end

In most cases you actually don't need to do this, but the information's 
there if you want it. I say that you don't need to do this because, 
generally speaking, you know why you ended up in that message handler in 
the first place and there's no need to check the message type or 
identifier to confirm it. For example, consider this code:

     aButton = FXButton.new(...)
     aButton.connect(SEL_COMMAND, method(:onCommand))

     ...

     def onCommand(sender, sel, data)
       #
       # Here, I can check the type of the message using
       # Fox.SELTYPE(sel), but I already know what the
       # answer's going to be. I got here because I "connected"
       # the button's SEL_COMMAND message to this handler method.
       #
     end


> (Incidentally, I don't see setSelector in the http://www.fxruby.org/doc/api/ but that's BTW.)

Yeah, this isn't spelled out clearly in the README part of the API docs, 
but it should be. For all of the getter and setter methods (including 
FXWindow#getSelector and FXWindow#setSelector) there are aliases that 
instead make them look like regular Ruby attr_reader and attr_writer 
methods. So if you look at the documentation for FXWindow:

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

and check its list of "Attributes", you'll see an entry for "selector", 
which has [RW] accessors. So to set the selector for a window, you can use:

     aWidget.setSelector(xxx)

or the more Ruby-esque:

     aWidget.selector = xxx

which I thought was more compact.

Hope this helps,

Lyle

[Fxruby-users] DataTargets, and more about messaging.

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

Maybe this will help deepen my understanding.  I'm building a front
end to some "database", which is probably too grand a name for it.
So I have a login window.  I want to have a button to clear the text
fields.  I don't see a clear method for FXTextField, but then, I'm
using a DataTarget, so that doesn't matter; the two are intimately
connected, right? :-)  The code below is where I am now.  Before
adding the @username.handle() commands, the fields cleared on button
realease, only to get immediately reset to the non-clear values they
just had.  Now I get a problem with

FXRuby.cpp:781: FXASSERT(type!=SEL_NONE) failed.
FXRuby.cpp:781: FXASSERT(type!=SEL_NONE) failed.

so this suggests I have really munged the messages.


class LoginWindow < FXMatrix
    def initialize(parent)
        super(parent, 2, MATRIX_BY_COLUMNS)

        entry_width = 15
	@user = FXDataTarget.new("") # for a string
	@pass = FXDataTarget.new("") # for a string

        @userlabel = FXLabel.new(self, "Username:")
        @username = FXTextField.new(self, entry_width, @user, FXDataTarget::ID_VALUE)
        @passlabel = FXLabel.new(self, "Passphrase:")
        @passphrase = FXTextField.new(self, entry_width,
            @pass, FXDataTarget::ID_VALUE,
            TEXTFIELD_NORMAL|TEXTFIELD_PASSWD)
        @login_button = FXButton.new(self, "login")
        @login_button.connect(SEL_COMMAND) { do_login }
        @clear_button = FXButton.new(self, "clear")
        @clear_button.connect(SEL_COMMAND) { |sender, selector, data|
            @user=""
            # Blast. That didn't work on it's own. Try this as well:
            @username.text =""
            # No, not good enough. Prod it with a message?
            @username.handle(@clear_button, SEL_CHANGED, "")
            # And similarly....
            @pass=""
            @passphrase.text =""
            @passphrase.handle(@clear_button, SEL_CHANGED, "")
        }
    end

    def create
        super
        @userlabel.create()
        @username.create()
        @passlabel.create()
        @passphrase.create()
        @login_button.create()
        @clear_button.create()
    end

    def do_login
        # Convert password to MD5 string.
        require "md5"
        key = MD5.new(@pass).hexdigest
        @pass =""  # Clear this ASAP.

        # Now look this up.
        success = false
        open("passwords", "r") { |pwf|
            # ... Check the password...
            # This "state" thing is the current position in a state
            # machine.
            loans_tool.state.loginsuccess if success
        }
        unless success
            # set state appropriately
            loans_tool.state.loginfailure
        end
    end

end

The construction of the GUI itself has been very pleasant.  The
layouts are working nicely and the diags are helpful.  I think when
I finally grok this messaging stuff I will really enjoy FXRuby.

        Hugh

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

On Fri, 13 Jun 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote [about docs needing fixing]
>
>
> I agree that the documentation on the FOX web site doesn't tell the
> whole story about how message identifiers are used, and instead focuses
> on one particular use. Obviously, if the *only* purpose of the message

Then maybe the fact of this focus should be more explicit.
It's not easy to document things, of course: the *original* Murphy's
law was about people's amazing ability to misunderstand things.
Other remarks about "not being able to make things foolproof because
fools are so ingenious" come to mind, too!

> identifier were to distinguish between senders, you could arguably just
> hang on to a reference to the sender object(s) and compare them when you
> get a message:
        [dispatch on sender code]

>
> But as I (hopefully) explained in my previous response, that in fact
> isn't the whole story when it comes to message identifiers ;)

It is becoming clearer.  Thank you.
>
> Hope this helps,
>
> Lyle
>
        Hugh
>

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

On Fri, 13 Jun 2003, Lyle Johnson wrote:

>
> Message identifiers are not the same things as message types. Message
> identifiers *can* be used as a means of identifying the sender of a
> message, but that's just one use for them.
>
> Multiple objects can send the same type of message to a single receiver
        [...]
> your post, let's work with an example based on that widget. Suppose you
> have a shutter widget:
>
>      aShutter = FXShutter.new(...)
        [...[
>      openFirstButton = FXButton.new(...)
>
> When a button is clicked, it sends a SEL_COMMAND message to its message
> target. When this button (openFirstButton) is clicked, we want it to
> send a message to the shutter, so let's make the shutter its message target:
>
>      openFirstButton.setTarget(aShutter)

(which could be used for the dynamic retargeting we discussed
earlier. OK...)
>
> The ID_OPEN_FIRST message identifier tells the shutter to open its first
> item, so let's make that the message identifier (or selector):
>
>      openFirstButton.setSelector(FXShutter::ID_OPEN_FIRST)
>
> So now, when the user clicks this button, it will send a (SEL_COMMAND,
> ID_OPEN_FIRST) message to the shutter.

So this is sending the ID_OPEN_FIRST selector in the data part of
the (sender, message, data) triple? (Incidentally, I don't see
setSelector in the http://www.fxruby.org/doc/api/ but that's BTW.)
Does SEL_COMMAND have the semantics "If the data is a selector,
respond as if that had been the message", or am I overgeneralizing
now?

> Let's say that you also want to provide a menu command (in a pulldown
        [...]
>      openFirstMenuCommand = FXMenuCommand.new(...)
        [...]
>      openFirstMenuCommand.setTarget(aShutter)
>      openFirstMenuCommand.setSelector(FXShutter::ID_OPEN_FIRST)
>
> Since a menu command sends a SEL_COMMAND message to its target when it
> is selected, this has exactly the same result as the button click did.
>
> Note that for this example, the message identifier (ID_OPEN_FIRST)
> doesn't distinguish between different senders, it's just identifying
> which command we want the shutter to perform.

Ok, so this is using message id to mean ( "don't care", message_type).
This is clearer now, but I must say I find this overloading of the
meaning confusing.  I just wonder how many more things like this
there are to bite me!
>
> Hope this helps,
>
> Lyle
>

        Thank you for your continued patience!
        Hugh

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

Hugh Sasse Staff Elec Eng wrote:

> So, either I am right about this, and the api docs need fixing, or I
> am wrong about this, and http://www.fox-toolkit.org/messages.html
> needs fixing because  it says:
> <quote>
>  The approach taken by FOX is a Target/Message System. Each Widget
>  sends its message to a certain object called the target. As there
>  may be multiple Widgets sending messages to one specific target, a
>  message id is used to tell them apart.
> 
>  Moreover, a single Widget may be able to send several kinds of
>  messages; this problem is solved by typing the messages by a
>  message type. Using the message type and message id, the source and
>  type of a GUI event or action can be uniquely identified.
> </quote>
> 
> Or, is there in fact a third way to understand this, and reconcile
> both these documents?

I agree that the documentation on the FOX web site doesn't tell the 
whole story about how message identifiers are used, and instead focuses 
on one particular use. Obviously, if the *only* purpose of the message 
identifier were to distinguish between senders, you could arguably just 
hang on to a reference to the sender object(s) and compare them when you 
get a message:

     @button1 = FXButton.new(...)
     @button2 = FXButton.new(...)

     ...

     def onMessageReceived(sender, sel, ptr)
       if sender == @button1
         # do something
       elif sender == @button2
         # do something else
       end
       return 1
     end

But as I (hopefully) explained in my previous response, that in fact 
isn't the whole story when it comes to message identifiers ;)

Hope this helps,

Lyle

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

Hugh Sasse Staff Elec Eng wrote:

> Just when I thought I was no longer confused about this:
> 
> On Thu, 12 Jun 2003, Hugh Sasse Staff Elec Eng wrote:
> 
>> OK, reading this in conjunction with paragraphs 3 and 4 of
>>
>> http://www.fox-toolkit.org/messages.html
>>
>> it seems that message_id is actually the sender of the message, and
>> message type is actually the message itself (not counting associated
>> data).  I would have called the message itself the message_id,
> 
> Well, it is not as simple as that.  The FXRuby API docs for
> FXShutter, FXShutterItem, FXScrollbar and FXList at least refer to
> Message Identifiers which are constants, and are not names of the
> originating objects.  So should these be called Message Types for
> consistency with other FOX docs, or what?

Message identifiers are not the same things as message types. Message
identifiers *can* be used as a means of identifying the sender of a
message, but that's just one use for them.

Multiple objects can send the same type of message to a single receiver
for different reasons, and so one use for the identifier is to
distinguish between different messages of the same type. If one of your
GUI's buttons sends you a SEL_KEYPRESS message, you might react
differently than you would if a text field sent the same message type.

Following from that, a more general way to think about message
identifiers is simply as a way to distinguish between different
responses to the same type of message. Since you mentioned FXShutter in
your post, let's work with an example based on that widget. Suppose you
have a shutter widget:

     aShutter = FXShutter.new(...)

and you want to provide some ways to open the first shutter item. One of
those options that you're going to offer is a push button, somewhere on
the GUI, so you construct that button:

     openFirstButton = FXButton.new(...)

When a button is clicked, it sends a SEL_COMMAND message to its message
target. When this button (openFirstButton) is clicked, we want it to
send a message to the shutter, so let's make the shutter its message target:

     openFirstButton.setTarget(aShutter)

The ID_OPEN_FIRST message identifier tells the shutter to open its first
item, so let's make that the message identifier (or selector):

     openFirstButton.setSelector(FXShutter::ID_OPEN_FIRST)

So now, when the user clicks this button, it will send a (SEL_COMMAND,
ID_OPEN_FIRST) message to the shutter.

Let's say that you also want to provide a menu command (in a pulldown
menu) that does the same thing. First you'd construct the menu command:

     openFirstMenuCommand = FXMenuCommand.new(...)

and then set its target and identifier, as you did for the button:

     openFirstMenuCommand.setTarget(aShutter)
     openFirstMenuCommand.setSelector(FXShutter::ID_OPEN_FIRST)

Since a menu command sends a SEL_COMMAND message to its target when it
is selected, this has exactly the same result as the button click did.

Note that for this example, the message identifier (ID_OPEN_FIRST)
doesn't distinguish between different senders, it's just identifying
which command we want the shutter to perform.

Hope this helps,

Lyle

Re: [Fxruby-users] Message Identifiers, Types, etc again.

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

On Fri, 13 Jun 2003, Sander Jansen wrote:

> On Friday 13 June 2003 07:44 am, Hugh Sasse Staff Elec Eng wrote:
> > Just when I thought I was no longer confused about this:
> >
> > On Thu, 12 Jun 2003, Hugh Sasse Staff Elec Eng wrote:
> > > OK, reading this in conjunction with paragraphs 3 and 4 of
> > >
> > > http://www.fox-toolkit.org/messages.html
> > >
> > > it seems that message_id is actually the sender of the message, and
> > > message type is actually the message itself (not counting associated
> > > data).  I would have called the message itself the message_id,
> >
> > Well, it is not as simple as that.  The FXRuby API docs for
> > FXShutter, FXShutterItem, FXScrollbar and FXList at least refer to
> > Message Identifiers which are constants, and are not names of the
> > originating objects.  So should these be called Message Types for
> > consitency with other FOX docs, or what?
> >
> >         Hugh
>
> a message consists of a type and a id. Sometimes called the selector.

Yes, and from the above URL the id is the sender of the message, and
the type is the individual message without data.
>
> In C++ we have the following macros to get the type and id from a selector:
>
> FXSELTYPE(selector)
> FXSELID(selector)
>
> In constructors of widgets, you normally have to input a target and selector.
> In that case, the selector is only the ID. Its still named this way because
> of historically reasons.  Also "getSelector" would give you back the ID.

But then the id is the widget that sent the message. My point is
that
http://www.fxruby.org/doc/api/classes/Fox/FXScrollbar.html
and the similar pages refer to Message Identifiers, and then list
Message types.
<quote>
Message identifiers
ID_TIMEWHEEL:   x
ID_AUTOINC_LINE:        x
</quote>

I currently believe that these cannot be called identifiers because
the identifier is a widget, which is not a constant. A message type
is a constant.

So, either I am right about this, and the api docs need fixing, or I
am wrong about this, and http://www.fox-toolkit.org/messages.html
needs fixing because  it says:
<quote>
 The approach taken by FOX is a Target/Message System. Each Widget
 sends its message to a certain object called the target. As there
 may be multiple Widgets sending messages to one specific target, a
 message id is used to tell them apart.

 Moreover, a single Widget may be able to send several kinds of
 messages; this problem is solved by typing the messages by a
 message type. Using the message type and message id, the source and
 type of a GUI event or action can be uniquely identified.
</quote>

Or, is there in fact a third way to understand this, and reconcile
both these documents?
>
> 	Sander
>
        Hugh

Re: [Fxruby-users] Message Identifiers, Types, etc again.

[Sander J. <sa...@kn...>]

On Friday 13 June 2003 07:44 am, Hugh Sasse Staff Elec Eng wrote:
> Just when I thought I was no longer confused about this:
>
> On Thu, 12 Jun 2003, Hugh Sasse Staff Elec Eng wrote:
> > OK, reading this in conjunction with paragraphs 3 and 4 of
> >
> > http://www.fox-toolkit.org/messages.html
> >
> > it seems that message_id is actually the sender of the message, and
> > message type is actually the message itself (not counting associated
> > data).  I would have called the message itself the message_id,
>
> Well, it is not as simple as that.  The FXRuby API docs for
> FXShutter, FXShutterItem, FXScrollbar and FXList at least refer to
> Message Identifiers which are constants, and are not names of the
> originating objects.  So should these be called Message Types for
> consitency with other FOX docs, or what?
>
>         Hugh

a message consists of a type and a id. Sometimes called the selector.

In C++ we have the following macros to get the type and id from a selector:

FXSELTYPE(selector)
FXSELID(selector)

In constructors of widgets, you normally have to input a target and selector. 
In that case, the selector is only the ID. Its still named this way because 
of historically reasons.  Also "getSelector" would give you back the ID.

	Sander





>
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Fxruby-users mailing list
> Fxr...@li...
> https://lists.sourceforge.net/lists/listinfo/fxruby-users

-- 
"Mother, should I run for President?
Mother, should I trust the government?
Mother, will they put me in the firing line?
Ooooowaa Is it just a waste of time?"

 -- Pink Floyd "The Wall"

[Fxruby-users] Message Identifiers, Types, etc again.

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

Just when I thought I was no longer confused about this:

On Thu, 12 Jun 2003, Hugh Sasse Staff Elec Eng wrote:

> OK, reading this in conjunction with paragraphs 3 and 4 of
>
> http://www.fox-toolkit.org/messages.html
>
> it seems that message_id is actually the sender of the message, and
> message type is actually the message itself (not counting associated
> data).  I would have called the message itself the message_id,

Well, it is not as simple as that.  The FXRuby API docs for
FXShutter, FXShutterItem, FXScrollbar and FXList at least refer to
Message Identifiers which are constants, and are not names of the
originating objects.  So should these be called Message Types for
consitency with other FOX docs, or what?

        Hugh

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

On Thu, 12 Jun 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > My workaround for this is to build in /scratch, but if this problem
>
> Attached is a modified version of the install.rb script which does not
> attempt to create the InstalledFiles file.

Thanks.  If you like me to test this I can but I have successfully
installed using the (local) /scratch partition for the build.

        Hugh
>

Re: [Fxruby-users] OO documentation issues.

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

On Thu, 12 Jun 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > Things that have puzzled me about this target message sytem include:
> >    the target is fixed at construction time.
>
> No. The target is initialized at construction time, but it is not
> "fixed". You can change it at any time using the setTarget() method, or
> by "re-connecting" the widget to some other proc, or whatever. It is
> (can be) very dynamic if that makes sense for your application.

Oh, I see, thanks.
>
> >    The messages have types and ids.
        [...]
> I'm not sure I follow, so I'll just give you my summary of how message
        [...]
>
> First, the boring part.
>
> Message types are used to distinguish between the different kinds of
> messages that a widget can *send*. If we consider the FXButton widget as
        [...]
> we see that it can send one of five different message types
> (SEL_KEYPRESS, SEL_KEYRELEASE, SEL_LEFTBUTTONPRESS,
> SEL_LEFTBUTTONRELEASE or SEL_COMMAND) to its target object.
>
> Of course, the button's target may getting messages from *other* widgets
> as well. So it needs some way to distinguish between SEL_KEYPRESS
> messages coming from, say, button #1, and SEL_KEYPRESS messages coming
> from button #2. And that's where the message identifier comes in.

OK, reading this in conjunction with paragraphs 3 and 4 of

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

it seems that message_id is actually the sender of the message, and
message type is actually the message itself (not counting associated
data).  I would have called the message itself the message_id,
divided gruops of ids into types, and called the sender "sender" or
"sender_id"! No wonder I was confused. Message_id doesn't identify
the message, only the sender (well, it's useless without an
acompanying message, but still)!)

>
> Message identifiers are most often used to distinguish between different
> senders of the same type of message. Since the message identifiers are
> used by the receiver of the message (i.e. the target), they just need to
> be unique for that class of objects and do not need to be globally unique.

OK, that's clearer now. Thank you.
>
> Now, the less boring part.
>
> For many FXRuby applications, you don't need to get *too* hung up on the
> details of how FOX's message-target system works under the hood. As
> discussed in detail here:
>
>      http://www.fxruby.org/doc/events.html
>
> A lot of the ugly details have been hidden for the most common
> applications in FXRuby.

Yes, I like that elegance.
>
> > I suppose there is
> > an analogy here with the Ruby send() method, except that one must
        [...]
> Yes, and this is largely due to some fundamental differences between C++
> and Ruby. The C++ language doesn't have any way to "send" a message to
        [...]
> system. It is no secret that he would have preferred to have written FOX
> in Objective-C, where this kind of messaging would have been more
> natural, but for pragmatic reasons he went with C++ ;)

:-)  For pragmatic reasons I gave up on C++ and went with Ruby for
most of my work! :-)
>
>
        Thank you
        Hugh

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

Hugh Sasse Staff Elec Eng wrote:

> My workaround for this is to build in /scratch, but if this problem
> can be avoided by doing all changes to the build directory before
> the install stage, it would help.

Attached is a modified version of the install.rb script which does not 
attempt to create the InstalledFiles file.

Re: [Fxruby-users] OO documentation issues.

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

Hugh Sasse Staff Elec Eng wrote:

> Things that have puzzled me about this target message sytem include:
>    the target is fixed at construction time.

No. The target is initialized at construction time, but it is not 
"fixed". You can change it at any time using the setTarget() method, or 
by "re-connecting" the widget to some other proc, or whatever. It is 
(can be) very dynamic if that makes sense for your application.

>    The messages have types and ids.
>       Is this how global scope of message ids is avoided, so that
>       Multiple Inheritance (C++) or Mixin (Ruby) is achievable? Only
>       the case of direct ancestry makes it necessary to adjust
>       LAST_ID, then?
> and that selector seems to be used for message.

I'm not sure I follow, so I'll just give you my summary of how message 
types and identifiers are used in the C++ library. But before you get 
too bogged down in that discussion, let me note that in many cases, this 
mess is easier to work with in FXRuby applications due to some magic I 
added awhile back (i.e. the #connect method).

First, the boring part.

Message types are used to distinguish between the different kinds of 
messages that a widget can *send*. If we consider the FXButton widget as 
an example:

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

we see that it can send one of five different message types 
(SEL_KEYPRESS, SEL_KEYRELEASE, SEL_LEFTBUTTONPRESS, 
SEL_LEFTBUTTONRELEASE or SEL_COMMAND) to its target object.

Of course, the button's target may getting messages from *other* widgets 
as well. So it needs some way to distinguish between SEL_KEYPRESS 
messages coming from, say, button #1, and SEL_KEYPRESS messages coming 
from button #2. And that's where the message identifier comes in.

Message identifiers are most often used to distinguish between different 
senders of the same type of message. Since the message identifiers are 
used by the receiver of the message (i.e. the target), they just need to 
be unique for that class of objects and do not need to be globally unique.

Now, the less boring part.

For many FXRuby applications, you don't need to get *too* hung up on the 
details of how FOX's message-target system works under the hood. As 
discussed in detail here:

     http://www.fxruby.org/doc/events.html

A lot of the ugly details have been hidden for the most common 
applications in FXRuby.

> I suppose there is
> an analogy here with the Ruby send() method, except that one must
> setup the mapping between the message and the recipient's method in
> FOX, whereas this is mapping is implicit in the Ruby send command.

Yes, and this is largely due to some fundamental differences between C++ 
and Ruby. The C++ language doesn't have any way to "send" a message to 
an object other than explicitly calling one of its member functions, 
i.e. this binding must occur at compile time. So Jeroen had to invent 
this somewhat elaborate scaffolding to pull off FOX's message-target 
system. It is no secret that he would have preferred to have written FOX 
in Objective-C, where this kind of messaging would have been more 
natural, but for pragmatic reasons he went with C++ ;)

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

neelix hgs 108 %> su -
Password:
        [...]
# cd /home/hgs/FXRuby-1.0.24
# ruby install.rb install
install.rb: entering install phase...
---> lib
mkdir -p /usr/local/lib/ruby/site_ruby/1.6/
---> lib/fox
mkdir -p /usr/local/lib/ruby/site_ruby/1.6/fox
install aliases.rb /usr/local/lib/ruby/site_ruby/1.6/fox
install failed
Permission denied - "/home/hgs/FXRuby-1.0.24/InstalledFiles"
Try 'ruby install.rb --help' for detailed usage.


I think it is trying to write to my home directory, which is NFS
mounted, so that root comes in as nobody, and cannot do what is
required.

My workaround for this is to build in /scratch, but if this problem
can be avoided by doing all changes to the build directory before
the install stage, it would help.

        Hugh

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

On Thu, 12 Jun 2003, Lyle Johnson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hugh Sasse Staff Elec Eng wrote:
>
> | Thank you for this.
> | Can you confirm the md5sum for the tar.gz please?
>
> Sure; they are:
        [...]
> So it looks like you're in good shape ;)
>
> Lyle

Great, thank you again.
        Hugh

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hugh Sasse Staff Elec Eng wrote:

| Thank you for this.
| Can you confirm the md5sum for the tar.gz please?

Sure; they are:

	76d60ffedb663e09aea4da3fe8b5c40f *FXRuby-1.0.24.tar.gz
	3f8e16cf89dcf84e02c79ec4739eb2d6 *FXRuby-1.0.24-ruby168.exe
	04dc339a0d89a0ef1f6aba0d90aef889 *FXRuby-1.0.24-ruby173.exe
	c86b0a565ba2003a37c5a7f3d0b2683c *FXRuby-1.0.24-ruby180.exe

So it looks like you're in good shape ;)

Lyle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+6IKpRy8FwLkdsRcRAlBkAKCalvkutAcDleW20ZlvX7uPKEejqACgs3qw
K8liBn7uzGpe38kuaQc1JmA=
=TtKJ
-----END PGP SIGNATURE-----

Re: [Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

On Wed, 11 Jun 2003, ly...@kn... wrote:

> All,
>
> FXRuby-1.0.24 is now available for download from:
>
>     http://sourceforge.net/project/showfiles.php?group_id=20243

        [...]

Thank you for this.
Can you confirm the md5sum for the tar.gz please?  I get
neelix hgs 63 %> md5sum.rb FXRuby-1.0.24.tar.gz
76d60ffedb663e09aea4da3fe8b5c40f
neelix hgs 64 %> cat ~/bin/md5sum.rb
#!/bin/sh
ruby -r md5 -e "puts MD5.new(File.open('$1', 'rb').read).hexdigest"
neelix hgs 65 %>
>
> Lyle
>
        Thank you
        Hugh
>

[Fxruby-users] [ANN] FXRuby-1.0.24 Now Available

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

All,
 
FXRuby-1.0.24 is now available for download from:
 
    http://sourceforge.net/project/showfiles.php?group_id=20243
 
This is mainly a bug-fix release; for the complete list of changes since
version 1.0.23, see:
 
    http://www.fxruby.org/doc/changes.html
 
Enjoy!
 
Lyle

Re: [Fxruby-users] OO documentation issues.

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

On Wed, 11 Jun 2003, Lyle Johnson wrote:

> Again, I of course agree. But I should make it clear that the FXRuby API
> reference documentation is just that, reference material. It is not
> intended as the first stop for someone learning how to use FOX or
> FXRuby, in the same way that you wouldn't want to try to learn how to
> speak French by reading a French-English dictionary.

This is a fair point, well put.  Separating these concerns is
probably a Good Thing: it will reduce coupling in the documentation.
>
> In an earlier post, I sort-of joked about an FXRuby "book" that would
> fill the sometimes large gap between the example programs and the
> reference documentation. A kind of "Programming FXRuby" or "The FXRuby
        [...]

Yes, I'd like to see this, hopefully before 2020! :-)
>
> Many of these "wider context" issues are covered in various articles at
> the FOX web site (http://www.fox-toolkit.org/doc.html). To a large
        [...]
> Once you've learned those fundamental concepts, you should find that
> they work the same throughout the library. For example, once you
> understand how FOX's message-target system works for events generated by
        [...]

Yes, I think this is true, I am beginning to get the picture, having
explored the Wiki as well.  I think the problem for me is that there
is a lot of inter-related terminology of special significance.

Things that have puzzled me about this target message sytem include:
   the target is fixed at construction time.
      In langauges like Smalltalk where OO is message passing, any
      object can pass messages to any other, as FOX can.  So fixing
      the target is only necessary because that is the most useful
      thing most of the time: if you press a given button you will
      always want the message to go to one place, or the
      circumstances are very exceptional.  Is that about right? It
      probably makes it easier in languages that are not as dynamic
      as Ruby as well.
   The messages have types and ids.
      Is this how global scope of message ids is avaoided, so that
      Multiple Inheritance (C++) or Mixin (Ruby) is achievable? Only
      the case of direct ancestry makes it necessary to adjust
      LAST_ID, then?
and that selector seems to be used for message.  I suppose there is
an analogy here with the Ruby send() method, except that one must
setup the mapping between the message and the recipient's method in
FOX, whereas this is mapping is implicit in the Ruby send coammend.

        Hugh

Re: [Fxruby-users] OO documentation issues.

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

Hugh Sasse Staff Elec Eng wrote:

> I have been thinking some more about the problems of documenting
> FXRuby effectively, and why it is a difficult problem.  Generally
> OO programming simplifies things in so far as when you know about a
> class of components you can generalize.  This is good.  However,
> knowing about all the classes doesn't mean you know about how to put
> them together.

Yes, I agree.

> This sort of knowledge lives outside the class descriptions, but
> within the space of the toolkit.  Looking around the fox size I see
> this problem reflected there.  There are classes that interact but
> only have descriptions about themselves, and even in the C++ source
> code comments don't reflect the wider context in which they are
> used.

Again, I of course agree. But I should make it clear that the FXRuby API 
reference documentation is just that, reference material. It is not 
intended as the first stop for someone learning how to use FOX or 
FXRuby, in the same way that you wouldn't want to try to learn how to 
speak French by reading a French-English dictionary.

In an earlier post, I sort-of joked about an FXRuby "book" that would 
fill the sometimes large gap between the example programs and the 
reference documentation. A kind of "Programming FXRuby" or "The FXRuby 
Way", that is more instructive or tutorial-driven instead of just 
presenting the cold, hard facts ;)

> OK, parent and text are clear enough.  Icon refers to bttons with an
> image on them, I take it.  What is target?  Is it to do with Data
> Targets?  What is selector?  Options, position, size and padding are
> relatively clear. Some of these things will interact: what if the
> image is bigger than the button size, or the text wider/taller than
> the button.  Instead of making this whole expression a link to the
> code would it be useful to postprocess the RDoc output so each of
> these keywords is a link to a desciption of the appropriate topic?
> What happens if the parent won't support the creation of a button?
> These sort of questions apply more widely than this case, and I
> don't know where the information should be held so it can be found.

Many of these "wider context" issues are covered in various articles at 
the FOX web site (http://www.fox-toolkit.org/doc.html). To a large 
degree, those articles are language-independent, even if the code 
examples Jereon uses happen to be written in C++. For example, I'm 
pretty sure that all of the material in the chapter on FOX's layout 
managers (http://www.fox-toolkit.org/layout.html) can be applied to 
directly to FXRuby without any mental gymnastics of trying to convert 
from C++ concepts to Ruby concepts.

Once you've learned those fundamental concepts, you should find that 
they work the same throughout the library. For example, once you 
understand how FOX's message-target system works for events generated by 
FXButton (perhaps after reading 
http://www.fox-toolkit.org/messages.html), you'll find that that 
knowledge transfers pretty seamlessly to new widgets. For example, you 
could look at the reference docs for FXSpinner 
(http://www.fxruby.org/doc/api/classes/Fox/FXSpinner.html), scan the 
list of events it sends to its target, and set up handler(s) for those 
messages.

Hope this helps,

Lyle

[Fxruby-users] Focus on ComboBox?

[Laurent J. <Lau...@xr...>]

I have a problem with a dialog box that I run in modal mode (a 
find/replace kind of dialog box). There are several widgets in this 
dialog box and one of them is an editable combobox. For some reason, I 
can't set the mouse focus on the text field of the combo box. Using 
#setFocus on the combobox item has no effect

Does any body know how to do that?

Side question: ideally what I'd like to do is that in addition of 
placing the focus in the text field of the combobox, I'd like to 
select the text already available in it so that when the user type a 
new word it automatically erases the existing one. Right now the user 
has to double-click to do that.

Any hint is welcome

Laurent

Re: [Fxruby-users] OO documentation issues.

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

On Wed, 11 Jun 2003, Hugh Sasse Staff Elec Eng wrote:

> OK, parent and text are clear enough.  Icon refers to bttons with an
> image on them, I take it.  What is target?  Is it to do with Data

I think I've found this now: target is where the messages will go
from this object...

> Targets?  What is selector?  Options, position, size and padding are

...and selector is the main message that will be sent, like
SEL_COMMAND

        Hugh

[Fxruby-users] OO documentation issues.

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

I have been thinking some more about the problems of doucmenting
FXRuby effectively, and why it is a difficult problem.  Gnererally
OO programming simplifies things in so far as when you know about a
calss of components you can generalize.  This is good.  However,
knowing about all the classes doesn't mean you know about how to put
them together.  For example, one can learn about transistors,
understand their characteristics (current as a function of voltage),
and one may know about resistors, Ohm's law and power dissipation.
This doesn't give enough information to design a transistor
amplifier with correct biasing of the transistor, and desired gain
and input and output impedance.  For this some extensive knowledge
of how the components interact is necessary.

This sort of knowledge lives outside the class descriptions, but
within the space of the toolkit.  Looking around the fox size I see
this problem reflected there.  There are calsses that interact but
only have descriptions about themselves, and even in the C++ source
code comments don't reflect the wider context in which they are
used.  Would a more relevant example help?

Take FXButton.
<quote>
new(parent, text, icon=nil, target=nil, selector=0,
opts=BUTTON_NORMAL, x=0, y=0, width=0, height=0,
padLeft=DEFAULT_PAD, padRight=DEFAULT_PAD, padTop=DEFAULT_PAD,
padBottom=DEFAULT_PAD) {|theButton| ...}

Construct button with specified text and icon.
</quote>

OK, parent and text are clear enough.  Icon refers to bttons with an
image on them, I take it.  What is target?  Is it to do with Data
Targets?  What is selector?  Options, position, size and padding are
relatively clear. Some of these things will interact: what if the
image is bigger than the button size, or the text wider/taller than
the button.  Instead of making this whole expression a link to the
code would it be useful to postprocess the RDoc output so each of
these keywords is a link to a desciption of the appropriate topic?
What happens if the parent won't support the creation of a button?
These sort of questions apply more widely than this case, and I
don't know where the information should be held so it can be found.

Considering further the context in which these widgets are used,
would it be useful to have links in the docs to unit-tests for the
widget, which explain how each facility is put to use?

        Hugh

Re: [Fxruby-users] [ANN] Updated API Documentation

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

Joel VanderWerf wrote:

> [Are the online API docs] more or less the same as the downloadable api-docs file on the 
> sourceforge site?

More or less, but the "live" docs at the web site are newer and more 
complete. I'll probably post another downloadable snapshot this 
afternoon. Another option, if you have RDoc installed, is to check out 
the FXRuby source code from CVS and build the docs directly from the 
RDoc sources (as I do).