Win32API Interface Library-Project Wheels Engineering Foundation section completed

From the last blog post for a long time, first to busy a robot project, and then the Department of Things and Examination Week review, and then to the exam week, while reviewing the gap, picked up the winter vacation time copy of the interface library, fixed off the previous bug.

BUG1 Control Display Issues

Originally copied this library when on the typesetting part of the code confused, by this tune bug, slightly clarify the layout part of the code intention. The layout of the interface is dynamic, the user constructs the layout of the entire layout with various typesetting elements of the placement namespace, and then calls the Applyplacement member of the WinForm object, and passes the layout of the previous structure to it, The function internally recursively reads the size of the structure object and its sub-objects, computes one layer at a level, and applies a typographic layout.

So apply typography

Applyplacement (Horzscale (Ten, 0.5,control (Txtregex), Control (TXTREGEX2)));

Applyplacement inside is a simple call to the ApplyTo function of the Typeset object

Inlinevoid wincontainer::applyplacement (placement::base::P ointer placement) {    Placement->applyto ( Getplacement ());}

ApplyTo function is a virtual function, according to different typesetting elements, there are different effects, the basic principle is computing space, set the current layout in the window size changes behavior, recursive application of child elements of the layout, and then set the position of the child elements.

Feature2 modified the definition of event

This library of the original event is a macro-generated, the code is not highlighted, with a variety of connection token of # #, it is very obscure, but considering this library is Vczh University period of work, then there is no c++11, can not be happy to use variable length template parameters to write an event, Choose to use a macro to replace is also a good choice, reading the code of the people facing this large macro, will certainly first exclamation the writer's Cow B bar.

This time the event was replaced with the event in VLPP, and because of the associated inclusion, I copied the smart pointer class PTR and the function object class Func as well. A comprehensive comparison of the event before the library and the event in the VLPP, the two are not much different in the organization of the code, just vlpp more clear, the EventHandler part of the independent into a func, and added a lambda and other callable object encapsulation support.

The event contains an array of func, stored, itself overloaded with operator () (Targs ... args), when the event itself is called, the callable object within the Func array is called one by one, and the variable-length parameter table Targs ... One is perfectly forwarded into the Func invocation parameter, achieving the purpose of callback.

void operator () (Targs ... args) const{for (auto&& handler:handlers) {handler (perfectforward<targs> (args )...);}}

The following is the design of the Func, Std::function compared to Func, its biggest weakness is-not to encapsulate member function pointers, it is well known that the member function pointer at the time of the call requires a corresponding object pointer exists, and function does not do this, for this reason, c+ + also provides the STD::MEM_FN function, accepts the object pointer and the member function pointer, returns a callable object, this itself is possible, the problem is that the object itself and Std::function have no association, the type name is also the spectacle of the underscore beginning, usually only auto inference with auto , if I want to combine std::function and this thing stiff, I might as well write one myself.

The func itself contains a smart pointer to a callable object that invokes the callable object in the smart pointer with an overload of operator (), and this callable object is the key thing to say:

C + + has three different callable objects--ordinary function pointers, member function pointers, and functor, these three things can be encapsulated into three callable objects, and then focus on-let them together inherit from a same base class, and this accumulation has a pure virtual operator () member, This will explain why the Func is a pointer rather than a copy of the object, because there is no way to invoke different callable objects happily using polymorphism.

With Func, with the event, this callback mechanism is aligned.

P.s. A few days ago inadvertently saw Boost::signal, this is a reinforced version of the Event-eventhandler design, can be used to group the event callback management, temporarily disable some callbacks, or bulk unbind callback, etc., after the time, finished their own map and list , try to implement this.

P.p.s. By the way, to write the boost of the bull in the absence of a variable length template exists in the era of abruptly with template parameters to heap the highest support 9 parameters of the boost::signal, it is very powerful

Feature3 merging destroy and destructors, using smart pointers instead of manual destructor resources

Here again to spit Groove Win32API three messages wm_quit, WM_CLOSE, Wm_destroy, although from the design point of view, these three messages do not conflict, but for the user, the similar event name is indeed confusing. Perhaps to take care of the ancient times C language does not support the design of long identifiers, I would like to name them as Wm_applicationquit, Wm_askwindowclose, wm_windowdestroyed will be much better, This also can be at a glance to understand the meaning of three messages-program exit, Request close window, window destroyed

The original message mechanism of this program is such that the window accepts WM_CLOSE messages, closes itself at the same time if it finds itself as the main window, then call application exits (at this point not exiting from the main window message handler), application manages all the windows and controls of the program , application calls the Destroy function on one of the windows, and then uses the delete destructor to tune them, and the destroy function destroys the resources that the object actually occupies, in a layer. When calling DestroyWindow within the destroy of the base class Wincontrol, the Wm_destroy is generated and then immediately sent to the message handler processing, when the window has not been removed from the application list. Application's message handler finds the Window object in the list, passes the Wm_destroy message to him, and the window releases all the accompanying objects including the timer, the anti-registration accelerator, and the last call to PostQuitMessage, and the program exits normally.

After the destroy is written into the destructor, the window has been removed from the application list since the call to DestroyWindow, Wm_destroy cannot find the handler, is handled by default, no postquitmessage is called, So the window has gone, the message loop is still running, the program has not yet completely exited, this time as long as the function of the delete all the functions of the last add PostQuitMessage, you can correctly end the message loop, close the program.

Let's talk about it first.

Win32API Interface Library-Project Wheels Engineering Foundation section completed