Persisting updated visual status, using Managed Extensions in DLLs

Continuous updating of the visual state

Using Managed Extensions in DLLs

This month is my 11 anniversary of the column and the new title: "C + + at Work" Opening ceremony. At the same time we have added a new bimonthly column: "Pure C + +", which is hosted by my partner, one of the C + + master figures--stan Lipman. Stan will be more involved in the Pure C++/cli language (he will tell you more about it), and I will continue to write articles on the day-to-day application of C + + as well as on the real-world MFC (and current Managed Extensions) Windows programming. Stan's new column depicts Microsoft C + +, which is recognized as one of the most active mainstream programming languages today, and MSDN magazine will provide more C + + content for our readers in this column.

I chose "C + + at Work" because it has two layers of meaning: the first meaning is "C + +" (c + + on-the-job), which refers to people working with C + +. Another implication for me, and more important, is "let C + + work" (putting C + + Work)--that is to say, C + + works for you. That's the point of my column, and that's not going to change. The only formal change is that there will be no "q&a" in the name, but I reserve the right to write occasionally about C + + topics and technologies that I think are important and interesting and worthwhile, not directly from the reader's questions. Besides, I'm going to keep q&a style, so anyway, just give me a question.

I read you in November 2004 with great interest in the column on how to continue the view state of the Open dialog box for different user sessions, I think there is a problem. Your Clistviewshellwnd (M_wndlistviewshell in the dialog box) will be destroyed when the user enters another folder. So when you close the dialog box, it doesn't store the current view mode, it's the view mode where the user enters another folder. How do you solve the problem?

Someone caught the pigtail, really let me very embarrassed! You're absolutely right, there was a bug in my code last November. In that article, I described how to implement a custom Open dialog box (CPERSISTOPENDLG) to keep track of the views of different user sessions. That is, if the user selects a thumbnail in the Open dialog box, the next time the program is run, the dialog box opens in thumbnail mode. I shelldll_defview a special window through subclasses, and the Open dialog box uses that window to display files and folders. I used Spy + + to discover this magical command IDs to set the view mode, and I also demonstrated the use of lvm_getitemspacing to differentiate between icon mode and thumbnail mode-both of which return from Lvm_getview/getview are lv_view_icon.

Any time you store the window state, whether it's size/position or view mode, it's natural to do this work in the Wm_destroy/ondestroy process routines before the window is destroyed. That's what I'm going to do in Clistviewshellwnd, it's an MFC class created to handle Shelldll_defview:

void CListViewShellWnd::OnDestroy() {
　　m_lastViewMode = GetViewMode(); // 记住当前视图模式
}

When the dialog box is destroyed, its object (CPERSISTOPENDLG) writes M_lastviewmode to the user profile in the constructor. That's the way it goes--it's a routine approach to doing things like that. But as John found, the Open dialog box does not destroy the shell view when the user closes it, and it is destroyed each time the user transfers to another folder. The only way to change the display of a file list is to start all over again. (Now you know why it's so slow to go into another folder after the Open dialog box). To understand the destruction of a folder view, you simply add a TRACE:

void CListViewShellWnd::OnDestroy() {
　　TRACE(_T("CListViewShellWnd::OnDestroy\n"));
　　...
}