PlausiblyDamp

Something like Dim vncfile As String 'vnc file contents vncfile = "[Connection]" & vbCrLf & "Host=" & ip & vbCrLf & "Password=password" & vbCrLf & "[Options]" & vbCrLf & "UseLocalCursor=1" & vbCrLf & "UseDesktopResize=1" & vbCrLf & "FullScreen=0" & vbCrLf & "FullColour=1" & vbCrLf & "LowColourLevel=1" & vbCrLf & "PreferredEncoding=hextile" & vbCrLf & "AutoSelect=1" & vbCrLf & "Shared=0" & vbCrLf & "SendPtrEvents=1" & vbCrLf & "SendKeyEvents=1" & vbCrLf & "SendCutText=1" & vbCrLf & "AcceptCutText=1" & vbCrLf & "DisableWinKeys=1" & vbCrLf & "Emulate3=0" & vbCrLf & "PointerEventInterval=0" & vbCrLf & "Monitor=\\.\DISPLAY1" & vbCrLf & "MenuKey=F8" & vbCrLf & "AutoReconnect=1" Response.Clear() Response.ClearHeaders() Response.ContentType = "application/text" Response.AppendHeader("Content-Disposition", "attachment; filename=Run.vnc") Dim b() As Byte = System.Text.ASCIIEncoding.ASCII.GetBytes(vncfile) Response.BinaryWrite(b) Response.End() on the server side should generate the relevant content and send it down to the browsers as a .vnc file - as long as the client has the vnc viewer installed it should prompt them to open it with the correct app and that should be that. You may need to change the line Response.ContentType = "application/text" to Response.ContentType = "VncViewer/Config" though - I don't have vnc installed here so I couldn't test it for sure.

The error appears to be being thrown by Microsoft's code - it is an error inside the SQlDataReader class itself - this is either a problem with the DataReader or with the connection to SQL itself. As well as checking you are closing all connections you really should monitor it with a 3rd party tool - this will show what is actually happening rather than what the code suggests is happening. There is always the possibility that readers / connections are not being closed if errors occur as your close statements are outside of the try block.

Does the file need to be in any particular characterset or encoding? Try something like StreamWriter LFWrite = new StreamWriter("C:\\Lock001.txt", false, System.Text.ASCIIEncoding.ASCII); to create the StreamWriter as the default is UTF-8 which could well be confusing the old application.

Looks like it is a problem inside their code rather than yours - did you check to see if you were leaving connections open?

When you catch the error could you also log ex.ToString() as that would give yu more information regarding the stack trace. Are you closing all you connections properly in your application? Try ... Finally blocks could help here; you might want to check through the SQL admin tool or perfmon how many active connections there are - if there are a large number then this error can occur as the server is possibly running at it's limit. Also - just as an aside : are you really storing the connection string and SQL criteria in the viewstate?

Is the .exe installed on the PC in question or are you running it from a network? Also if you run it from your PC but logged on as the user in question does it still work? Similarly if you log onto a user's PC as yourself and run the app does it work?

Could you not define an interface that all actions implement (IAction or similar)? That way you would never need to know the actual implementation - the majority of your code works with the interface.

If there are several different object types that you need to perform the same operation on then you should really be looking at implementing an interface. Could you give a bit more detail about the kind of objects you are using where you feel 'Object' is the best way?

I would avoid Object as a datatype wherever possible - in this case because the generic list class implements the IList interface anyway you could simply use 'Select Proper List Dim SelectedList As IList If ListChoice = 1 Then SelectedList = List1 ElseIf ListChoice = 2 Then SelectedList = List2 ElseIf ListChoice = 3 Then SelectedList = List3 Else SelectedList = Nothing End If If SelectedList IsNot Nothing Then If SelectedList.Count > 0 Then SelectedList.RemoveAt(SelectedList.Count - 1) End If End If and avoid the use of Object - will even compile with Option Strict On (you do use Option Strict On I'm assuming) and you still get intellisense for the SelectedList variable.

The shell command will run the application on the IIS box itself (as whatever user the web-server is configured to run as). Rather than trying to launch the .vnc file on the server you could have it downloaded to the client and run from there - that should launch the vnc viewer on the destop.

Do you get any errors show or is it literally just failing to display the message box? Have you tried running it on your development box but without a debugger attached (either running the .exe direct or from VS using the 'Start Without Debugging' option)? One of the rules of windows forms is that you shouldn't mess with the UI from anything other than the main UI thread - not sure if it is relevant but the call to MsgBox could be falling foul of this rule; it might be worth trying to write to the event log my.Application.Log.WriteEntry(txt) in the RptThread method to see if that works.

