[RESOLVED] Understanding Namespaces

[RBARATA]

What's the difference between System.Windows.Forms.Label and System.Windows.Controls.Label?

What does each of these entities represent?

And in my code, it starts by Public Class Form1. Where is it located in the Namespaces "hierarquical tree"?

[wild_bill]

System.Windows.Forms.Label is used in Windows Forms Applications while System.Windows.Controls.Label is used in WPF Applications. The default namespace that all forms will be in is the same name as your project. You can view and edit this by going into your project's properties under the Application tab there is a 'Root namespace:' box.

[RBARATA]

I can see a project uses several different Namespaces.
Can I say that VB's "interface" (grafically and code) work inside the system.windows? I mean, different Namespaces can be "called" but always from system.windows.

[jmcilhinney]

A namespace is simply a logical grouping of types within which each type name is unique. That's it, that's all. The System.Windows.Forms namespace contains types that are intended to be used in Windows Forms applications. That doesn't mean that Windows Forms applications can't use types from other namespaces. Types from other namespaces are not specifically intended to be used only in Windows Forms applications though.

For instance, whenever you use ADO.NET, you are making use of types in the System.Data namespace. Types that relate specifically to data access are members of that namespace and they can be used in Windows Forms apps but they can also be used in other types of applications. If you're working directly with SQL Server then you will use types from the System.Data.SqlClient namespace. If you're accessing a data source via an OLE DB provider or ODBC driver then you will use types in the System.Data.OleDb or System.Data.Odbc namespace. That should illustrate how namespaces are used to group related types.

As for all type names within a namespace being unique, you hit upon that your self in your original question. There is a Label class designed for Windows Forms application, there is a Label class designed for WPF applications and there is a Label designed for ASP.NET Web Forms applications. If there were no namespaces then they couldn't all be named Label because we wouldn't be able to tell the difference between them. They'd have to be named WindowsFormsLabel, WpfLabel and WebFormsLabel or something like that, which is cumbersome. By using namepsaces we are able to use the name Label for all three. In an application you can import just one of the System.Windows.Forms, System.Windows.Controls and System.Web.UI.WebControls namespaces and then, when you use the name Label, you know exactly which one you're referring to.

You may find it useful to follow the Blog link in my signature and check out my post on Assemblies & Namespaces.

[RBARATA]

Thanks for the explanation. I understood the concept of "Namespace".
But, inthis particular casr, I still have one doubt related with the properties of each namespace label.

In System.Windows.Forms, I see it as the domain on which all the controls applicable to a form have their existance (or are applicable).
But all the objects that are applicable to a form are called controls (buttons, checkboxes, etc).

So, what is the difference (in terms of applicability, properties, etc) between both labels (System.Windows.Forms and System.Windows.Controls)?

If, hierarquically they were something like System.Windows.Forms.Controls.Label that would make sense. But, if they are at the same level, probably these labels are something different but with the same name.

[jmcilhinney]

It's very simple and has already been explained. System.Windows.Forms is the namespace that contains all the types related specifically to Windows Forms. They are not necessarily all controls, but they are all related to Windows Forms. System.Windows.Controls is the namespace that contains all the types related specifically to WPF. They are not necessarily controls, but they are all related to WPF. The System.Windows.Forms.Label class and the System.Windows.Controls.Label class are completely equivalent, one representing a text label in a WinForms app and the other representing a text label in a WPF app. That's all there is to it.

[RBARATA]

The System.Windows.Forms.Label class and the System.Windows.Controls.Label class are completely equivalent, one representing a text label in a WinForms app and the other representing a text label in a WPF app. That's all there is to it.

Ok, now I can identify clearly my doubt, which is: What's the difference between WinForms app and WPF app? I couldn't find a satisfactory explanation (at least for a beginner like me).

[Shaggy Hiker]

WinForms is just your basic windows forms. WPF is a more recent technology. It is essentially a different way to create a user interface that addresses lots of the limitations of WinForms. You have all kinds of control of the shape, appearance, and behavior of controls in WPF. Of course, that comes at a cost: WPF is a steeper learning curve that WinForms. You can make prettier interfaces, but at the cost of learning.

[jmcilhinney]

Ok, now I can identify clearly my doubt, which is: What's the difference between WinForms app and WPF app? I couldn't find a satisfactory explanation (at least for a beginner like me).

