Fixes #3675. Adds ObjectDisposedExceptions

[tig]

Fixes

• Fixes Need more cases of ObjectDisposedException  #3675

Proposed Changes/Todos

• Backed out bogus Title check per @dodexahedron
• Applicaiton.Mouse - Found bug in ContextMenu
• Adornments - Would have helped ID Null reference in v2 in FindDeepestView #3667
• ApplictionNavigation
• Application.Run

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[dodexahedron]

Just cross-posting a reference to commentary I put in #3675 for the work being done for this.

[tig]

Note while this is ready for review (and is probably enough for now), tests fail due to #3678

[dodexahedron]

Oh wow that Title bug came back?

Pretty sure that's a regression, unless I never made a PR for the branch I fixed it in. 🤔

[dodexahedron]

I'll review this in a bit.

I'm actually considering maybe making at least part of #3677 a PR to your branch for this, since they're conceptually pretty related, for the IDisposable portion, and would be wise to be vetted as a whole before this PR gets merged. Might save a small amount of work and potential wild goose chases.

Then I'll just rebase the other parts of that issue on top of that.

Sound good?

[dodexahedron]

Thar ye goeth: tig#39

[dodexahedron]

Coolio.

I'll take a look at it in a minute. Just gotta stash what I'm working on at the moment.

[dodexahedron]

Whoops. Got an idea and got distracted on it. NOW I'm taking a look. 😅

[dodexahedron]

I have some items to run by you on this one. Some are pretty important.

I'm writing it up and validating specifics. I'll have a small amount of code plus commentary that I'll include with it, as a PR to your branch again.

[dodexahedron]

In addition to the stuff I'm preparing, my other main general commentary is that, until that test issue is fixed, I wouldn't advise merging this yet, since this change isn't isolated to a specific single unit that is still passing, while also not being coupled in any way to other units under test.

That recommendation isn't limited to this PR. It applies to any which can't be deterministically proven to be fully isolated from all failing tests.

However, this change set in particular involves code paths that involve the entire lifetime of the library, so I'm not comfortable putting my stamp on it if it won't pass Release mode tests.

Can we temporarily back out whatever caused the failures in the mainline v2_develop branch until a fix is ready, and just have that work and any that is dependent on it continue on a parallel branch until it's all ready for merge, so other stuff isn't a big question mark and being potentially either missed til later or lumped in with unrelated breaking changes? 🫤

I have a sneaking suspicion that the need for a lot of this extra exception throwing/debugging is related to some other more fundamental issues and is going after the symptom, rather than the problem.

ODE should be thrown in pretty specific situations, from the object that was disposed, specifically.

An ODE being thrown is pretty much always a bug when you're the one receiving it, and also the vast majority of the time when you are the one throwing it, unless it's being thrown in that narrow set of specific circumstances.

The remarks in the .net docs for ODE do at least a decent job of trying to explain when it might be thrown and by whom. I know there's a more detailed doc (or there was) somewhere else on MS Learn but I'm getting errors accessing the site, at the moment so I don't have a quick link handy for ya right now. Ugh. Sorry. :(

[dodexahedron]

The way the commented line was before is preferred, since it's a constant and also more trim-friendly for consumer custom View-derived types.

[dodexahedron]

typeof was better

[dodexahedron]

If you would like the consumer to benefit from better specificity of the most-derived type, rather than always calling it just a View, you can just make that method generic:

public static void GrabMouse<T> (T? view) where T : View

and then the only change necessary should likely be that the typeof uses turn into typeof(T) instead of typeof(View). There could be other small tweaks needed in the method, and in callers, if they're making comparisons to specific types without calling that method with something more specific than a View, but they'd likely be pretty trivial to adapt, as well, if any exist.