This is the deal...

I have a _one_ web site where one piece of the site (VD1 = virtual directory 1) is secured using SSL and another piece isn't (VD2 = virtual directory 2).

VD1 is using the IE Treeview Web control.

Unless I make virtual directories, I would have to apply the SSL cert to the entire site, which is BAD in my case. With the virtual directory set up, I can apply the SSL cert VD1 and everything is dandy. Users can come in, view the general, unsecured VD2 site as they please, and if they wanna login, the get redirected to VD1 where the SSL connection is initiated.

A bit more on the set up:

My wwwroot is located in C:\Inetpub\wwwroot. (Whoa! that's crazy!)

VD1 is located in a sub-directory of root, here: C:\Inetpub\wwwroot\VD1
VD2 is located in a sub-directory of root, here: C:\Inetpub\wwwroot\VD2

Now the IE Treeview HTML web controls are installed by default in the web site root, in my case here: C:\Inetpub\wwwroot\webctrl_client. We'll call this location WC.

Now herein lies the problem...

The SSL'd web application running in VD1 uses the IE Treeview HTML Control which is installed in a directory _not_ in a subfolder of VD1, for example, not in a directory like C:\Inetpub\wwwroot\VD1\webctrl_client. Remember, VD1 is using the IE Treeview control. The SSL cert successfully encrypts everything within VD1, but since the Treeview control is installed in WC, I get the following message popping up no less than two times every time somebody logs in to VD1:

"This page contains both secure and nonsecure items. Do you want to display the items?"

This message occurs because the app in VD1 is accessing files in WC which do not have the SSL cert applied them.

My question is: How can I can change the default install of the IE Treeview control so that they will be installed into a sub-directory of wwwroot, namely wwwroot\VD1 and _not_ wwwroot\?

With this done, SSL will be applied to all files in the VD1 web app, thus, eliminating the need to retrieve the treeview files located in WC in an unsecured manner, thus getting rid of those annoying popups!

Thanks in advance,
Emory Al-Imam

Sorry I can't help as I'm having the same problem as you are.

On my page, however, I'm getting inconsistent results with the tree view. The images
that I have on the leaf nodes will not load sometime and my post back events that
respond to node clicks will sometimes not work.

With the exception of the annoying message box, is your tree view functioning
properly?

Hey There tfewster,
Make sure "Smart Navigation" is not activated when using the TreeView control. Although in theory it seems that the TreeView control was made for use with Smart Nav, in practice its been my experience that the whole application just either just flat out crashes upon refresh or there will just be a general "weirdness" to the whole app. In any case, try disabling it if it is activated and see what happens. Good luck!

Emory

Have you tried simply copying over the entire \webctrl_client\ directory structure into the root of your web page for VD1?

(without using the install program)

Dawn

Hi Dawn,
I can definitely move the files into VD1, but there's no configuration file for the TreeView control that lets me specify where the new location is. That's exactly my problem. The 'webctrl_client' directory must be located in the root directory of a web site. Try moving it anywhere else and it breaks. Go ahead, I dare ya. :) Anyways, it isn't so much of an issue anymore, but if someone does figure it out, a two-line follow-up on this post would be great for some closure.

See yas,
Emory

Hi,

Thought I'd pitch in here. I've not tested this as I don't have time but I reckon it would work :)

Now, I'm guessing everybody downloads and gets all the source code and has to build the controls to start off with, I did anyway :)

Well in the src directory there is a BaseRichControl.cs file. In here you will find the following line...
private const string DefaultCommonFilesRoot = "/webctrl_client/";

At a wild guess if you were to change that constant to say,
private const string DefaultCommonFilesRoot = "/VD1/";

Rebuild the dll and make sure your project is referencing this and not an old one somewhere else.

I'd love to know if anybody actually tests this and it works. I don't see why it shouldn't as it does look like it will. If I get a spare 5 minutes I'll do it myself.

Cheers

Tartan

I tested it out and it works. Not a nice solution but workable.