.net controls + longhorn?
-
Hi, i must admitt that i dont undestand s##t how the new longhorn stuff is going to work , so im hoping someone can help me understand this :) 1) this AVALON thing , is that the gui engine in longhorn? 2) is XAML a language that is intended to replace languages like c# , or what is the purpose of XAML? 3) can i code NON winforms controls in c# under longhorn? , meaning , if AVALON is a vectorbased gfx engine thinge , does it allow me to use c# to create custom controls for it? 4) is it correct that the XAML thinge is not the actual language , it is only indended to describe a UI , much like html , while i still use c# to make "codebehinds" , much like in asp.net but for winforms apps?? (and yes ive read the longhorn/win32 post in the lounge and i still dont get this) //Roger
-
Hi, i must admitt that i dont undestand s##t how the new longhorn stuff is going to work , so im hoping someone can help me understand this :) 1) this AVALON thing , is that the gui engine in longhorn? 2) is XAML a language that is intended to replace languages like c# , or what is the purpose of XAML? 3) can i code NON winforms controls in c# under longhorn? , meaning , if AVALON is a vectorbased gfx engine thinge , does it allow me to use c# to create custom controls for it? 4) is it correct that the XAML thinge is not the actual language , it is only indended to describe a UI , much like html , while i still use c# to make "codebehinds" , much like in asp.net but for winforms apps?? (and yes ive read the longhorn/win32 post in the lounge and i still dont get this) //Roger
1. MSDN describes Avalon as the "new Longhorn presentation subsystem." In other words, yeah, a new 3d-accelerated GUI engine specific to Longhorn. 2. XAML is not intended to replace any languages. XAML itself isn't a true programming language per se (example, you can't create functions, variables, etc.), it's very much like HTML and how it's used to describe web pages or XML and how it's used to describe relational data; they're all used to describe things, none of them actually perform things. In XAML's case, it will describe UI elements. 3. Yes, in addition to System.Windows.Forms.Controls, we'll also have the MSAvalon namespace. While I haven't read enough into the API to know if we can create custom Avalon controls in the traditional manner, we'll certainly be able to do custom controls by using a combo of MSAvalon and XAML. 4. XAML is a language, just like HTML or XML is. But yes, it's only intended to be used to describe UI elements, it can't be used by itself to create an app. MSDN describes typical Longhorn apps being comprised of your choice .Net language, like C#, with UI pages being written in XAML. Of course, we'll still have access to Windows Forms, but I'm guessing MS won't focus much on that. The graveyards are filled with indispensible men.
-
1. MSDN describes Avalon as the "new Longhorn presentation subsystem." In other words, yeah, a new 3d-accelerated GUI engine specific to Longhorn. 2. XAML is not intended to replace any languages. XAML itself isn't a true programming language per se (example, you can't create functions, variables, etc.), it's very much like HTML and how it's used to describe web pages or XML and how it's used to describe relational data; they're all used to describe things, none of them actually perform things. In XAML's case, it will describe UI elements. 3. Yes, in addition to System.Windows.Forms.Controls, we'll also have the MSAvalon namespace. While I haven't read enough into the API to know if we can create custom Avalon controls in the traditional manner, we'll certainly be able to do custom controls by using a combo of MSAvalon and XAML. 4. XAML is a language, just like HTML or XML is. But yes, it's only intended to be used to describe UI elements, it can't be used by itself to create an app. MSDN describes typical Longhorn apps being comprised of your choice .Net language, like C#, with UI pages being written in XAML. Of course, we'll still have access to Windows Forms, but I'm guessing MS won't focus much on that. The graveyards are filled with indispensible men.
Judah H. wrote: XAML is a language, just like HTML or XML is. But yes, it's only intended to be used to describe UI elements, it can't be used by itself to create an app. That is not entirely true, since you can inline C# or VB code in a XAML file. Of course, for intermediate to big real world applications you would not want to use a declarative language such as XAML.
-
Judah H. wrote: XAML is a language, just like HTML or XML is. But yes, it's only intended to be used to describe UI elements, it can't be used by itself to create an app. That is not entirely true, since you can inline C# or VB code in a XAML file. Of course, for intermediate to big real world applications you would not want to use a declarative language such as XAML.
apferreira wrote: since you can inline C# or VB code in a XAML file I guess you still need to compile the XAML file if it contained inline code whereas XAML in document format need not be compiled ?? :~ regards, Kannan
-
apferreira wrote: since you can inline C# or VB code in a XAML file I guess you still need to compile the XAML file if it contained inline code whereas XAML in document format need not be compiled ?? :~ regards, Kannan
Regarding your question, and quoting the Longhorn SDK[^] ...You can display pure "XAML" pages in a browser without compiling it. However, if your "XAML" page includes procedural code, you must compile the application before you can run it. "Avalon" cannot interpret uncompiled procedural code... Also, to make my earlier remarks clear: Another quote from the Longhorn SDK[^] Procedural code can be part of the "XAML" file or be within a separate code-behind file..."XAML" has a corresponding object model that allows you to do anything in procedural code that you can do with markup. In fact, when you build an "XAML" application, the markup parser converts the markup into equivalent object model-based code... And a quote from Don Box's blog[^] ...XAML is domain-neutral, so while it may be used to create desktop apps, web pages, and printable documents, it could also be used to create CRM apps, blogging backends, or highly concurrent web services provided you had a supporting CLR-based library to do the heavy lifting...