"Win 10 App development" UI composition Notes (i): implementation of the View framework

Before starting today's content, old Zhou Xian said a question, which I remember someone had mentioned before.

Setting the Windows.ApplicationModel.Core.CoreApplicationView.TitleBar.ExtendViewIntoTitleBar property allows you to extend the contents of the app window to the title bar. Simply put, your UI area can be enlarged and populated with the title bar, which is useful when developing custom title bars or what frosted glass effects are.

However, this extendviewintotitlebar attribute has a "eight elder brother", once you set up, the system will record it, it is difficult to revert back to the default window title bar. This is why, this problem in fact, the old weeks have already found the answer, just write blog when 睺 did not write out, if write this content alone, it seems too monotonous.

It suddenly occurred to me today, just by the way in this article.

In fact, this title bar state is saved in the registry, the path in the

hkey_current_user\software\microsoft\windows\currentversion\applicationframe\titlebar\< your App package id>

The solution is to find the key, then find your app ID under titlebar and then delete your App ID key. Note that this TitleBar subkey will not appear by default and will not be created by the system until the current user has installed a custom title bar app.

===================================================================

OK, the above content is finished, if you have a problem in customizing the title bar, you can refer to the above method, of course, that is for the UWP app, desktop applications do not need to ignore, and not affected by this.

From today onwards, the old week to the big partners to tell a lot of friends feel very complex content--ui composition. This I do not know how to translate, simply use the original word, of course you can translate to "user interface components", or "UI building", anyway weird.

This thing is very useful in development, especially when dealing with images, or doing some interface effects, is quite good, and sometimes more convenient than in WPF, of course, there is a Render method in WPF rewrite, not in the UWP. So take advantage of composition.

To draw in the UWP, either you build the UI tree directly with the XAML type, or you use D2D, but this is to be written in C + +, and it's quite complicated, especially for beginners who are unfamiliar with direct Show like the old week, which is even harder.

If you use the composition API to draw or implement the filter function, in addition to the content in the SDK, you should also use a component--win, this east to D2D did the encapsulation, use is very simple, often can be used in conjunction with composition. This is also published by Microsoft, in the project right-click on the "Reference" and then from the right-click menu to choose "Nuget Manager", then you search for Win, you see the word "UWP" you can install.

Is the UI composition complex? Actually also not necessarily, we can cobwebs, many things, do not suddenly go to very complex direction to think, also do not think too much, otherwise is learning not understand. As long as the structure is clear, the back is good to enter the state, once you enter the state, you can learn in two hours.

With regard to the structure of the UI composition, let's leave it to the next one, because we need to look at the view framework of the application first. Of course, this stuff is not available in regular apps and may be used in games or direct-related programs, but it's good to know.

Specifically, we want to implement two interfaces.

A, Iframeworkview: This is an important class of assembly interface, in the implementation of this interface, you can complete the UI assembly, you can also handle the application window and the user's various interactions, such as keyboard input, mouse or other pointing device operation. This interface provides some life-cycle related methods that we can implement to complete the application logic.

B, Iframeworkviewsource: To implement this interface, you only need to implement a method:

Iframeworkview CreateView ()

This method returns an object instance that implements the Iframeworkview interface.

Therefore, the implementation of the Iframeworkview interface is the core, and then the application view is returned through the CreateView method of the Iframeworkviewsource interface.

Below, we will complete a simple example, while the hands of learning, the effect can be increased 120 times times, believe it or not.

Create a new blank application project in vs. After the project is created, you can delete the App.xaml, MainPage.xaml, and related code files generated by the project, because we don't use them in this example.

The manifest file should be kept, not deleted.

Now, let's create a new code file and implement our own app view class.

     Public classMycustview:iframeworkview { Public voidInitialize (Coreapplicationview applicationview) {} Public voidSetWindow (CoreWindow window) {} Public voidLoad (stringentrypoint) {                    }         Public voidRun () {} Public voiduninitialize () {}}

We see several methods that are about to be implemented.

* Initialize: Called at initialization time, in this method, you can instantiate some types or resources to use.

* SetWindow: In this method can be applied to the application window processing, for example, you want to track the user's mouse pointer coordinates, you can attach here PointerMoved event processing method, such as you want to track the window size (you can dynamically redraw the interface elements), you can handle SizeChanged event.

