The treeview is rendered as a table, so there is no easy way to get a count of nodes - the nodes are actually table rows and cells. You could apply a css class or other attribute to the nodes in the code behind when you are creating your treeview - then use javascript to count the number of elements with that class - very simple if you use JQuery. Are you adding or removing nodes dynamically with javascript? If not then you could just count them as they are added server-side and embed them in your javascript when the page is rendered. This[^] post will show you how to embed asp.net variable. Hope that helps.

Something is adding that <script> block to your page, so asp.net then throws an error because there is something outside an <asp:Content> block - which is not allowed. The first thing I would do is check IIS to make sure that there is nothing set to automatically include the block.</x-turndown>

You can't GROUP BY a field of type text. You could cast Category to a varchar, but that would not perform well. Are you sure that the type text is the most appropriate for your data? A varchar might be much better and your GROUP BY would then work.

I think the problem is that the People objects that you are trying to send are defined on the client side. The service is expecting the People objects that are defined on the service side - they are not the same thing. Try sending a list of ServiceReference1.People instead of SilverlightApplication1.People and see if you get the same error.

Once the user is authenticated you can use Roles.IsUserInRole("Role") to find out if they are in a role and GetRolesForUserto find out what roles they are in. This[^] page may help.

Hi, I had the same error recently and was helped out by this[^] blog post.

If ImgRow1 is a property like:

public List<Image> ImgRow1 { get; set; }

and is in scope in the event handler, then you can modify the event handler like this:

private void item_MouseDown(object sender, MouseButtonEventArgs e)
{
Image myImage = (Image)sender;
int index = ImgRow1.IndexOf(myImage);

        MessageBox.Show(index.ToString());
    }

Or, You could create your own "IndexedImage" class with a ListIndex property, inheriting from Image and use that.

public class IndexedImage : Image
{
public int ListIndex { get; set; }

    public IndexedImage()
    {
    }
}

When you add the event handler, add the list index as well:

foreach (IndexedImage item in ImgRow1)
{
item.MouseDown +=new MouseButtonEventHandler(item_MouseDown);
item.ListIndex = ImgRow1.IndexOf(item);
}

Then in the event handler you can get the ListIndex property:

private void item_MouseDown(object sender, MouseButtonEventArgs e)
{
IndexedImage myImage = (IndexedImage)sender;
MessageBox.Show(myImage.ListIndex.ToString());
}

but that has other issues, in that the index may change later on, so the class would need to be more complicated in reality.

modified on Sunday, October 11, 2009 4:51 PM

This[^] blog post will show you how to implement a version of DoEvents(), that should help.

I don't think the datagrid does any transposing at the moment. This[^] blog post shows a way of transposing your data instead. Hope that helps.

One way is to use the WebRequest object to retrieve the page and then parse it for the information you want. This article[^] may help.

You might want to have a look at the dataSet.ReadXml() method. http://msdn.microsoft.com/en-us/library/system.data.dataset.readxml(VS.71).aspx[^] Hope that helps.

Soulforged wrote:

SSL to non-secured service calls would be denied

That's the basis of the problem. By having the clientaccesspolicy.xml with https and http included you are allowing calls from a Silverlight app in http to services in https and vice versa. It is my understanding that the browser is ignorant of what Silverlight is doing in the background so the padlock can be misleading. You could run the app in https with a nice padlock and then call services over http and the padlock will stay there. Unless you remove/alter the clientaccesspolicy.xml and stick to either all http or all https. I'll let you know if I find out any more info. Cheers

I know what you mean. I have just been talking to my colleague about the same thing. The funny thing is that once the xap has been downloaded (via https for example) and is running, whatever the browser says is irrelevant, you can still go ahead and be as un-secure as you like in the background with your service calls (assuming you have the clientaccesspolicy.xml in place). That's my understanding anyway - I would like to be proved wrong though. Cheers.

This is a nice example of how to do that. http://go.microsoft.com/fwlink/?LinkId=150553[^]

Are you sure that need the padlock to show up? From what you have said, you have secured the call to the service (assuming your endpoints etc. are looking at the https services): e.g. <endpoint address="https://nigel.company.co.nz/MyService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyService" - but that is all in the background. Even though you didn't access/download the Silverlight xap with https it will still be communicating directly with the services over https if they are configured that way.

Hi Jeremy, One way could be to have a property in the ViewModel like this:

private int _selectedIndex = -1;
public int SelectedIndex
{
get { return _selectedIndex; }
set
{
if (value != _selectedIndex)
{
_selectedIndex = value;
NotifyPropertyChanged("SelectedIndex");
}
}
}

It's set to -1 initially so the XAML doesn't throw an error when there's no collection to bind to. Bind it to the list box:

<ListBox ItemsSource="{Binding Employees}" SelectedIndex="{Binding SelectedIndex}" />

Then, in the completed event (when the service returns from the asynchronous call with the data) you can set it to whatever you want.

void svcClient_GetDataCompleted(object sender, EmployeeSvc.GetDataCompletedEventArgs e)
{
Employees = e.Result;
SelectedIndex = 1;
}

Not particularly elegant, but it seems to work. Cheers.

Hi there, I was getting the same message with an SSL enabled service recently. It turned out that the name on the certificate in IIS was slightly different than what I had in the WCF binding (I was missing a "companyname.co.nz" on my binding). It didn't really matter without SSL because it was all running locally so the machine-name (without the "companyname.co.nz") was enough. Something for you to double check anyway. Cheers.