Cancellable Work Pattern: Revisit order of calling virtual function first, then invoking event

[tig]

While investigating #3714, I think I finally understand something @BDisp has been saying for a while...

The guidance for CWP, and the implementation within the library and examples today, says:

• Call the virtual function (e.g. OnMouseEvent) first.
• If not cancelled, invoke the event (e.g. MouseEvent)

When I settled on this design, I felt it was important that

a) This behavior was consistent
b) It didn't really matter much which came first.

On b) I decided that it was slightly better to do the v-function first so that code that inherited (via override) had priority over external code (which MUST use events) or inheriting code that chose to use the event. My reasoning was inheritance implies tighter coupling and thus devs would expect to have more control. In addition, the order in which events are raised is non-deterministic per the dotnet spec, so calling v-functions first would be more deterministic.

#3417 raises a real issue with this, particuarly for MouseEvent: It is not possible for code external to a View like Slider that overrides OnMouseEvent to prevent mouse events from going to the View. The same thing applies to MouseClick.

There are several ways to fix #3714:

Implement a "disable mouse events" property in View

E.g View.IgnoreMouse

Implement more granular mouse events

For each existing event (e.g. MouseEvent and MouseClick) redefine things such that there are explicit "before" and "after" events, each following the current CWP model. E.g. MouseEvent` would become (horrible naming, but makes the point):

• BeforeMouseEvent (cancellable)
• AfterMouseEvent (not-cancellable)

AfterMouseEvent would replace the current MouseEvent (and all code that overrides it would be changed to not assume cancellation semantics).

The default impl of OnMouseEvent in View would only proceed if BeforeMouseEvent was not cancelled.

Change the CWP guidance to reverse the order such that the event is raised first, then the v-function

Here, events like MouseEvent would need to be rewritten to reverse the order. At this point I don't have a full understanding of what existing code (if any) DEPENDS on the current behavior. To this end, I'm going to use the AIs to do an analysis of the entire code base, creating a report of EVERY instance where CWP-style eventing is used and what the potential impact of changing the CWP guidance would be.

Which is why I've created this PR and am assigning it to copilot...