Duilib Multiple DLL usage issues for the same process

Duilib Library oneself now with quite comfortable, all the code oneself also see several times, to oneself develop UI to help quite much. Duilib a small Directui library that basically satisfies most of the development. Although there are some bugs, but do not affect the development, as long as they understand the principle of his library other easy.

In order to make the module more modular, I directly encapsulate the interface and the business in a DLL, the resources are placed in the compressed package and as a DLL resources. External only provides the interface, even if the demand changes, to modify the interface, but for the outside, the interface is not changed, they know everything, so as to reduce the coupling. But in the project development found that I started a Duilib module interface after the front interface is closed do not close after you want to start another Duilib write dll inside the interface, you will find that the root can not start, after a while debugging an assert (Proot) diagnostic error. I feel very strange, I used to use MFC this development time did not find such a problem. Feel a little unscientific. In the back of the thought of a process common to a DLL, a process of memory is the same. So the guess uses all the variables.

I later analyzed the core inside Cpaintmanagerui, there are a large number of static variables of the class, it is obvious that the corresponding Cpaintmanagerui all instances are common.

Static hinstance m_hinstance;
Static hinstance m_hresourceinstance;
Static cduistring M_pstrresourcepath;
Static cduistring M_pstrresourcezip;
static bool M_bcachedresourcezip;
Static HANDLE M_hresourcezip;
static short M_h;
static short m_s;
static short m_l;
Static Cstdptrarray m_apremessages;
Static Cstdptrarray M_aplugins;

Behind the analysis m_hinstance is problematic, each DLL has its own different m_hinstance, unless I put exe inside the public EXE resources. Obviously Duilib author does not consider the multi-DLL access problem at all, the estimation does not consider the use of duilib in the DLL, only consider the use of EXE.

My solution: I do not modify the author's original code, lazy trouble. The DLL for each module corresponds to a duilib DLL, but the name is not the same because the same process can only load one copy of the DLL.

This will load the same DLL environment for each process. Metaphor Live module: Generate Duilib_live. The recording module will be Duilib_play, anyway duilib is not big, the program size does not have much influence.

Duilib in the custom control when the visit default is False, many times do not notice will find how the window does not display it ...

MFC can be very good with duilib, in particular, can see online buddies to write the Thunder player tutorial.

MFC in the DLL notice a lot of points, one is the handle problem, each time to create a afx_manage_state (AfxGetStaticModuleState ());

and the Window object is not on the stack, must heap on, otherwise will error, oneself did not find his reason specifically, can use on the line. MFC is compatible with too many things, so do not say that MFC is bad.

Duilib Multiple DLL usage issues for the same process