PlausiblyDamp

Do you mean tips on documenting them or just tips in general?

System.IO.Directory.GetFiles can be used to check if any files match your criteria. You may just want to catch there error though rather than checking first if there is the potential for new files to be created between the check and then the deletion...

Why not just use a parameter of type MessageBoxIcon?

If you are doing this with .Net 2 then you might want to look at the BackgroundWorker component. Other than that you would probably need to look at retreiving the information in a background thread rather than the main UI thread.

What does your application do? If it is only accessing it's own files etc. then there is no need to putthose files in a location hat requires admin access. One easy way to launch an application as another user is the runas command - type runas /? at a command prompt to see the help for it.

If you use the application as a shell it will be launched with the security credentials of the user logging in. As far as I'm aware there is no way to get your shell launched with an alternative set of credentials. As a work around you could make the shell a stub application that launches your shell via something like the runas command to elevate the permissions. Personally I can't think of many things that would expose security concerns more than a shell always having admin rights regardless of who logs in.

You would either need to relax the security on the folders / keys you need access to or run the application as a user with permissions to those resources. Alternatively if you are only dealing with your own files etc. you could store them in locations the user does have access to.

The basics of forms passing information around can be found in this thread Threads are only a problem when dealing with UI elements from a background thread - the general idea of how to do this is exactly the same as in your above post.

Not tested (or even compiled) but something like Public Class Form1 Delegate Sub SetEnabledCallback(ByVal enabled As Boolean) Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim thRead As New Thread(New ParameterizedThreadStart(AddressOf myThread)) thRead.Start() End Sub Private Sub myThread(ByVal o As Object) Me.SetText("a") End Sub Private Sub SetEnabled(ByVal enabled As Boolean) If Me.TextBox1.InvokeRequired Then Dim d As New SetTextCallback(AddressOf SetEnabled) Me.Invoke(d, New Object() {enabled}) Else Me.TextBox1.Enabled = enabled End If End Sub End Class should do the trick.

Just to add - putting Option Strict On at the top of your source files will catch a lot of these mistakes at compile time rather than run time.

You could alternatively check the sender's type or cast it to a control and check it's name. If you want it to do two different things based on how it is called it might be easier to either handle the form load and the check changed event's with their own event handlers.

Got it, like it. Some of the interface takes getting used to though - but very nice when you do. VS has some known 'issues' one being it isn't supported without SP1 and an additional Vista patch... but by and large no real problems.

Yep - if you are using .Net 2 then TryParse is the way to go, if you are using .Net 1 then Parse inside a Try ... Catch block will do the trick.

Personally I don't rate boot camps at all - they are nothing more than an exercise in getting an exam under your belt and provide no real knowledge of how to use the product in any way shape or form. If you are relying on certification to gain employment it looks good on paper, however you will suffer in any kind of interview that involves technical questions. If you do survive the interview process and get the job you are probably going to be far less capable than your new employer thought... If you know how the product actually works and how to apply it in the real world passing the relevant exam(s) isn't that big a leap - plus you now have the benefit of certification and actual knowledge.

It is also worth noting that because each instance is a separate install they can be service packed individually and they also each maintain their own set of logins.

The .ToString implementation for you custom types isn't available to the client, web services don't allow your types to have a full implementation at the client side simply because there is no guarantee what the client is.

Depends on the situation - a select case is often cleaner and more maintainable when you have one condition but several possibilities, if .. else if .. else allows you to have different and more complex decision making logic for each if / else if.

My bad, didn't read your code properly... Is this problem occurring with any application or just specific ones? Does the application(s) in question have a splash screen or similar before the main window is launched? If so that could also be causing this issue. Have you tried using the Handle property of the object returned from Process.Start - this is the native handle for the application; you might be able to use it with the GetWindowThreadProcessId function.

Process.WaitForInputIdle () will be better than looping as loops can eat CPU cycles and bother people running laptops on battery. Also be aware that MainWindowHandle will always be 0 for some applications, I seem to remember reading something about this being the case if the applications main window (or first window displayed anyway) is a dialog rather than a standard window.

You never should be manipulating the UI from anything other than the main UI thread - it was just that .Net 1 / 1.1 didn't enforce this rule; this however could lead to hard to track down problems at runtime so .Net 2 detects and traps this violation. http://www.xtremedotnettalk.com/showthread.php?t=95171 might shed some light on how to do this correctly.

Seems a strange problem! Is the exception being thrown from your code? If so it might be worth checking if InvokeRequired is true and then either Invoking yourself or just exiting the routine anyway...

http://blogs.msdn.com/ansonh/archive/2005/12/08/501763.aspx - the answer as to why is a bit of a disappointment, they do show you the fix though ;)

There is Sandcastle from MS themselves - isn't perfect and a bit slow but does support .Net 2 properly. The tool itself doesn't have a gui but you can get several from 3rd parties http://www.codeproject.com/useritems/SandcastleBuilder.asp mimics the look and feel of NDoc. Others can be found at http://www.sandcastledocs.com/Wiki%20Pages/Sandcastle%20GUIs%20from%20Community.aspx

The Thread.Sleep will impact on system resources far less than the loop so out of the two I'd plump for that one. Be aware though if you are doing this in the code behind a web page it will increase the time it takes to refresh the page and this could cause users to think it has hung.

Too lazy to type - http://msdn.microsoft.com/msdnmag/issues/03/07/NET/ should get you going.