divil

Nothing I'd call significant, no. It does seem a shame to have every label etc using its own hWnd, but these days there are hundreds of window handles around already on the average desktop anyway.

Well I'm assuming that these new versions of your software actually do have new version numbers (set in AssemblyInfo) so it's important to remember to update your setup project to reflect the new version.

1) Use the TopLevel property. It's there. 2) Merging won't work unless you're dealing with mdi child forms. It's best not to use Forms with DocumentManager, that's not what it was created for. You can still design controls with Visual Studio using the UserControl designer.

It's interesting, that when Sun won their case against Microsoft, they effectively sealed Java's fate - at least on the client side. Being distributed with Windows is the best thing that can happen for a product, and that's not allowed any more.

Are you actually changing the product version number, in the properties of the setup project? If not, it won't remove previous versions (because there technically aren't any).

1) There is no automatic menu/toolbar merging yet, I am still deciding on the best way to implement this. 2) It's gone by default, but it virtually a one-liner to create. Check out the FAQs section on the SandBar website for a full example of hosting a control in a toolbar. http://www.divil.co.uk/net/controls/sandbar/

Windows Forms does not support windowless controls.

When using the synchronous Connect method of the Socket class the first thing you should do afterwards is check the Connected property to see whether or not it was successful. As you're using TcpClient instead of Socket, I'm not sure what to advise. TcpClient appears to just call the Connect method of the underlying Socket, but doesn't check Connected afterwards. You could do this yourself, but the underlying Socket is only exposed via a protected member so you'd have to inherit to add your own Connected property. Unfortunately I don't have much experience with TcpClient (I've always used Socket directly) so this is all I can suggest.

Is the CopyLocal property for the assembly set to true in the solution explorer? It sounds like maybe it's not getting copied to the output directory, in which case .net wouldn't be able to locate it at runtime.

You declared l wrong.

It turns when it gets added. It's done internally, and is a very common practice when adding objects to collections.

If your debug symbols (pdb) are included with your assembly, then a debugger knows where to find the source code and how to map source code lines to IL instructions. There's probably documentation for cordbg in the SDK, if not, the help function within the software isn't too bad.

Yes, you use GetFiles to get your array of files, the GetFileName on all those entries to convert them to just the filename instead of the whole path. Then you feed that array to the listbox's AddRange function.

Well, you can intercept WM_NCPAINT and take responsibility for drawing the nonclient parts of the form yourself. This includes the borders and titlebar as well as the menu. I don't know what functions, if any, allow you to determine the region occupied by the menu bar though.

If you really want to write your own message loop, there's nothing to stop you using the standard api functions to do this. Just declare the functions using platform invoke in the normal way.

Just to add to this... .NET is sometimes not very helpful about reporting missing dependancies, as you can see from the exception information Drstein99 posted. This seems to be even less helpful on Windows 98 machines, where it isn't possible to install Visual Studio to debug the software. One option is to copy across some of the files from the .NET SDK, including cordbg.exe. This useful program is a fully-featured debugger which operates via a command line, and running your application through it will reveal a great deal more than the unhelpful exception dialog, and show you the whole exception. If you copy your source code to the target machine it'll even give you a stack trace and show you just where the exception occured.

There aren't any, you're going to have to write them yourself I'm afraid. The system colors you need are: SystemColors.ControlLightLight SystemColors.ControlLight SystemColors.Control SystemColors.ControlDark SystemColors.ControlDarkDark

Or System.IO.Path.GetFileName()

Stick this on your property. <EditorAttribute(GetType(System.Windows.Forms.Design.FileNameEditor), GetType(System.Drawing.Design.UITypeEditor))>

Just set its Dock property to Fill, and it will automatically resize to occupy the whole of its container.

You won't be able to do this with native .NET methods. That colour is taken from the system colour settings.

There is no direct framework equivalent in .NET 1.1 - this has been implemented in .NET 2.0 where all numeric types have a TryParse method that does not rely on trapping an exception.

There is no difference. The latter case is optimized correctly to make it as effecient as the former.

Check out the DrawBorder3D method of the ControlPaint class.

this.Menu = null; That works.