fxruby users - Oct 2006 - Data Targets and message handlers [was: Defaultdouble-click in FXTable?]

fxruby-users-bounces at rubyforge.org wrote:
> On Oct 10, 2006, at 11:17 AM, Philippe Lang wrote:
> 
>> I''m convinced it is not the problem: under FXRuby, message
handling
>> has been implemented using "PseudoTargets", in order to
simplify the
>> way you write message handlers. Connecting a handler to a widget
>> changes its target (the new target is the pseudo target!).
>> So if you previously set the target of widget to an FXDataTarget, the
>> link gets lost after you connect the handler.
>> 
>> This makes FXDataTarget objects pretty useless under FXRuby...
> 
> Unless I''m misunderstanding what it is that you''re trying
to
> do, this has nothing to do with FXRuby. A FOX widget (such a
> FXTextField) can only have a single message target. That
> target object can be an FXDataTarget, or it can be some other
> object that responds to messages, but there can only be one.
> You can''t (directly) connect an FXTextField to, say, both an
> FXDataTarget and some other object that handles SEL_KEYPRESS
> and SEL_KEYRELEASE messages sent from the FXTextField.
Hi,

Unless I''M misunderstanding something (probably!), I see things this
way:

1) An object, let''s say an FXTextField, can have a target, for example
an FXDataTarget. This is fine. Something happens in the widget, and the target
is called.

2) This same FXTextField should also be able to process messages in the same
time, when it is the target of another object. The solution is to use the
"connect" method, and add the handler to the object.

Unfortunately, under FXRuby, both options are not possible in the same time:
connect changes the target of the FXTextField, and sets it to a new object,
called "PseudoTarget". This is a pure FXRuby thing, as far as I know.

So I was wondering if we could not get rid of this Pseudo Target, so an object
can independently HAVE a target, and BE a target (process messages). This is
possible under Fox C++, right?


---------------
Philippe Lang
Attik System

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3125 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/fxruby-users/attachments/20061012/d2615618/attachment.bin

On Oct 12, 2006, at 1:07 AM, Philippe Lang wrote:
> Unless I''M misunderstanding something (probably!), I see things  
> this way:
>
> 1) An object, let''s say an FXTextField, can have a target, for  
> example an FXDataTarget. This is fine. Something happens in the  
> widget, and the target is called.
Correct.
> 2) This same FXTextField should also be able to process messages in  
> the same time, when it is the target of another object. The  
> solution is to use the "connect" method, and add the handler to
the
> object.
No, this is not correct. Calling connect() on an FXTextField doesn''t  
make it the target of some other object. Calling connect() on an  
FXTextField, like this:

	textfield.connect(SEL_KEYPRESS) do |sender, sel, data|
		# ... handle key press event ...
	end

  is *roughly* equivalent to this:

	class FXPseudoTarget < FXObject
		def initialize
			FXMAPFUNC(SEL_KEYPRESS, 0, :onKeyPress)
		end
		def onKeyPress(sender, sel, data)
			# ... handle key press event ...
		end
	end

	textfield.target = FXPseudoTarget.new
	textfield.selector = 0

In other words, the result of calling connect() on the FXTextField is  
to assign a new target to it (thus replacing the text field''s  
previous target). Subsequent calls to connect() for the same text  
field will just add new message handlers to the existing FXPseudoTarget.
> Unfortunately, under FXRuby, both options are not possible in the  
> same time: connect changes the target of the FXTextField, and sets  
> it to a new object, called "PseudoTarget". This is a pure FXRuby
> thing, as far as I know.
>
> So I was wondering if we could not get rid of this Pseudo Target,  
> so an object can independently HAVE a target, and BE a target  
> (process messages). This is possible under Fox C++, right?
Per the previous discussion, there''s nothing in FOX (or FXRuby) that  
prevents an object from both being a target and having a target. But  
I think I understand what you''re getting at, and that is that you  
want to have the text field''s content tied to some variable in your  
application, but you''d also like to be able to catch certain messages  
(like SEL_KEYPRESS and SEL_KEYRELEASE) generated by the text field.  
Is that right?

If that''s the case, I don''t think you''ll be able to
use FXDataTarget
directly, but that''s not a big tragedy. You would instead do  
something like this:

	textfield.connect(SEL_UPDATE) {
		# Update the text field''s content from a variable
		textfield.text = my_variable
	}
	textfield.connect(SEL_COMMAND) {
		# Update the variable based on new text field content
		my_variable = textfield.text
	}
	textfield.connect(SEL_KEYPRESS) {
		# ... handle key press event ...
	}

Hope this helps,

Lyle

Lyle Johnson wrote:
> But I think I understand what you''re getting
> at, and that is that you want to have the text field''s
> content tied to some variable in your application, but you''d
> also like to be able to catch certain messages (like
> SEL_KEYPRESS and SEL_KEYRELEASE) generated by the text field. Is that
> right? 
Why didn''t I say like this before! Yes, exactly.
> If that''s the case, I don''t think you''ll be able
to use
> FXDataTarget directly, but that''s not a big tragedy.
No, that''s not a big tragedy at all. I noticed that in my application,
I actually don''t absolutely need data objects, so I simply dropped
them. But IMHO, there might be something to improve in the framework regarding
messages. Fox Tails is apprently just doing that.

Thanks for your notes, and for FXRuby by the way...

Bye

---------------
Philippe Lang
Attik System

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3125 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/fxruby-users/attachments/20061013/585ca6ba/attachment.bin