I have to wonder, then, exactly what you would find to be a satisfactory explanation. I just searched for compare windows forms wpf and this was the first result:

http://geekatwork.wordpress.com/2010...-windows-form/

That seems like a perfect explanation for someone who is a beginner and therefore wouldn't necessarily understand all the technical details.

Even apart from that though, you don't have to understand anything about Windows Forms or WPF to understand the concept of namespaces. There are many, many more namespaces in the .NET Framework than just System.Windows.Forms and System.Windows.Controls. The idea is that a namespace is a logical grouping of types, as I said. All the types related to GDI+ drawing are in the System.Drawing namespace. All the types related to data access are in the System.Data namespace. All the types related to I/O are in the System.IO namespace. Etc, etc.

[RBARATA]

So, can I say that WPF apps are an evolution of WinForms apps (which were not dismissed)? An it seems the names were change too

I have found this "namespaces map", where is visible that some of the controls are common (exs, button, checkbox, listbox). Probably the properties available for editing in WPF are higher for each of these controls. Right?

[jmcilhinney]

WPF is not an evolution of WinForms. It is a completely new way to create Windows applications built from the ground up to overcome some of the limitations of WinForms and to support features desirable in modern apps. Given that WPF and WinForms are just two different ways to create Windows apps, why would it be a surprise that they both provides classes to create buttons, check boxes and list boxes? These are the sorts of things many Windows applications provide so any technology that creates Windows apps would be incomplete if it didn't provide such classes.

In fact, such features are not limited to Windows apps. Web applications would be all but useless if they didn't provide such features too, which is why the System.Web.UI.Controls namespace, which is dedicated to types related to ASP.NET Web Forms application development, also contains Button, CheckBox and ListBox classes.

Probably the properties available for editing in WPF are higher for each of these controls. Right?

I have no idea what you mean by that but, whatever it is, it's wrong. You're really trying to take something simple and make it difficult. WPF and WinForms are just two technologies that can both be used to create Windows applications. That's it. There's a namespace dedicated to the types used in each. Each of those namespaces contains the controls you can use to build a UI using that technology. The control classes in each namespace have the appropriate properties to configure those controls. That's it.

[RBARATA]

Ok, now it's clear. Sorry for the confusion but I always like to know, not only the hows, but also the whys.

One more request, if possible. Can you post a code of an application using WPF and WinForms? As far as I understood, it's possible to "call" different namespaces into your original application. I just want to compare the possibilities between WPF and WinForms.

Thank you

[Shaggy Hiker]

You are still missing something. Whenever we try to understand some concept, we build a mental model and try to fit everything into that model. As long as we can make it fit, however awkwardly, we stick with the mental model. Only when something totally doesn't fit do we tend to change the mental model. I would have to say, though, that the mental model you are working with for namespaces is totally wrong.

You seem to be working with a model where the namespace is somehow significant. That you can include or exclude namespaces as if that was even meaningful. If that sounds even vaguely like how you are picturing it, you should probably scrub out that part of your brain and start over on it.

Namespaces were introduces for one reason only: To prevent name collision.

When you get into object oriented programming (and to a lesser extent even before object oriented designs), you end up with lots of names for things. You make a bunch of objects, and these objects all have to have names. Most objects have one obvious name. For instance, a rectangular 3D area on a form that responds to a click is reasonably called a button. So, when you make such an object, you would normally call that object a Button. That's so obvious that Microsoft did indeed create an object that they called a Button. Now, if there were no namespaces, the fact that Microsoft had created an object called a Button would mean that nobody else could EVER call ANY object a Button, because the compiler would become confused as to which Button you meant.

By adding namespaces, you can distinguish one button from another. For instance, you could define a Your namespace, and a Her namespace. Now you can define an object called a Button in each namespace. There would be a Your.Button and a Her.Button. In both cases, you would be defining a class:

Public Class Button
End Class

And this would look the same. The namespace would just be added as a decoration onto the name 'Button' so that the compiler would know exactly WHICH definition of Button you are talking about. Therefore, the whole thing about namespaces is just a decoration onto a name so that the compiler can tell one object from another.

Therefore, WPF can have a Button object and WinForms can have a Button object. If that was all there was, the compiler would have no idea which button to create when you wrote:

