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
Corrected the ScrollView behavior for vertical scrolling. In case of a vertical scrollbar the position of the "arrow" can not be determinated by the Bound.Width.