The key must be propagated initially to the first chain element
before evaluating if we should stop because of the handled or
the Modal condition. Otherwise the modal dialog
won't get any process key notification.
This fixes c072e29a68
It's quite common for key events to flow up the containment hierarchy in
UI frameworks. This could simplify management of global hotkeys that can
be placed in a top-level "App" and have all views shown subsequently just
"inherit" that behavior as long as they let the key event flow.
Propagating keys upwards is typically undesirable in modal dialogs, so we
set it to true in the `Dialog` base class.
Make sure we make a copy of the items since a key handler could modify the
top-level collection (i.e. by closing a dialog in between this processing).
`indent_size` came before `tab_width` and the latter is basically a fallback for the former,
as far as I can understand https://github.com/microsoft/vscode-editorconfig/blob/master/src/editorConfigMain.ts#L248.
However, VS behaves weirdly when one is defined and not the other. It gets the tabs
completely wrong. If both have the same value, however, it works as expected. So make
it easy for contributors on VS to contribute by adding this value.
Hopefully, this will be a no-op on VSM.
When building UIs, it's quite common to separate the UI/control building code
from the interaction logic by placing it all in a single method, usually
`InitializeComponent` or similar. This also allows other tooling to generate
such a method from potentially other UI languages (XML/Json/Yaml/whatever)
at build-time.
Even if no codegen is involved, having the UI building in a single place
allows for creating base views that provide some common boilerplate that
derived views can subsequently extend by overriding the base "initialize"
method.
The tricky part is that the base class cannot provide (at least that's
against the .NET guidelines and it certainly makes for some confusing and
potentially hard to reason bugs) a *virtual* method to do so and invoke
it from the constructor, since the base class constructor is called and
finishes *before* the derived class constructor does. This means that
fields that may be required by the derived view to build its UI in its
override of the "initialize" method would not be available by the time
the base class calls it.
Which is why the best place to handle such an approach is in the library
itself, which controls the exact time when a view is about to be shown.
Since no other method is provided for "initialize once before showing
for the first time" scenario, a good trade-off is to simply enable this
mechanism as totally opt-in by allowing views to implement `ISupportInitialize`
(which provides the `BeginInit`/`EndInit` pair) or `ISupportInitializeNotification`
(which adds `IsInitialized`/`Initialized` property/event). If the former
is implemented, the Begin/End will be called on every `Run`, since the
library has no way of knowing if the view has already been initialized
before. In these cases, the views could just clear all its controls in
the `BeginInit` and reconstruct the UI entirely in `EndInit`. The
`ISupportInitializeNotification` interface allows more control for views
that require that Begin/End init are called exactly once.
* Unify projects in SDK-style and PackageReference
* Add a note on the known issue about dlls not being copied
* Bump CI to a more recent stable version of Mono
This adds support for .net472, the first version of .NET
with full support for netstandard2.0
The existing property is now considered legacy and results in a build warning:
```
##[warning]C:\Program Files\dotnet\sdk\3.0.100\Sdks\NuGet.Build.Tasks.Pack\buildCrossTargeting\NuGet.Build.Tasks.Pack.targets(198,5): Warning NU5125: The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead.
```
When invoking an action in the main loop, the token will be cancelled (see
`MainLoop.Invoke` and `WindowsDriver.Wakeup`). At this point when the
EventsPending is running we must avoid throwing by waiting using a cancelled token:
`eventReady.Wait(waitTimeout, tokenSource.Token)`
And make sure we reach the disposal of the token source. Otherwise we keep throwing
over and over and cause a severe performance problem for the running app.
In more "modern" app programming models (such as WPF/UWP/XF), the "app" is a
derived class that contains the UI building behavior and is the entry point.
Typically in the constructor of such a class, you'd build the main UI, menus,
etc. In the context of gui.cs, that would mean the `Main` method would typically
be:
```
Application.Init();
Application.Run(new App());
```
In order to make the code flow consistent with the existing behavior, the existing
`Init` implementation was moved to a private method that now receives a `Func<TopLevel>`
to create the top level view upon initialization. The existing behavior is unchanged
since the new `Init` just invokes the previous `TopLevel.Create` as before.
The new `Run<T>` allows the `Main` method to simply be:
```
Application.Run<App>();
```
NOTE: this was added since doing `Application.Run(new App());` failed in the
`Window`-derived class when trying to access the static `Colors` since those were
initialized as part of `Init` and creating the `App` class was too early, preventing
this slightly simpler model.
* added a public api function called SetTerminalResized for drivers
* bugfix: overflow exception has occurred on (Rune)c when c is an integer => casting to uint solved the problem
* Apply suggestions from code review
Co-Authored-By: Marius Ungureanu <teromario@yahoo.com>
In the elmish wrapper for the Termial.Gui I need the "right" cursor position when the "Changed" event is triggered. In the current Implementation the cursor position is set after the event is triggered, so either I have to wait some ms asynchronously before I can process the event or I change the order inside the ProcessKey Method by using a helper variable "oldCurPos" and set the cursor position before the SetText method is called.
Related to: https://github.com/DieselMeister/Terminal.Gui.Elmish/issues/2
