PlausiblyDamp

What is the sql you are using to return the data? If you look at the dataset / datatable in the debugger are the table / column names the same as what you are expecting? Do the columns contain data?

Try using _ Private Shared Function GetWindowTextLength(ByVal hwnd As IntPtr) As Integer End Function _ Private Shared Function FindWindow( _ ByVal lpClassName As String, _ ByVal lpWindowName As String) As IntPtr End Function _ Private Shared Function GetWindowText(ByVal hwnd As IntPtr, _ ByVal lpString As StringBuilder, _ ByVal cch As Integer) As Integer for the declarations and see if it makes a difference.

The System.IO.Path class will do pretty much everything you are after in regard to manipulating file names. Out of interest is there a reason why you are truncating file names to eight characters?

http://www.microsoft.com/express/support/faq/ point 14 covers the framework version. As far as I am aware all the varsions of visual studio use the same compiler and as such would produce the same code without any differences in performance etc.

Is there any other code attached to the form or combobax that might be interfering with the autocomplete? Just tried duplicating your problem on my PC and it worked as expected for all the AutoCompleteModes.

It looks like there is a version mis-match with the Microsoft.VC80.DebugCRT files, not sure how the best way to solve the problem is though short of rebuilding the original dll. Sorry I can't be of any more help...

How have you declared the relevant API functions (GetWindowText etc.)?

C++ isn't even close to being my strong point so anything I say is suspect, however I think the problem is the fact you aren't casting the return from GetProcAddress to the correct type. Something like typedef BOOL (*DoWorkFunc)(LPCTSTR , DWORD , BOOL , UCHAR , UCHAR ); DoWorkFunc pDoWorkFunc = GetProcAddress (hModule, "DoWork"); might be closer to the right answer.

Could you post the code you are using to Serialize / Encrypt and Desirelize / Decrypt the file?

That is pretty much all that is involved in running from the command prompt. Can you browse to the DLL from within Excel and add it as an addin that way?

It is based on the locale you specify - this would normally be done in the Main method of your application if using C# or the MyApplication_Startup if using vb in vs 2005 or later. To use the default locale it would be as easy as Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture to use a specific culture that would just be something like Thread.CurrentThread.CurrentUICulture = system.Globalization.CultureInfo.CreateSpecificCulture("de-DE")

http://www.naughter.com/ping.html might be worth a look - is just a ping implementation in C++

.Net itself has a fairly reasonable localisation mechanism via the use of resx files. In visual studio itself if you select a form and look under it's properties there is one calle 'localisable' - setting this to true will move all localisable content from the ui into this .resx for you. If you have any strings hardcoded into the actual code files then this can get a bit nastier to move into .resx files, however http://www.codeplex.com/ResourceRefactoring can be a big help in getting this task done. Once all the basics are done you can then add new languages via these .resx files (resgen.exe installed along with VS can make handling the string conversion easier, winres.exe can make designing the ui easier). One good thing is that all languages apart from the default one get compiled in to seperate dlls so these can be built outside of VS and created / deployed as and when there is a need.

Masterpages are probably the closest thing in asp.net - have you looked at them?

Not personally done much with serial ports with .Net but System.IO.Ports.SerialPort is probably the best starting place.

Once you have run the installer does it copy the COM dll to the expected place or is that not happening either? If you execute the MSI from an elevated command prompt does that make any difference?

The only one I am aware of is System.Globalization.CultureInfo.CurrentCulture.TextInfo.ToTitleCase This will case according to your culture's rules but I don't think it special cases words like 'of' etc.

is including the file ~/imageswap.html into the current file and is not a comment while I think the other two lines are comments :confused: If you delete each of those lines in turn does it break anything?

Where / how are the variables tstart, trav, dlink and dlink1 declared?

Just out of interest which areas of the registry are you writing to?

Try right clicking on the project and selecting Add Reference... then select the relevant dll.

My bad, I was fiddling with a couple of other things and forgot to say. I think the problem is down to where you are loading the plugins from - all the files are found in the same folder as the executable and a "plugins" subfolder, IIRC this will cause problems as the same interfaces / classes are being loaded more than once. Try getting it so the plugins and supporting files only exist once in either one or the other of those two places and see if that fixes the problem.

After a couple of changes it now seems to run without any errors. In the gateway.vb file I changed the following 'Delegate declaration to Public Delegate Function _GetPluginInformation(ByVal FullPath As String) As IPlug.IPlugInfo and the GetPluginInfo method to Friend Function GetPluginInfo(ByVal FullPath As String) As IPlug.IPlugInfo Dim tempAssembly As [Assembly] Dim IPlugName As String = GetType(IPlug.IPlugInfo).ToString Dim temp As Type Dim tempRef As Object Dim tempPlugInfo As IPlug.IPlugInfo tempAssembly = [Assembly].LoadFile(FullPath) For Each Exported As Type In tempAssembly.GetTypes 'cycle through the types that are in the assembly If Exported.IsPublic Then If Not ((Exported.Attributes And TypeAttributes.Abstract) = TypeAttributes.Abstract) Then temp = Exported.GetInterface(IPlugName, True) 'checks for a match against default interface If Not (temp Is Nothing) Then 'if it is there, set the flag tempRef = tempAssembly.CreateInstance(Exported.FullName) 'when it hits the following line it gives the error tempPlugInfo = DirectCast(tempRef, IPlug.IPlugInfo) End If End If End If Next Return tempPlugInfo End Function

A type that implements an interface is different from the interface itself, you cannot cast between two different types. e.g. Public Interface ITest Function TestFunc() As Integer End Interface Public Class TestClassOne Implements ITest Public Function TestFunc() As Integer Implements ITest.TestFunc Return 0 End Function End Class Public Class TestClassTwo Implements ITest Public Function TestFunc() As Integer Implements ITest.TestFunc Return 0 End Function End Class Even though both classes are nothing more than the same implementation of the ITest interface they are not the same type and any attempt to cast e.g. Dim t1 As New TestClassOne Dim t2 As TestClassTwo t2 = DirectCast(t1, TestClassTwo) will not work. If you have Option Strict On set (and you should IMNSHO) this code will not even compile. If you were to jest return the interface rather than a type based on the interface everything should work just fine.

Just because PluginInformation and tempRef happen to have an interface in common doesn't mean you can cast one to the other, you could cast either to the IPlug.IPlugInfo interface as they do have this in common. An integer and a string both implement the IConvertable interface, this doesn't mean you can cast a string to an integer though.