* Load: Load Some external resources before the application begins execution, or load some file data. Note that this method receives a string parameter, which is the entry point for the type of app to invoke. In a standard XAML-based application, it is generally an app class. This value comes from the configuration of the manifest file, which can be ignored if there is no special need.

* Run: At this point, the application starts executing and the message loop is started.

* Uninitialize: This method is called at the end of the application, so you can do some cleanup work in this method.

So what is the order of the calls to these methods? Quite simply, let's write some debug code to keep track of it.

     Public classMycustview:iframeworkview { Public voidInitialize (Coreapplicationview applicationview) {Debug.WriteLine ($"--calling {nameof (Initialize)} method. "); }         Public voidSetWindow (CoreWindow window) {Debug.WriteLine ($"--calling {nameof (SetWindow)} method. "); }         Public voidLoad (stringentrypoint) {Debug.WriteLine ($"--The {nameof (Load)} method is being called. "); }         Public voidRun () {Debug.WriteLine ($"--The {nameof (Run)} method is being called. "); }         Public voidUninitialize () {Debug.WriteLine ($"--calling {nameof (Uninitialize)} method. "); }    }

Don't rush to run, now the application is not running, we also have an interface is not implemented.

     Public class Mycustviewsource:iframeworkviewsource    {        public  iframeworkview createview ()        {            returnnew Mycustview ();        }    }

When implementing the CreateView method, returns an instance of the view class that was just defined above.

OK, now the implementation of the interface has been implemented, but, unfortunately, the application will not work. And I ask you, on Windows, to execute an application, where do you first find it? Yes, the entry point, which is the Main method. UWP apps are the same, you have to have the Main method. In fact, a standard XAML-based application has the Main method, but it is generated by the development tools.

Therefore, we also write an entry point for the application, this Main method if you think the other class to write trouble, you can directly write to the Mycustviewsource class just above. However, the usual habit of the old week is to write a class alone to put the Main method, because that code looks more clear.

    class program    {        staticvoid Main (string[] args)        {            coreapplication.run (  New   Mycustviewsource ());        }    }

It's actually much like we used to write WinForm and WPF applications, and the Application.Run method is called in the Main method. Here we call the method of the Coreapplication class, and the parameter it needs is an instance of the type that implements the Iframeworkviewsource interface. That's why we have to write the Mycustviewsource class in front of us, which is used in this place.

After this exercise, you will learn the process of implementing the View framework: Implementing the Iframeworkview interface to write the core application code---> Implementing the Iframeworkviewsource interface to return to the view instance---> then the source The instance is passed to the Run method to execute (in the Main method).

Now that you can run it, you will find that the application window does not appear and then it ends. That is because when the Iframeworkview interface is implemented, no message loops are started in the Run method, so the application does not receive any messages after it is run, and it ends naturally.

Now, let's look at the contents of the Output window.

From the results, the application initializes, then sets the window parameters, loads the related resources, and then executes, and then uses the Uninitialize method to clean up when exiting .

In order for everyone to see the window, we start the message loop when the Run method executes.

     Public classMycustview:iframeworkview { CoreWindow thewindow = null;  Public voidInitialize (Coreapplicationview applicationview) {Debug.WriteLine ($"--calling {nameof (Initialize)} method. "); }         Public voidSetWindow (CoreWindow window) {Debug.WriteLine ($"--calling {nameof (SetWindow)} method. "); Thewindow = window; }         Public voidLoad (stringentrypoint) {Debug.WriteLine ($"--The {nameof (Load)} method is being called. "); }         Public voidRun () {Debug.WriteLine ($"--The {nameof (Run)} method is being called. ");        theWindow.Dispatcher.ProcessEvents (coreprocesseventsoption.processuntilquit); }         Public voidUninitialize () {Debug.WriteLine ($"--calling {nameof (Uninitialize)} method. "); }    }

The UWP app traditionally has a good tradition of WPF, and it is also the Dispatcher object that is responsible for message scheduling, so I often say that WPF can learn, and the UWP can basically be bypassed.

Now, let's run it again, we can see the window, and it will wait for you to close the window before the app exits.

A big partner would ask, how do you have a splash screen? Of course, because the window is blank, the application just starts the message loop, but no interface elements, of course, can only see the splash screen.

As for how to build UI elements, let's discuss the next one, write here today, don't write too long, learn to accumulate a little.

"Win 10 App development" UI composition Notes (i): implementation of the View framework