Dim myButton As New Button

The compiler wouldn't know if that was the WPF button or the WinForm button (or even the ASP.NET button). There are only two possible ways to solve this problem. The first is that only one is called a button while the others are called something else, such as ASPButton and WPFButton. The other alternative is that the buttons be put into different namespaces. That does the very same thing, though, when you think about it. After all, rather than being WinButton, WPFButton, and ASPButton, you end up Windows.Forms.Button, Windows.Controls.Button, and ...uhh, I forget what namespace ASP uses. In any case, you can see that the two examples are pretty similar. Both examples use Button somewhere in them, though the former prepends some other word onto the front, while the latter prepends Windows.something. onto the end. If you can get over the fact that there are '.' in the name, you should see that they are actually the same thing: Just decorations on a name so that no two names are exactly the same. Therefore, you don't "call" a different namespace, because a namespace is just a decoration on a name to make it distinct.

[RBARATA]

Namespaces were introduces for one reason only: To prevent name collision.

I already understood that (as well as 99% of what yu wrote after that).

The compiler wouldn't know if that was the WPF button or the WinForm button (or even the ASP.NET button). There are only two possible ways to solve this problem. The first is that only one is called a button while the others are called something else, such as ASPButton and WPFButton. The other alternative is that the buttons be put into different namespaces. That does the very same thing, though, when you think about it. After all, rather than being WinButton, WPFButton, and ASPButton, you end up Windows.Forms.Button, Windows.Controls.Button, and ...uhh, I forget what namespace ASP uses. In any case, you can see that the two examples are pretty similar. Both examples use Button somewhere in them, though the former prepends some other word onto the front, while the latter prepends Windows.something. onto the end. If you can get over the fact that there are '.' in the name, you should see that they are actually the same thing: Just decorations on a name so that no two names are exactly the same. Therefore, you don't "call" a different namespace, because a namespace is just a decoration on a name to make it distinct.

This means that the WinButton, WPFButton, and ASPButton, all are the same button? Let me put my question in another way...the properties available for editingin WinButton are the same as in the WPFButton and ASPButton? Or not?

[Shaggy Hiker]

They are not all the same button. Each is a distinct object with a distinct definition. As it happens, they are all very similar. After all, a button is only going to react in certain ways (it gets clicked), and all will have some things in common such as a name and a location. However, they are not the same, and the set of properties contained in each is not necessarily the same. Furthermore, a property that exists in each and has the same name, may not necessarily do the same thing in each case....though they probably will be the same thing.

For one thing, you should expect that WPF will have LOTS more properties because you can do so many different visual things with a WPF control.

[RBARATA]

However, they are not the same, and the set of properties contained in each is not necessarily the same. Furthermore, a property that exists in each and has the same name, may not necessarily do the same thing in each case....though they probably will be the same thing.

So, basically, when working with object from different namespaces, one must know what each property means.

For one thing, you should expect that WPF will have LOTS more properties because you can do so many different visual things with a WPF control.

Exactly, that was what I was asking.

And, is it possible to include WPF objects in a WinForm app? If so, how can I do it?

[boops boops]

In theory you could add WPF object to windows forms projects if you reference the appropriate libraries. However, you can't add a System.Windows.Control to a Windows Form. The interfaces would be all wrong. I expect that would severely limit the usefulness of most WPF objects in a Forms project. Besides, WPF controls have Dependency Properties and Routed Events which which would be very hard to deal with in a Forms project. On the other hand, there are some Forms components (not controls) such as the OpenFileDialog which are usable in a WPF project.

Still, there are some practicable ways of integrating Forms and WPF. Firstly, you can use the Windows Forms ElementHost control to host a WPF UserControl on a Windows Form. The WPF UserControl can contain anything a WPF Window contains. However, everything will be confined to a single rectangle, and you will need to built the UserControl in WPF project anyway.

Secondly, you could make a hybrid solution with both a Forms project and a WPF project. It's not hard to make them interact. The "shaped form" CodeBank entry in my signature gives a very simple example of how you could do that. It's more a proof of concept than a useful code example, but it might give you some useful ideas.

There is a WPF control which can host a Form, but I haven't tried it. BB

[RBARATA]

Thank you for the replies. Now things ar more clear.