Forum

Hello,

we want to achieve a themed look for the NC area of our CDialog based dialogs. We tried using CExtNCW<CDialog> and this seems to do what we need.

We have the following problems, however:

- Many dialog boxes are contained in DLLs. , that are delivered independently from the calling .EXE files. This means, that it may happen, that a DLL is called, that we delivered in - say - 2006, by a .EXE (with Prof-UIS support), that will be delivered in 2007. The dialog boxes in these DLLs should show the themed look, too, if possible.

- in total there are more than 50 of such DLLs with several hundred dialog boxes. It would mean a huge work for us, to change all references to CDialog to CExtNCW<CDialog> in the source code of all DLLs.

- we want to enable our customers, to change the theme on the fly at runtime. This would probably mean, that we have to implement some kind of notification scheme to notify our CExtNCW<CDialog> based dialog boxes sitting in the DLLs about such change. Note, that these dialog boxes are usually non-modal and will have to be able to change their look while being opened.

Now my question:
is there a (relatively) simple approach to hook the NC-Painting of these dialog boxes by the .EXE file and to change the look of these dialog boxes by source code, that is only contained in the .EXE files?

Additional information:
all our executables are statically linked against MFC. Our DLLs are thus no MFC extension DLLs. To enable the already delivered DLLs to run with our new (Prof-UIS enabled) version of the .EXE file we cannot change this for compatibility reasons.


Any suggestions?

The CExtNCW < CDialog > windows would provide a skinned non-client area only (the client area will remain non-themed). So the only way to make your dialogs and controls on these dialogs theme-consistent, is to

1) use CExtNCW < CExtResizableDialog > windows
2) use the corresponding CExt*** classes for all the dialog controls

Of course, you will have to recompile you dlls. But please note that this is quite a task and even Microsoft cannot afford to make all the dialogs in Office applications theme-consistent and in most cases you will be able to find only default Windows dialogs in most cases. So you can make this step by step.

In the latest Prof-UIS versions, all paint managers in scope of one application can be easily synchronized. You can use this feature in your regular MFC DLLs and main application. In the main application, please invoke:

CExtPmSynchronizeSink * pAppPaintManagerContainer = &g_PaintManager;
CExtPmSynchronizeSink * pSomeDllPaintManagerContainer1 = ...; // get it using exported API 
                                                        //from some DLL which has its own g_PaintManager;
CExtPmSynchronizeSink * pSomeDllPaintManagerContainer2 = ...;
CExtPmSynchronizeSink * pSomeDllPaintManagerContainer3 = ...;
      pAppPaintManagerContainer->PmSynchronizeSink_PerformSynchronizationWith( pSomeDllPaintManagerContainer1 );
      pAppPaintManagerContainer->PmSynchronizeSink_PerformSynchronizationWith( pSomeDllPaintManagerContainer2 );
      pAppPaintManagerContainer->PmSynchronizeSink_PerformSynchronizationWith( pSomeDllPaintManagerContainer3 );

This enables all paint managers to be synchronized when you call g_PaintManager.InstallPaintManager().

Please also note that using 50 copies of MFC and Prof-UIS in all your 50 DLLs is not effective. We would recommend to switch to the MFC extension DLL-based approach in all the cases like yours. And it is not difficult. The application objects should be removed from DLLs, the DLL entry method should be added and the AfxLoadLibrary() API should be used in the main application for loading MFC extension DLLs dynamically.

Hello,

many thanks for the comprehensive response. This supports my concerns, that there is no solution, that covers also all already compiled and distributed DLLs.

> Please also note that using 50 copies of MFC and Prof-UIS in all your 50 DLLs is not effective.
If hard disk space is the only issue, then this is no actual problem. Note, that always only a few DLLs are actually installed on an end user computer. No end user actually has the need to install all DLLs. We also do not have another choice, because many already distributed DLLs were compiled with MS VS 5 and 6, while our .EXE comes compiled with MS VS 2005. Changing the new version to MFC extension DLLs would make the old DLLs incompatible. The ability to provide such extrem range of compatibility is a good reason not to use extension DLLs.


Another question: if we link our DLLs statically against Prof-UIS just to include CExtNCW < CDialog > and the needed paint manager functions, how big is the overhead in terms of file size of these DLLs?

You could avoid recompiling your old dlls using VS 2005. Why don’t you compile them using the same versions of VS with which they were initially produced? In this case, you could ask us about how you should Prof-UIS then? The answer would be to assign different names for the Prof-UIS dlls so the library for a particular version of Visual Studio can have its unique name. If such an approach is suitable for you, we can provide more details.

As for the second question, there is a FAQ How to reduce the size of the Prof-UIS dll that I use in my project? which describes how to exclude some features.

Many thanks for your offer.

This proposal is a solution from a pure technical point of view, but due to the complexity and specific characteristics of our application not workable for our customers and our support team. We have very good reasons not to go with the dynamically linked version and we will not change this just for themed dialog boxes.

Perhaps I made myself not clear enough: I didn’t want to enter into a discussion, whether and how to link our DLLs dynamically or how to use CExtNCW in the source code of our DLLs.

We are searching for a solution or workaround to make the dialog boxes hosted within our DLLs look themed without (!) touching the source code of these DLLs (e.g. perhaps by hooking certain windows messages in the .EXE file). If there is no such hook we will have to abandon the use of Prof-UIS in that particular area of our applications.

It is possible to code a subsystem which will hook any windows in your application and subclass them with the Prof-UIS controls which are in-fact should be the classes derived from CExt*** classes and implementing the PostNcDestroy() virtual method for deleting their instances when the subclassed window handles are destroyed. But we don’t think this is technically correct.

Alternatively it is possible to code a hook which will simply re-paint everything what can be re-painted. But this is enough large work and it does not change behavior of repainted windows. I.e. It does not implement such things as alpha blending animation in the Office 2007 themes and it does not display Prof-UIS context menus over controls such as edit box.

This is why we think you can switch into more modern UI in your DLL modules step by step - not at once.

Hello,

many thanks for this suggestion. For now it would be sufficient to just hook the functions related to NC-Painting of the dialog boxes. We just want to give the dialog boxes contained in our DLLs a "themed NC" look, i.e. mainly the title bar, the caption and the border of the dialog boxes shall be themed, nothing else. We decided already, that the contained controls shall remain "classic MFC" for the time being.

Is there a way to hook NC painting of these dialog box frames? And if so, how is this done? Could you draft an idea?

You need to install a thread wide CBT hook procedure that should allow you to detect the creation event for each new window in the same thread. All the popup windows which are not subclassed yet can be subclassed with CExtNCW < CWnd > windows.

Hello,

many thanks. We will try this out.