message passing blasphemy

[adaml2]

This mail is a feature request "foxgui-devel" and bit of theoretical one and long.

Let us assume, that there are 2 variants of 'handle'. One that uses only
recipient and one that bubbles through ancestor-chain:

#define FXIMPLEMENT(classname,baseclassname,mapping,nmappings)
  ....
  long classname::handle(FX::FXObject* sender,FX::FXSelector sel,void* ptr){ \
    const FXMapEntry* me=(const FXMapEntry*)metaClass.search(sel); \
    return me ? (this->* me->func)(sender,sel,ptr) : baseclassname::handle(sender,sel,ptr); \
    }
  long classname::handleWithoutDad(FX::FXObject* sender,FX::FXSelector sel,void* ptr){ \
    const FXMapEntry* me=(const FXMapEntry*)metaClass.search(sel); \
    return me ? (this->* me->func)(sender,sel,ptr) : 0; \
    }

The first one goes through
   FXTextField --> FXFrame --> FXWindow --> FXDraw, Id,Obj
the second tries only
   FXTextField.
-------------
Now what is wrong with this:

long FXTextField::onQueryTip(FXObject* sender,FXSelector sel,void* ptr){
  if(FXFrame::onQueryTip(sender,sel,ptr)) return 1;
  if((flags&FLAG_TIP) && !tip.empty()){
    sender->handle(this,FXSEL(SEL_COMMAND,ID_SETSTRINGVALUE),(void*)&tip);
    return 1;
    }
  return 0;
  }

There's nothing really wrong in this case,
but what if we remove 'return 1' from first code line....
Let me explain:

I think, that
  if (FXFrame::onQueryTip(sender,sel,ptr)) return 1;
    ==
  if ( this->handleWithoutDad(sender,sel,ptr)) return 1;

That means, that FXTextField::onQueryTip, starts its own descent,
because FXFrame could be doing another ancestor call...
But this function is called, with one implicit descent hidden in
'handle':
widget->handle(someone,FXSEL(SEL_QUERY_TIP,0),NULL)

What I write here is theoretical. All that is safe, if there is
immediate  ' return 1;'  or something similar in
  if(FXFrame::onQueryTip(sender,sel,ptr)) return 1;
Otherwise you can create pretty long chain of events,
which again in this case is not much of an issue
( as FXFrame doesn't implement onQueryTip and
FXWindow doesn't descent )

summary:
Its just a question whether the function uses explicit descent
in it's own code or implicit one in 'handle'.  Therefore if
1) it is uses it's own, it shouldn't be called via ->handle,
2) and if it doesn't use it's own, it must be called via handle.

Therefore handle-functions are only good for 'handle'
calling convention and shouldn't be called as standalone.

---------
You will not like what I write now.

Having setter, getter, fxsel-setter, fxsel-getter is some kind of unnecessary
( not mentioning metaclass->search() )

Message passing to only selectors, creates strict limits for eg
user editable keyboard-binding, which I would love to have.

When Lyle writes binding to ruby, he basically wraps
all that, so that ruby can use its own message passing.
This is yet another copy.

I hope for the best, which is more general message passing
directly in Fox, but programmed in such a way, that it could
be easily compatible with higher-level-languages, like python,ruby.
In other words, why program it at all.
Isn't there a possibility to reuse such system
directly from ruby/python source tree ?

ada

P.S. As I read it after myself, I know I'm not gonna get anyone to support
this, but thanks for reading.
Well in Fox, rtti type system is not general enough ( not every function
argument is FXObject ).







------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Sunday 23 August 2009, adaml2@... wrote:

