Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor MouseEvent and MouseEventEventArgs to simplify #3029

Open
5 of 11 tasks
tig opened this issue Dec 4, 2023 · 2 comments
Open
5 of 11 tasks

Refactor MouseEvent and MouseEventEventArgs to simplify #3029

tig opened this issue Dec 4, 2023 · 2 comments
Labels
v2 For discussions, issues, etc... relavant for v2
Milestone

Comments

@tig
Copy link
Collaborator

tig commented Dec 4, 2023

Similar in spirit, but somewhat less scope, than #2927

  • New/OnMouseEvent now uses just MouseEvent.
  • New/OnMouseClicked now uses just MouseEvent.
  • Beef-up/refactor mouse unit tests
  • Merge MouseEvent and MouseEventEventArgs into a single class.
  • Better document/rename OfX/OfY
  • Move mouse stuff out of Responder and into View so Responder can be nuked
  • Engineer something that removes the need for Responder.IsOverridden which breaks all rules of OO design.
  • Ensure all library code uses consistent naming/usage
  • Ensure all Scenario code uses best practices related to new design.
  • Ensure all API documentation is awesome
  • Add a docs/mouse.md
@tig tig added the v2 For discussions, issues, etc... relavant for v2 label Dec 4, 2023
tig added a commit to tig/Terminal.Gui that referenced this issue Apr 4, 2024
- Started MouseEventEventArgs -> MouseEvent transition - for OnMouseEvent. Partially fixes gui-cs#3029.
- Refactored Appliation.OnMouseEvent and View.OnMouseEvent to match design guidelines.
- Re-impleented highlight, enabling extensibility (see Border).
- Beefed up unit tests
@tig
Copy link
Collaborator Author

tig commented Apr 4, 2024

Partially fixed in #3372.

@dodexahedron
Copy link
Collaborator

dodexahedron commented May 8, 2024

BTW:

For adherence to the dotnet design guidelines for events, all EventArgs classes should end in "EventArgs" and should not be mixed use classes outside of events themselves (Key, for example, is used both ways - I have a stashed change somewhere that's probably way obsolete by now that fixed that).

Inheriting from EventArgs also used to be recommended, but is now just a soft suggestion.

Here's one of the best of the various documents about guidelines for events:

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/events/how-to-publish-events-that-conform-to-net-framework-guidelines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2 For discussions, issues, etc... relavant for v2
Projects
Status: 📋 Approved - Need Owner
Status: 📋 Approved - Need Owner
Development

No branches or pull requests

2 participants