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
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.