>
> This mail is a feature request "foxgui-devel" and bit of theoretical one and long.
>
> Let us assume, that there are 2 variants of 'handle'. One that uses only
> recipient and one that bubbles through ancestor-chain:
>
> #define FXIMPLEMENT(classname,baseclassname,mapping,nmappings)
>   ....
>   long classname::handle(FX::FXObject* sender,FX::FXSelector sel,void* ptr){ \
>     const FXMapEntry* me=(const FXMapEntry*)metaClass.search(sel); \
>     return me ? (this->* me->func)(sender,sel,ptr) : baseclassname::handle(sender,sel,ptr); \
>     }
>   long classname::handleWithoutDad(FX::FXObject* sender,FX::FXSelector sel,void* ptr){ \
>     const FXMapEntry* me=(const FXMapEntry*)metaClass.search(sel); \
>     return me ? (this->* me->func)(sender,sel,ptr) : 0; \
>     }
>
> The first one goes through
>    FXTextField --> FXFrame --> FXWindow --> FXDraw, Id,Obj
> the second tries only
>    FXTextField.
> -------------
> Now what is wrong with this:
>
> long FXTextField::onQueryTip(FXObject* sender,FXSelector sel,void* ptr){
>   if(FXFrame::onQueryTip(sender,sel,ptr)) return 1;
>   if((flags&FLAG_TIP) && !tip.empty()){
>     sender->handle(this,FXSEL(SEL_COMMAND,ID_SETSTRINGVALUE),(void*)&tip);
>     return 1;
>     }
>   return 0;
>   }
>
> There's nothing really wrong in this case,
> but what if we remove 'return 1' from first code line....
> Let me explain:
>
> I think, that
>   if (FXFrame::onQueryTip(sender,sel,ptr)) return 1;
>     ==
>   if ( this->handleWithoutDad(sender,sel,ptr)) return 1;
>
> That means, that FXTextField::onQueryTip, starts its own descent,
> because FXFrame could be doing another ancestor call...
> But this function is called, with one implicit descent hidden in
> 'handle':
> widget->handle(someone,FXSEL(SEL_QUERY_TIP,0),NULL)
>
> What I write here is theoretical. All that is safe, if there is
> immediate  ' return 1;'  or something similar in
>   if(FXFrame::onQueryTip(sender,sel,ptr)) return 1;
> Otherwise you can create pretty long chain of events,
> which again in this case is not much of an issue
> ( as FXFrame doesn't implement onQueryTip and
> FXWindow doesn't descent )
>
> summary:
> Its just a question whether the function uses explicit descent
> in it's own code or implicit one in 'handle'.  Therefore if
> 1) it is uses it's own, it shouldn't be called via ->handle,
> 2) and if it doesn't use it's own, it must be called via handle.
>
> Therefore handle-functions are only good for 'handle'
> calling convention and shouldn't be called as standalone.
>
> ---------
> You will not like what I write now.
>
> Having setter, getter, fxsel-setter, fxsel-getter is some kind of unnecessary
> ( not mentioning metaclass->search() )
>
> Message passing to only selectors, creates strict limits for eg
> user editable keyboard-binding, which I would love to have.
>
> When Lyle writes binding to ruby, he basically wraps
> all that, so that ruby can use its own message passing.
> This is yet another copy.
>
> I hope for the best, which is more general message passing
> directly in Fox, but programmed in such a way, that it could
> be easily compatible with higher-level-languages, like python,ruby.
> In other words, why program it at all.
> Isn't there a possibility to reuse such system
> directly from ruby/python source tree ?
>
> ada
>
> P.S. As I read it after myself, I know I'm not gonna get anyone to support
> this, but thanks for reading.
> Well in Fox, rtti type system is not general enough ( not every function
> argument is FXObject ).

FXTextField::onQueryTip calls its base class's (actually, FXWindow's since
none of the intermediate base classes implement onQueryTip) version, which
dispatches to the widget's target.  This allows interception of the SEL_QUERY_TIP
message in the application, thereby overriding the standard tip method, which is
to set the tip value from the tip text in the widget.  The return 1 is appropriate
in that case.

We don't have a handleWithoutDad() because we don't need one.  If you wanted to
stop the search then you can simply add:

        FXMAPTYPES(MINTYPE,MAXTYPE,FXWindow::onDefault)

to the end of your message map.  This will map every type of selector to onDefault,
which is a function that returns 0.

Note, we don't [usually] need self-messages, unless there's a change that subclasses
should intercep them.  This is because base classes are fixed at the time you're
writing the code  [in contrast, how widgets are connected to each other is a run-time
issue and thus we do need the message handling mechanism there].

Things like:

        sender->handle(this,FXSEL(SEL_COMMAND,ID_SETSTRINGVALUE),...);

and:

        sender->handle(this,FXSEL(SEL_COMMAND,ID_GETSTRINGVALUE),...);

ARE necessary.  This is because we don't know the specific type of "sender" (other
that the fact that it is derived from FXObject).

This mechanism is exploited in FXDataTarget, where it allows variables to be connected
bi-directionaly with widgets via the datatarget intermediary.

In this case, FXToolTip doesn't know what kind of widget is contained in the "helpsource"
variable, and conversely, the widget whose onQueryTip message is invoked doesn't know
if its FXToolTip or some other custom widget that invoked it.  

So the handle() mechanism is appropriate here.


                - Jeroen


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users