Need Expert Opinion on design issue

[Neil]

Greetings all,

Ok, I've developed a .NET application that integrates into the Windows shell
as a namespace extension (think of Scheduled Tasks and you'll get the
general look of my app). Since I've written it in C# using the 1.1
framework, I decided to support the XP look by calling
Application.EnableVisual Styles(), however here lies the problem:

It appears that calling EnableVisualStyles() works as long as its' called
from an executable. Unfortunately, in my case, I have no starting
executable. Technically the executable is Windows Explorer (explorer.exe)
which calls into my DLL through various interfaces. To make a long story
short, calling EnableVisualStyles within my DLL eventually leads to a crash
of the Windows exlplorer interface, so I'm left with one option to get the
XP style interface, and this is where I need expert opinions:

If I include a manifest named explorer.exe.manifest and install it into the
windows directory, everthing works great. My windows inherit the XP
interface, however so does other programs that are tied to Windows
explorer, such as scheduled tasks. So my question is, should I install a
manfiest that potentially alters other programs interface just to get my app
to have the XP style interface, or should I just leave it alone? The reason
I ask this is that this is going to be a commercial application, and I want
it to look professional (i.e. when run on XP, one would expect it to have an
XP interface), but am I crossing the line by installing a file that could
have affects on other apps that are not mine?

All opinons are welcome!

Neil Axe
Exalien Software

 

[Brian P. Hammer]

Not sure about your problem and how to resolve it, (IMHO) but it's a bad
idea for your program to modify any other program unless it's designed to do
so and the user purchased it for that. I feel the same way about apps that
want to change my display size.

 

[Eric Cadwell]

You can paint the theme controls yourself. This method does not rely on
EnableVisualStyles or manifest files, but it's probably a lot more effort
than it's worth.

Look for OpenThemeData and DrawThemeBackground if you want to go that route.


HTH;
Eric Cadwell
http://www.origincontrols.com

 

[Neal Andrews]

Are you calling Application.DoEvents directly after calling
EnableVisualStyles? There are some bugs with using the EnableVisualStyles
call but calling DoEvents directly after EnableVisualStyles should in most
cases fix the problem of crashes.

Regards
Neal

 

[Jacek]

Hi All!

Actually Microsoft provides some guidlines for application desing and one of
them says not to change system files which work under Windows File
Protection system. I have not checked if explorer.exe is under protection
but due to its core role in running system I would bet on that.
To find more check Platform SDK (or MSDN):
1.
ms-help://MS.PSDK.1033/apcompat/apcompat/application_compatibility_guide.htm
2.
ms-melp://MS.PSDK.1033/apcompat/apcompat/do_not_overwrite_system_files_cover
ed_by_window_file_protection.htm

Jacek

 

[Neil]

Thanks for the replies. I've decided not touch explorer.exe, wich I'm sure
is the way MS would want it, so I've decided to go the long way around and
use the UxTheme functions to recreate all my controls. Yes, it's tedious,
but my goal is to create a utility that looks as if it was always a part of
Windows, so I think the extra effort is warranted.

 

[Neil]

Yes, I have tried that, but I think the nature of this problem lies deeper.
The problem has to do with creating two different windows within my shell
extension DLL. It seems that whichever shows itself first dictates the
state of the visual styles. The problem is that there is no way that I know
of to apply visual styles to a window that is created within
IShellView::CreateViewWindow. For my other window which is a dialog, I
simply create it like normal and then show it in an Application.Run() method
call. If I include Application.EnableVisualStyles() before this function,
my dialog is indeed XP Themed, but after I close it, and attempt to show my
IShellView window, things start to act flakey and eventually explorer
crashes. If, on the other hand, I show my IShellView window first, and then
show my dialog, the dialog appears unthemed even though I called
Application.EnableVisualStyles before the Run method.

Anyway, since this app is not your ordinary simple executable, I don't
expect much in the way of help, so I've decided to bite the bullet and
create my own custom controls that use UxTheme to directly get the XP theme
look. So far this approach seems to be working create, although it is quite
time consumeing, but after I'm done, I'll have a nice UxTheme library full
of controls I can keep using with other programs.

 

[Neil]

Yep, that's exactly the way I've decided to go. I've already got
TabControl, TabPage, GroupBox, CheckBox, Label, and TextBox done. Took a
while to figure out the best order to handle the, WM_PAINT, WM_ERASEBKGND,
and WM_NCPAINT messages, but I'm getting there!

 

[Neil]

Technically I wouldnt be "changing" a system file. I would just be adding a
file to the Windows directory that is not there. But just to be safe, I
think I'll refrain from that approach anway. It just seems rather cheap,
but it would have saved me a lot of work.