divil

Yes - please see the FAQ posted as a sticky thread in the forum.

Presumably if you're creating your application context you must be storing it somewhere, in which case you can pass it to your main form as it is created so it has a reference to it too.

I don't think it's "retarted" at all. VB just happens to support one more layer than C# in terms of project-wide imports instead of having to declare them all in every file. Personally I think this is pretty useful, but like you said it can potentially cause problems when moving files between projects. For example in a large presentation layer it would be great to always import System.Windows.Forms, System.Drawing, System.ComponentModel without having to specify them every time like you do at the moment with C#. Mike_R: There is no such thing as having option strict off in C#. One of the reasons I like it :)

The framework itself does fully support optional parameters, natively. It is C# that is lacking support for them. However this does not mean they are a good idea. The VB compiler does indeed compile in the default value of a parameter when calling the function. If you try writing a small method which takes optional parameters and disassembling it, you can see the default values and metadata associated with them. The best practice is generally accepted to be overloading functions, which essentially does the same thing anyway. For the above example, you declare another version of the function without a gravity parameter that calls the first function passing 9.8 or whatever.

End is, however, not normally recommended as a good way of closing your application as it's good practice to clean up resources you are using explicitly. Closing the form your application is relying on for its message loop is generally a good idea instead.

Check the user-agent header the browser passes to your site. If they're using internet explorer the version of .NET installed will be passed as part of this. You can then at least tell them that since they have .NET already they can download the smaller version. Those users that aren't using Internet Explorer (or just don't have .NET) you can still present with a choice.

TabPages only have a Visible property because they inherit from Control. The TabControl uses it internally so that only the selected tab is visible, the rest are hidden. If the Visible property was changed to indicate tab visibility, how would it show/hide the different pages depending on which tab was selected?

I have used LogonUser to impersonate a user with success. Why do you say you cannot do this?

I suggest you go on using your third-party control then.

The easiest way would be to derive from those classes in question, override the properties in question and apply the BrowsableAttribute to them.

You cannot remove the property. You can hide it from the PropertyGrid by applying a Browsable(false) attribute to it in your derived class. You can hide it from the intellisense by apply an EditorBrowsable attribute to it in your derived class. You can stop its value being serialized by the designer by applying a DesignerSerializationVisibility attribute to it in your derived class.