PlausiblyDamp

Does the variable resultCode contain anything useful after the web service call returns?

As a simpler example (doesn't handle minimized windows etc.) try Private Declare Function SetForegroundWindow Lib "user32" (ByVal hwnd As IntPtr) As Long Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim strPartialTitle As String = "Wind" For Each pProcess As Process In Process.GetProcesses() ' check process' main window title If pProcess.MainWindowTitle.StartsWith(strPartialTitle) Then ' it's a match Dim strMsg As String = [string].Format("{0}", pProcess.MainWindowTitle) 'MessageBox.Show(pProcess.MainWindowHandle.ToStrin g) SetForegroundWindow(pProcess.MainWindowHandle) End If Next End Sub

If you copy the file locally and try the convert does it work then?

I would tend to avoid the registry as it is often more trouble than it is worth. If you are planning on ini files then http://www.mentalis.org/soft/class.qpx?id=6 is worth a look. If this information is to be shared between multiple users and is of a read only fashion then the app.config is a perfect place to store this kind of thing. However given that you seem to be using .Net / vs 2005 the easiest method is probably the built in setting support. If you bring up the project properties and look down the list of tabs on the left of the property page there should be one called 'Settings' - go there and it is pretty self explanatory.

The TypeDescriptor.GetProperties function probably returns multiple PropertyDescriptors - not all of them are of type MyProp though. You will need to check the type of each p before casting to a MyProp variable.

Are you binding the datagridview directly to a dataset / datatable? If so you might want to look at using a dataview and binding to that, then you could set a filter on the dataview.

Without getting involved with regular expressions a simple loop is probably easiest; unless the string is very large performance is unlikely to suffer either. Out of interest what are you trying to do? There may be an alternate method that saves you the trouble...

The "is a" only works one way round, i.e. MyProp is a PropertyDescriptor but there no guarentee than a PropertyDescriptor is a MyProp. In other words you can always safetly assign a MyProp object to a variable of type PropertyDescriptor because that is always going to be a safe assignment, there is no way the compiler can verify that the reverse conversion will be true - hence the cast is required. try using foreach(PropertyDescriptor p in TypeDescriptor.GetProperties(this.GetType())) { MyProp mP =(MyProp) p; }

You could just try and download the file using something like the WebClient class - however this could be slow in practice.

Looking at the il with ildasm it appears that the My.User.... function ultimately calls the WindowsPrincipal.IsInRole method anyway. Other than that I can't really see any major difference, personally I would tend to avoid the My.... methods simply because I use both vb and c# so I try to use functionality that is present in both (less for me to remember that way)

You need to move the declaration of MyDBConn to before the try block.

Could you not just use a literal control and set it's text to the html you want to display?

Depending on the version of .Net and exactly what you are trying to do will really make a difference here. The data grid in .Net 1 seems to be a lot more bloated than the GridView control in .Net 2 so if you are using .Net 2 try switching. Rather than creating the table through code though you might want to look at using either the DataList or Repeater control - these will give you more control over the HTML but still have an easy databinding way of doing things.

You will probably need to declare the CSIDL_APPDATA constant try Private Const CSIDL_LOCAL_APPDATA = &H1A&

The code I posted was for vb.net, http://support.microsoft.com/kb/252652 has a link for doing the same in VB6. Either way will work on 98 / ME though.

1. Potentially none, this could be move to another location even for the OS' that use it by default. 2. You should always use Environment.GetSpecialFolder(...) to find this kind of thing e.g. Dim s As String s = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) 'or s = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) should get you the path you are after.

What was the HRESULT / associated error?

As a rule data readers will have lower overheads than datasets and can help improve performance. Other than that you will find tuning the sql itself will often give good performance i.e. only selecting the rows / columns you need, implementing your own paging logic etc. will often give bigger improvements over the simple choice between datareaders / datasets. It may be worth investigating the use of an O/R mapping tool to help streamline the actual data access code you are writing. As you are using asp.net it is also worth investigating the Cache object and out put caching - both of these can help remove database calls entirely, used sensibly they can be a good performance win. How are you displaying this information in your front end?

What are you using for the LDAP side?

It is an extra layer of security for the web.config file. If somebody has physical access to the server then you already have problems in ensuring security - however this may be unavoidable (3rd party hosting as an example). Encrypting the config file simply prevents information contained from being available in clear text, by securing the container you are preventing all but one or two selected accounts from ever being able to decrypt the file.

IIRC you would need to create a UITypeEditor - http://msdn2.microsoft.com/en-us/library/fd3kt7d5(VS.71).aspx has an example and links to further documentation.

They key is required to decrypt the sections - if you delete it then asp.net cannot decrypt the relevant sections. If you have already set permissions on the container though you shouldn't need to delete they key anyway.

Could you not use the httpcontext class to get to it?

Have you given the resource a locale that is different from the form itself?

Could you not just do a Response.Redirect or Server.Transfer from within the web part?