PlausiblyDamp

The API GetWindow sounds (reads???) like it might be of use in this situation.

In the Form_Load you are declaring the DT variable - this will fall out of scope when the Form_Load method exits. You are then declaring a new variable (that just happens to share the DT name) in the AddRow_Click method. You would probably need to store DT in a session variable or similar so it would survive between postbacks.

You could try something like IEnumerable peopleOlderThan; private void QueryData() { peopleOlderThan = from p in people where p.Birthday < DateTime.Parse(textBox1.Text) orderby p.Name ascending select p; dataGridView1.DataSource = new BindingSource(peopleOlderThan, null); } You should then be able to access peopleOlderThan in other methods etc. by using a generic IEnumerable at least you also get proper intellisense throughout your code as well. If you are messing with multiple threads then the above code is probably a disaster waiting to happen unless you implement some proper synchronisation .

You could always use the Process class to launch a mailto:xxxx url - that should launch the default mail editor just the same as clicking the link in a web page would do.

Have you tried doing the insert without specifying a SrcColumn for the data?

Could you post the actual code you are using in the windows application?

What problems are you having with the first bit of code? If it works correctly under a console app then it certainly should work for a windows app. Not sure what the second snippet should be doing - from the look of it you should just end up with txt2 containing the same as txt1.

The FormView control might be useful as it is a fully templated control - this way you can have a much finer degree of control over the resulting HTML generated.

If you are using VS 2005 you could try My.Application.CommandLineArgs as an alternative or have you tried Environment.GetCommandLineArgs

You could choose to implement the ISerializable interface yourself - that way you would have exact control over what did and didn't get serialized at run time.

The only way I know of doing this is via the registry; If you look under the HKEY_CLASSES_ROOT key you should see an entry for .html - this will have as it's default value something like htmlfile. If you then look under HKEY_CLASSES_ROOT\htmlfile\shell\edit\command then you will see the currently registered application. To make your application the default simply change this to point to your app (this is pretty easy to do via the registry classes under .Net) Personally I would make this an option within your program rather than resetting it every time your application is run as the user might prefer another tool and choose your application for a feature that it excels in - if running the app causes it to take over the association I would soon stop using it.

Dim s As String = "test message thing" s = System.Globalization.CultureInfo.CurrentCulture.TextInfo.ToTitleCase(s) should do it for you - also is locale aware when it comes to handling what should and shouldn't be capitalised.

One good way to get code reviews to work is schedule them for a fairly non-productive time of the week (a couple of hours on a day when people just seem to be less enthused about their work...). Encourage people to send their code to their peer reviewer a day or two before the review itself so they have a chance to look at it - on beneficial side effect is people often find it easier to do this on a more ad-hoc basis just to get feed back if they are unsure of their current approach rather than stubbornly plodding on regardless. Try to avoid acting too overly superior in code reviews - the other developers should feel comfortable criticising your bad decisions / code just as much as each others, equally if a person can justify and defend their methods they might be right ;) OOP can be beneficial in this kind of scenario as a small-ish class can be delegated, reviewed and tested as a single 'work unit', if parts of the system can be designed in this way then delegation becomes easier e.g. in a data access layer splitting functionality such as connection management, config file handling, command creation / execution or similar into one or more classes or methods will foster a cleaner design in the long run and should produce cleaner code. Some of these ideas may only come together through communication. Encourage people to admit when things could be done better (and give serious consideration to making the relevant changes). Encourage relevant documentation which is appropriate to the scale and scope of a given project or task; a class itself may need no more than a simple class diagram and a couple of lines of text, a major system possibly more but with less detail. If you have time to look at other software then the code to #develop has some very clean design practices (please be aware of the the licence it is released under before actually 'borrowing' code though) - as very useful addition is their free book about the #develop project as it explains a lot of useful OOP terms and ideas in the context of a real application rather than a contrived scenario, plus they are quite open in admitting past mistakes and what was involved in fixing them.

One thing that I have found that can really help to prevent a 'them and us' type of environment is frequent code reviews. These can be fairly informal and definitely do not need to be a lengthy process either - however it means everybody can get familiar will all aspects of the system (providing good coverage if a single developer leaves or is away for any length of time) while also allowing all interested parties to see what direction things are going in and what is required (this way the 'users' of the class library get a valid chance to provide input and criticism and even contribute to it). Getting everybody involved in producing a working product has got to be the ultimate aim (just nip over to http://www.thedailywtf.com and search for Enterprise or Enterprisy for examples of overblown and pointless frameworks). For a small team it might be worth considering a more XP style of development (such as TDD) - this can reduce wasted time on over complicated design or massive frameworks and keep people focused on writing quality and necessary code.

And nice it is too. The web designer has had some much needed improvements (nicer master page support, nested master pages in the ide!, the ListView control is great), LinQ and it's related technologies are pretty impressive as well.

You should be able to use tlbimp.exe to create the interop dlls without requiring the full visual studio ide, these interop dlls can then just be copied to the development machine and built into your deployment package.

Is there any way to identify which version of the software is installed on a particular machine? If so you could potentially ship the interop libraries for all versions any use reflection to instantiate classes from the correct version at runtime.

WMI should expose a DriveID property - this should be the drive letter.

If you are dealing with something like a streamwriter then it is documented behaviour that you should explicitly close the streamwriter when you have finished writing rather than leaving it for the garbage collector. Suppressing finalization will simply result in the file remaining locked until the GC kicks in - this could result in an unacceptable wait before the handle is released.

Without seeing the actual code it is pretty difficult to check where an object may be failing to be released correctly - have you considered using try ... finally blocks around your allocated resources (or the Using statement if .Net 2). Also how are you checking if the object has been released or not.

Often the information presented depends on the file type itself - certain file types define their own metadata (i.e. jpegs have exif tags). NTFS does offer something called Alternate Data Streams - these are a way of attaching additional data to a file, however this requires the file resides on an NTFS volume as the information will be lost if the file is moved to something like FAT (or backed up with a non-ADS aware backup solution). http://msdn.microsoft.com/msdnmag/issues/06/01/NETMatters/default.aspx has a useful little article on how search for and read them, adding support for writing probably isn't that difficult.

In the code snippet you posted the line intC = MCS.PassThruConnect(MCS.Protocol.MSCAN, MCS.PassThruCon_TXFlag.TX_BLOCKING, intCC) has a parameter intCC - are you getting consistent values back when you call the method?

Without seeing the code in question this isn't the easiest question to answer ;) It might be worth giving a sample piece of code that shows the problem / how you are currently dealing with the interfaces.

Does the pChannelID parameter change with the different exes you are running or is there some other way you are identifying the different devices?

Do you have an example of how you actually use this dll? i.e. how your executables call it.