[Implemented] Make Event Visible to bound procedure

[Psych]

Since we cannot use WindowEvent() inside a bound procedure, it would be handy if we could get the Event number inside the procedure.

This would allow multiple events to be bound to the same procedure.

[mestnyi]

It would be nice to call Event ()

[kenmo]

+1

Would make bound event handlers much simpler!

[netmaestro]

With the way BindEvent currently works, this request doesn't appear to make sense. There are three cases:

BindGadgetEvent(): The event is always going to be #PB_Event_Gadget, never anything else.

BindEvent(): Currently you must supply a single event here, and #PB_All is not available to this parameter. So you know what it is already. Maybe even name your proc accordingly.

BindMenuEvent(): The event is always going to be #PB_Event_Menu, never anything else.

There is just no task for this request to simplify at present (unless and until BindEvent begins to accept #PB_All, then you're just in another ordinary Event Loop - what's the point?)

[Psych]

You are assuming that 1 BindEvent should only refer to one procedure handler.

What if I want 2 events to be handled in 1 procedure? The way it is currently you would have to have many procedures when 1 would do.

[netmaestro]

The Bind commands weren't designed for use like that. If you structure your event handling that way you might just as well stick with the normal event loop and leave it at that because all you're doing is moving the big Select/Case block somewhere else. Good modular code structure is splitting it up so each individual event (and there aren't that many as a rule) is handled in its own procedure. It's not even any more lines of code to use Procedure/EndProcedure because you aren't using a huge Select block anymore. Basically the request boils down to asking for an extra piece of information to make it easier for you to move your event loop to a bind procedure.

[TI-994A]

Since we cannot use WindowEvent() inside a bound procedure, it would be handy if we could get the Event number inside the procedure...

Simply assign the window event to a global variable; and read that.

Code: Select all

Global event

Procedure callback()
  Debug "Event: " + event
EndProcedure

...
...

BindEvent(..., @callback())

Repeat
  event = WaitWindowEvent()
Until event = #PB_Event_CloseWindow

[kenmo]

@TI-994A - Is that robust though? Are all relevant callbacks guaranteed to happen AFTER the variable "event" is set, and before the next call to WaitWindowEvent()? PB callback execution isn't exactly the same across platforms.


@netmaestro - Agree on Gadget and Menu binding. EventType() and EventMenu() are already available to determine what happened. I don't think Psych is asking about those.

Disagree on window binding. There are definitely cases where you don't have access to the main event loop (writing Includes or Modules) and you don't want to split event handling across multiple procedures.

One example: say you execute very similar code when your window is moved and resized, except when resized you have to do a little bit more. I would argue this is the nicest way to write it:

Code: Select all

Procedure MoveResizeCallback()
  ; common move/resize code
  If (Event() = #PB_Event_SizeWindow)
    ; extra code
  EndIf
EndProcedure

With two separate callbacks, you have some code redundancy, and now you have to manage window handling in multiple places.

Code: Select all

Procedure MoveCallback()
  ; common move/resize code
EndProcedure

Procedure ResizeCallback()
  ; common move/resize code
  ; extra code
EndProcedure

Sometimes I end up using code like this, which is OK but would be cleaner with Psych's feature request!

Code: Select all

Procedure MoveResizeCallback(Event.i)
  ; common move/resize code
  If (Event = #PB_Event_SizeWindow)
    ; extra code
  EndIf
EndProcedure

Procedure MoveCallback()
  MoveResizeCallback(#PB_Event_MoveWindow)
EndProcedure

Procedure ResizeCallback()
  MoveResizeCallback(#PB_Event_SizeWindow)
EndProcedure

[Psych]

There is just no task for this request to simplify at present (unless and until BindEvent begins to accept #PB_All, then you're just in another ordinary Event Loop - what's the point?)

As far as I am aware, BindEvent() and all its permutations, were included to avoid undesirable effects, including hanging (like the problems with scrollbar update events and the move window event). So I would respectfully disagree that we should just use the ordinary event loop.
The main reason I think this would be useful, is that it allows one common procedure to handle multiple events, thus reducing the need to have multiple routines with the same or very similar footprints (variable declares, common tasks, etc).
With the inclusion of PostEvent, it becomes very handy to process all events belonging to a particular set of custom events to one common procedure.
Of course, there will always be workarounds to achieve the same results, however since the overhead in adding this would be very small, and wouldn't break any existing code, I believe it's worth consideration.

[TI-994A]

...it allows one common procedure to handle multiple events, thus reducing the need to have multiple routines with the same or very similar footprints...

These bind functions were purpose-built to be event-centric for optimum performance. Nevertheless, it shouldn't hurt to know the triggering event.