The actual performance hit of an exception being thrown isn't that great in a release build anyway (there still is one so excessive exceptions need to be avoided) however the second example of yours probably puts it's own performance overheads on and increases the code to maintain while decreasing the readability... I am a big believer in the phrase "Premature optimization is the root of all evil." if the performance hit of writing cleaner more readable and maintainable code is sufficient to be a problem then I will look at alternatives....

I must admit that in the past I tended to be a big fan of the various Assert mechanisms in most languages, these days I virtually never use them as I tend to get quite fanatical about unit tests as a way to catch these problems. Getting back to the topic though... I honestly can't remember a single time I have ever either checked the InnerException property or thrown an Exception where I felt the need to provide one. I can't think of many situations where effectively changing the exception to a different one from the actual real problem is ever going to make thinks clearer. In a similar vein I often don't check for things like nulls so I can throw an exception if the result of me not checking is simply the same exception gets thrown anyway. In practice i tend to find the number of try ... catch blocks is far outweighed by try ... finally (or using statements really) as in most places when an exception is thrown there is either very little that can be done or it's serious enough that an application level handler is more suitable as there is nothing much you can do but indicate the connection to database / server / whatever has been lost.

Me.dgFile.CaptionText = sptable & " Table" Me.dgFile.DataSource = ds.Tables(</pre><table name or number>) Me.dgFile.Show() </

Have you tried running the command prompt as an Administrator and then using regsvr32 to register the component?

Which server side event are you using to create the textboxes? If you want the controls to automatically load information from the page that is being posted back you really need to create them controls in (or before) the Page_Load event.

http://msdn2.microsoft.com/en-us/security/aa480150.aspx gives a broad outline of what you need to do. Taken from that link is a sample minfest processorArchitecture="X86" name="IsUserAdmin" type="win32"/> Description of your application level="requireAdministrator" uiAccess="false"/> this should get you started on generating your own manifest. As an example for an executable called WindowsApplication1.exe you would create a file called WindowsApplication1.exe.manifest that would contain processorArchitecture="X86" name="WindowsApplication1" type="win32"/> Description of your application level="requireAdministrator" uiAccess="false"/> After building your application if the .exe and the .exe.manifest are in the same folder run the following command mt -nologo -manifest windowsApplication1.exe.manifest -outputresource:WindowsApplication1.exe;1 If you are building a dll rather than an exe replace the 1 at the end with a 2. Try running the app and you should get the prompt to elevate to admin, also in explorer you should see the icon overlay as well.

http://msdn2.microsoft.com/en-us/library/ms724834.aspx has the info you need.

50 different exceptions? Is this all in one place? If so are they all thrown by a 3rd party library? Where possible you should be catching the exceptions as close to where they occur as you can. It might help if you gave a bit more detail about your situation to see if any further advice can help.

Often catching all exceptions can be considered a bad practice; when you are implementing a catch block you are assuming responsibility for handling the problem correctly. If you are unaware of the exact type of problem it is very difficult to decide how to deal with it. In some situations it may be impossible for you to handle it anyway (try catching an OutOfMemoryException or StackOverflowException for example). Catching all exceptions while developing or debugging can hide potential problems - both from you or from parts of code higher up the chain that can handle them correctly, this is potentially introducing new problems rather than solving them. Without knowing why you need to catch all exceptions it's hard to give definite rules though, so my above post may not be relevant :-\

Whoops - my bad. You would probably be better of removing the Finally block and closing the file in the Catch block. Catch x As x ... If Not FilePath Is Nothing Then FilePath.Close() End If End Try

Private Sub ProcessButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles ProcessButton.Click Try Dim FilePath As FileStream = Nothing For Counter As Integer = 1 To Some Number FilePath = New FileStream(FileString, FileMode.Create, FileAccess.ReadWrite) ...process Next Catch x As x ... Finally If Not FilePath Is Nothing Then FilePath.Close() End If End Try End Sub You don't need to close the file within the Try block as the Finally will always run - it is a good idea to check that you have a valid file though just incase the New FileStream(...) bit fails for any reason.

Try Me.Invoke(d, New Object() {Message})

http://msdn2.microsoft.com/en-us/library/wz42302f.aspx

Focus is a method not a property, try Me.OKButton.Focus()