Thanks a lot, Paul, for taking the time to explain all that. Perhaps gradually it will sink in. I know I am liking .NET and, oddly enough, cSharp a lot more than I had expected to so I'll probably be churning around in the pond for quite a while.

Have you installed the .net2003 Beta? Are there any issues with putting it on the same box and if one is at the infant learning stage I'm obviously at do you think it would be better or worse to work with ?


>>
>>In the Csharp Windows example, the namespace HW.NetBook.Samples is the first line in both the MainAppForm and the CustomersOrdersForm. Beneath that classes are defined. If, in another form someplace I say "using HW.NetBook.Samples" (set Classlib to ???) are those classes defined in the two other forms available for instantiation?
>>
>>You can see I don't quite have a handle on this so if anyone can foxify the explanation of this it would be appreciated.
>>
>>
>
>Name spaces are just a grouping mechanism in .NET. The are >sort of< like class libraries, but different ;-) Namespaces can span multiple files. They let you logically group your classes. The "using" keyword is simply there to help you minimize typing. Without namespaces, you would need to type the full namespace in order to access a class:
>
>HW.NetBook.Samples.CustomerOrdersForm.SomeMethod();
>
>With "using":
>
>using HW.NetBook.Samples;
>
>CustomerOrdersForm.SomeMethod();
>
>Since you're using C#, you can only use a namespace up to one level above the current class. In the example above, you noticed that I only said "using HW.NetBook" instead of "using HW.NetBook.Samples". That's because of the one level limitation with C#. In C#, I always have to prefix the method with classname. If you're using VB.NET, you can use Import (VB's equivalent of "using") right up to the class name. So it would be possible to call the method w/o the class identifier.
>
>Unlike VFP's classlib, "using" doesn't behave like a "SET CLASSLIB TO" command. To include other projects or libraries, you need to add a reference to it (similar to the way you use ActiveX controls in VB). If you're working on a project (not a solution), right-click on the project in the Solution Explorer treeview on the righthand side of the screen. Select "Add Reference". Then you can click on Browse and find the other project's DLL and select it. If you've got a solution, you can do the same click by right-clicking on the "Solution" root-node in the same treeview.
>
>This is >only< required when you are referencing classes that are contained within another project. If all your classes are inside the same project, VS.NET should be able to find them automatically.
>
>If, as you type the "path" to your methods, you notice that Intellisense isn't kicking in, that's usually a good indicator that VS.NET can't find the class you're trying to use. It's usually a spelling and/or case thing.
>
>HTH