Find the best solution from multiple perspectives

These days have been plagued by the problem of multi-view switching. Based on a single document/view program, each module is dynamically loaded. As follows:

Bool cmainframe: oncreateclient (lpcreatestruct lpcs, ccreatecontext * pcontext) {crect RC; getclientrect (& rc); If (! M_wndsplitter.createstatic (this, 1, 2) |! M_wndsplitter.createview (0, 0, runtime_class (ccomputermngext), csize (250, RC. Bottom), pcontext) |! M_wndsplitter.createview (0, 1, runtime_class (ccommonlistext), csize (0, 0), pcontext) return false; return true;}/** function: replace the specified split view with the input view * parameter: Row, col-specifies the row and column numbers of the view, and the Pclass-runtime class pointer * return value: void */void cmainframe:: m_replaceview (const int row, const int Col, cruntimeclass * Pclass) {values (row, col); m_wndsplitter.createview (row, Col, Pclass, csize (250, 0 ), null); m_wndsplitter.setactivepane (row, col); m_wndsplitter.recalclayout ();} // menu command: "software management" Void cmainframe: onsoftwaremng () {m_replaceview (0, 0, runtime_class (csoftwaremngext ));}

This kind of view switching method is very simple and bright, and the effect is also very good. At the same time, in order to minimize the coupling between modules, I have determined the scheme of mutual message-driven between modules:

// Send the message: sendmessage (hwnd, wm_copydata, null, (lparam) (& CPD); // receive the message data bool ccommonlistdlg: oncopydata (cwnd * pwnd, copydatastruct * pcopydatastruct ){//...}

In general, this method of sending and receiving messages does not have any problems. Because one of the keys to sending messages using the sendmessage () or postmessage () functions is to find the handle of the receiving message window. However, after a variety of efforts, I am sorry to find that after the m_replaceview () operation, the handle of the replaced view is hard to be captured (maybe, but currently I have not found a method), the message will naturally not be delivered.

At this time, I thought of using Singleton design mode to create a global message instance. Each dynamic library assigns values to the member variables in the instance, then each module responds to messages based on the variable. This seems to solve the problem, but I soon realized that it is troublesome to monitor the changes to the instance. Besides using the timer, I didn't think of a better way. However, in this case, the real-time response of messages will certainly be affected, and if the scheduled interval is set too small, it will cause a great waste of CPU resources. This solution is also not feasible.

Do we have to embed the pointer of each other in each module to achieve the goal of mutual driving? However, this will greatly improve the coupling between modules. Such code and structure are unacceptable to me. After a long time of meditation, I suddenly came up with an inspiration. A function appeared in front of me, that is, updateallviews (). In fact, this is a very important function in a document/View-based application. When a document sends a change, you can use this function to notify all views to respond, the function prototype is as follows:

void UpdateAllViews( CView* pSender, LPARAM lHint = 0L, CObject* pHint = NULL );

Obviously, the second parameter of this function can carry the content we want to pass. But I'm not sure whether the function can find the views replaced by m_replaceview. The results of the experiment are gratifying. You can use updateallviews () to find each activated View:

// Send the UPDATE message this-> getparentframe ()-> getactivedocument ()-> updateallviews (null, (lparam) & MSG); // message response void csoftwaremngext :: onupdate (cview * psender, lparam lhint, cobject * phint ){//...}

At this point, we finally found an ideal solution for message-driven inter-module deployment.