While I haven't been involved in every aspect of the design and history of XAML,
I thought you all might enjoy a bit of the history of how we got to where we are with
XAML...
An early debate on the Avalon team was about what our markup should look like. We
knew that we wanted a declarative UI model - it is actually something we have had
for a long time. The Avalon team was formed with members from all over the company
- User, IE, etc. And each team had a different history with markup. Obviously the
IE folks had used HTML and VML in the past, while the User folks had used RC files.
To add to the great debate there was also the new success of ASP.NET and their form
of markup.
After great debate, we decided that the programatic object model would be based on
.NET conventions. We also felt that the markup should have the same programming model
as code. Neither HTML nor RC files had this "markup == object model" tenet, and it
made programming difficult. ASP.NET had (basically) this model, and people seemed
to really like that.
Finally we decided that the markup should be a new format that was, in fact, a persistence
format for .NET objects. Thus, code like this:
Button b = new Button();
b.Text = "Hello";
b.Background = Colors.Red;
Would be transformed into:
<Button Text="Hello" Background="Red" />
Of course, that wasn't the end of the debates. Now of course, we had to decide on
the object model for our objects. Should we try to make the object model familiar
to Win32, HTML, WinForms, ASP.NET, or some other group of developers? There were various
camps, but after the success of .NET in 2001/2 it became increasingly obvious that
a WinForms/ASP.NET based object model would be the right thing for majority of developers.
Anyway, back to the markup...
The general rules for XAML go something like this:
Tag names are class names. The CLR namespace and assembly is discovered by an XML
namespace mapping scheme (more later).
XML Elements are mapped to CLR properties or events
Sub-elements of a tag can either be other class instances or "compound" properties (of
the form Type.PropertyName)
There are a few more advanced rules around the "Definition" namespace and Style.VisualTree,
but basically these three rules are it. Property values are converted from strings
in markup to code using TypeDescriptors (just like in ASP.NET). Rule #3 has some complications
to it - there are several ways that a child object gets attached to a parent (IAddChild,
IList, etc.).
There is a fourth rule:
4. The root tag of a markup file is the base type of the class the markup file defines.
Would define a new type called "Window1" that derives from "Window".
Here introduces one of our current debates - is XAML a programming language or a resource
format? With XAML you can define new types, define interactivity with "def:Code",
and specifiy member variables of the type using "ID". XAML also defines the UI appearance
of something, and is used for localization scenarios. XAML lacks any imperitive constructs
(branching, etc.). XAML is more of a "programming model" rather than a language, so
we have left it at that - "XAML is a declarative programming model".
In the PDC bits their are two modes of XAML compilation - binary (BAML) and code (CAML).
We are still working on analyising the two options - CAML works just like ASP.NET,
it converts XAML into code (VB.NET, C#, C++, any other CodeDOM language)... BAML uses
a binary format and also creates a small section of code for the parts of XAML that
can't be represented in binary (like the outer class definition). CAML is the default
in PDC bits, and you can use Optimization="Download" in the project file for getting
BAML.
This entry is turning into a bit of a rambling mess... more later...
This is first time I've heard anyone compare XAML to RC. When I first saw this I thought 'okay, so it's markup'. Still not convinced of it's worth over things like RC, WinForms, etc..
However, being able to use transforms to alter the gui seems like goodness to me. Don't ask what I'd use it for, 'cause I don't know. Just sounds like a good thing. :)
IMHO, XAML should stick to its role as data. The purpose of the XAML file from my viewpoint is to separate data from code, therefore why would we want to start putting code back into the XAML file? It seems to defeat the purpose. Why do def:code and def:class exist? Are they beneficial or just cool?
I think the CAML approach is excellent. The idea of using XAML to define the UI but then being able to debug through the generated code is an excellent blend between the VB6 way and the C# way.
+1 on Darrel. I'd also favour XAML only for UI design, because if you allow dev's to mixin code, they will, and thus will break the tire archetecture. If XAML only defines UI, it will also be much easier to transform to XUL, thus either opening an ISV oportunity or maybe you guys even decide to agree on a XAML subset which will be XUL compatabil.
It's a huge opportunity to maybe get everybody agree on a common schema to define UI.
Rick: One simple use is to transform to a subset of XAML for mobile devices or other plattforms. Imagine to take your desktop on your mobile or PDA.
Not sure there'll ever be XAML on mobile devices, but if not, sombody will comeup and just write a parser, nothing they can do against that :)
Gerald is so funny, let's give him a +2 for humorous troll!
BillSaysThis | http://www.billsaysthis.com
11/01/2003 11:55 AM
Hmm, with 95% desktop market share and 55% server market share, it's all the life I want to handle for the moment. :-)
BobSmith
11/01/2003 12:52 PM
I second Darrel Miller' opinion. XAML should be used to separate UI from code. Instead of def:code and def:class there should be a more powerful code binding mechanism for (dynamic) binding to compiled code behind. I've read the XAML articles on the MSDN Longhorn dev center and my understanding is that IE will not be able to load XAML directly if the XAML contains/references event handlers. Unless my understanding is not correct, that basically means that I cannot have XAML generated dynamically and loaded in IE if this XAML contains/references event handlers. This seems like a big limitation to me. With such limitation XAML is just RC (although more expressive and flexible) - if I need to generate on the fly UI that needs to handle events, I still need to do all the coding myself. Ideally, XAML will be used only for describing the UI and some simple behaviors for which coding will be an overkill (like "highlight this button on mouse enter", for example). A powerful code binding mechanism (ala XML Events) will ensure the seamless integration between XAML and code behind modules. Since rendering engines are not compilers, the code behind should always be compiled.
Does XAML separate content from style? Code like this makes me barf: Button b = new Button(); b.Text = "Hello"; b.Background = Colors.Red;
or
<Button Text="Hello" Background="Red" />
Have you not learned anything from CSS, HTML and the future direction of not using inline styles, but using CSS for look and feel(color, font, position ...) outside of the HTML document (or at least in the head)?
Yves Reynhout | http://weblogs.asp.net/yreynhout
11/01/2003 1:57 PM
I wasn't able to go to PDC, so possibly a dumb question... Can XAML for an application be dynamically (re)generated or retrieved from a data source? Can an application discover what its UI layout (in XAML) is after it had started?
Dimitri: For dynamically generated UI you can either using databinding and repeater controls (like listbox) or invoke the parser for XAML directly... either should accomplish what you are looking for here.
The more I read about XAML, the more frustrated I get. With XAML MS is going back to pre-Internet VB. The difference being that the old .frm file is now .xaml file. Unlike the old times, when developers were not supposed to edit the .frm file directly, the XAML file format will be well documented and therefore it will be possible to edit XAML files with a text editor. And while in pre-Internet VB there was a clear separation between UI and the code behind, developers are now empowered to embed code in the form file (aka as XAML file). Just like old VB, dynamic UI generation is not possible, since XAML is actually not used for rendering. XAML is essentially a template language for source code generation. Instead of creating an advanced rendering engine and an application framework that will really show how pathetic it is to develop applications with HTML/JavaScript, MS came up with yet another language for creating VB applications.
George: I'm not sure why dynamic UI generation would be hindered here. Are you refering to dynamically generating a projection UI experience (ala HTML, with generation occuring on the server and the client being a dumb rendering engine) or something else?
In Avalon you can dynamically create elements, you can databinding, repeat, templatize, etc... all of this should produce the most dynamic experience that you have seen to date. However, yes, we are not focused on *projection* UI as the solution. Right now we are focusing on producing a rich client client solution that leverages the power of the PC to dynamically generate the UI on the client.
Chris: I concerned about the following. Let's say that as a result of some application event I need to display a dialog box. The layout and the number of controls on this dialog box depend on some runtime condition. Is it possible to generate a XAML sccript for this dialog box at runtime (by doing simpler string concatenations)? The dialog box should be able to handle events, like OnOK, for example. This is now possile with IE 6.0 and HTML.
Chris, as part of the layout model explanation, can you please also clarify if XAML files need to be compiled in order to be rendered. And if the answer is yes, why is it a better idea to generate application UI code (CAML or BAML) instead of rendering the UI at runtime with a rendering engine (provided that the UI markup does not contain any embedded code but does reference code behind). And finally, will my Avalon rich client application be able to render (and handle events from) UI forms generated with XSLT/XQuery transformations on data coming from a remote server at runtime.
What was the reasoning for not making the UI elements extend XmlElement? Since XAML is supposed to be an XML language it would seem obvious that one should be able to use the W3C DOM.
Did you ever conisder to create a general XML+CSS rendering engine and use CSS/RCC to do the styling for the UI controls?
Erik: Check out my later posting about XAML and CSS to address your second question. As for your first question - we did think about that, but the programming model would have been onerous - i'll write something up about this exact debate later today.
Excuse me if none of this makes sense. I am a novice programmer learning the world of .Net. From my limited experiences with asp.net, I think code and UI should be seperate entities joined by a common listener. This allows your artists to create the forms/ui and the programmers to create the logic. The UI created by the artist would be stored the UI structure (think of a house frame) in an XML format. The "look" would be stored in a CCS file. If this is confusing...I am sorry. Just thought I would throw my 2 cents out...as well as start my way into the programming community.
+100 for Yves!!! Really the quesiton should be, has the WinForms team learned nothing from the fact that programmmers are extremely productive with XHTML and CSS even for all of its shortcomings. If I want a font, I should be able to use XHTML. If I want a crosstab, OK, I need a f*cking widget.
While the debaters of XAML vs XUL make interesting claims for innovation, there is a preexisting standard for this kind of UI. Developed in the early nineties by a US Navy sponsored team, it was developed over SGML/HyTime, the standards of their day, but had significant inspiration from the Windows 3.1 resource file. It still exists as an ISO standard called ISMID.
1. The fact of several different groups coming up with the same invention independently means XAML passes Tim Berners-Lee's principle of independent invention. That's good. The MID team was working on IETMs and needed to separate behavior from presentation. Having similar requirements led to similar solutions.
2. Now that even Tim Bray is on record as stating that standards should follow commercial development, not drive it, there is a case to be made for modernizing ISMID to meet the requirements of soon to be fielded advanced client applications. This isn't a hard sell unless people want to be hard headed or stick to NIH and other Spy Vs Spy arguments which are almost guaranteed to create a bad perception of the new UI languages.
ISO standards come up for revision. A forward looking group that needs to develop while working to ensure international standards are in accordance with that development would do well to consider modernizing ISMID to meet XML requirements.
Of course, if XAML isn't a conforming XML application language, this doesn't work. If it is, then the experience of the X3D community (formerly VRML) indicates that ISO can be extremely cooperative.
***************************************** "The ISMID architecture includes:
Interface objects;
Container objects that are used to group other interface objects (e.g., Windows, Frames, Panels);
Content objects that are used to render specific information content (e.g., Video, Image, Audio, Animation, Text);
Control objects through which interaction with the MID takes place (e.g., Button, Scroll Bar, List Box, Check Box). Control objects enable users to make decisions and facilitate navigation through a MID instance;
External objects are used to allow the MID to communicate with external systems such as the computer operating environment or a diagnostic system.
Stimuli, which are actions received via the interface objects; and
Responses, which are reactions performed by the MID in response to a given stimulus."
Is Avalon/XAML going to solve my #1 pet peeve with winforms? In HTML/CSS land nearly every control supports the same 100+ visual properties (borderColor, overflow, cursor, fontWeight, etc...). It could be a Div tag, a P tag, doesn't matter. In winforms it's every control for themselves. Hell, in winforms you cannot even change borderStyle (etched, dashed, dotted) or borderColor without overriding OnPaint. Please tell me you folks are working on this.
A brief history of XAML
While I haven't been involved in every aspect of the design and history of XAML, I thought you all might enjoy a bit of the history of how we got to where we are with XAML...
An early debate on the Avalon team was about what our markup should look like. We knew that we wanted a declarative UI model - it is actually something we have had for a long time. The Avalon team was formed with members from all over the company - User, IE, etc. And each team had a different history with markup. Obviously the IE folks had used HTML and VML in the past, while the User folks had used RC files. To add to the great debate there was also the new success of ASP.NET and their form of markup.
After great debate, we decided that the programatic object model would be based on .NET conventions. We also felt that the markup should have the same programming model as code. Neither HTML nor RC files had this "markup == object model" tenet, and it made programming difficult. ASP.NET had (basically) this model, and people seemed to really like that.
Finally we decided that the markup should be a new format that was, in fact, a persistence format for .NET objects. Thus, code like this:
Button b = new Button();
b.Text = "Hello";
b.Background = Colors.Red;
Would be transformed into:
<Button Text="Hello" Background="Red" />
Of course, that wasn't the end of the debates. Now of course, we had to decide on the object model for our objects. Should we try to make the object model familiar to Win32, HTML, WinForms, ASP.NET, or some other group of developers? There were various camps, but after the success of .NET in 2001/2 it became increasingly obvious that a WinForms/ASP.NET based object model would be the right thing for majority of developers.
Anyway, back to the markup...
The general rules for XAML go something like this:
There are a few more advanced rules around the "Definition" namespace and Style.VisualTree, but basically these three rules are it. Property values are converted from strings in markup to code using TypeDescriptors (just like in ASP.NET). Rule #3 has some complications to it - there are several ways that a child object gets attached to a parent (IAddChild, IList, etc.).
There is a fourth rule:
4. The root tag of a markup file is the base type of the class the markup file defines.
Thus a file like this:
<Window xmlns="..." xmlns:def="..." def:Class="Window1">
<Button>Hello</Button>
</Window>
Would define a new type called "Window1" that derives from "Window".
Here introduces one of our current debates - is XAML a programming language or a resource format? With XAML you can define new types, define interactivity with "def:Code", and specifiy member variables of the type using "ID". XAML also defines the UI appearance of something, and is used for localization scenarios. XAML lacks any imperitive constructs (branching, etc.). XAML is more of a "programming model" rather than a language, so we have left it at that - "XAML is a declarative programming model".
In the PDC bits their are two modes of XAML compilation - binary (BAML) and code (CAML). We are still working on analyising the two options - CAML works just like ASP.NET, it converts XAML into code (VB.NET, C#, C++, any other CodeDOM language)... BAML uses a binary format and also creates a small section of code for the parts of XAML that can't be represented in binary (like the outer class definition). CAML is the default in PDC bits, and you can use Optimization="Download" in the project file for getting BAML.
This entry is turning into a bit of a rambling mess... more later...
9:53 PM | #Longhorn
10/31/2003 10:48 PM
This is first time I've heard anyone compare XAML to RC. When I first saw this I thought 'okay, so it's markup'. Still not convinced of it's worth over things like RC, WinForms, etc..However, being able to use transforms to alter the gui seems like goodness to me. Don't ask what I'd use it for, 'cause I don't know. Just sounds like a good thing. :)
Rick Childress | mailto:r dot childressAT NOSPAM(NoMoreSpanishSpam)comcast dot net | r dot childressAT NOSPAM(NoMoreSpanishSpam)comcast dot net
11/01/2003 6:02 AM
IMHO, XAML should stick to its role as data. The purpose of the XAML file from my viewpoint is to separate data from code, therefore why would we want to start putting code back into the XAML file? It seems to defeat the purpose.Why do def:code and def:class exist? Are they beneficial or just cool?
I think the CAML approach is excellent. The idea of using XAML to define the UI but then being able to debug through the generated code is an excellent blend between the VB6 way and the C# way.
Darrel Miller | mailto:darrelAT NOSPAMtavis dot ca | darrelAT NOSPAMtavis dot ca
11/01/2003 7:37 AM
+1 on Darrel. I'd also favour XAML only for UI design, because if you allow dev's to mixin code, they will, and thus will break the tire archetecture. If XAML only defines UI, it will also be much easier to transform to XUL, thus either opening an ISV oportunity or maybe you guys even decide to agree on a XAML subset which will be XUL compatabil.It's a huge opportunity to maybe get everybody agree on a common schema to define UI.
Rick: One simple use is to transform to a subset of XAML for mobile devices or other plattforms. Imagine to take your desktop on your mobile or PDA.
Not sure there'll ever be XAML on mobile devices, but if not, sombody will comeup and just write a parser, nothing they can do against that :)
Benjamin J. J. Voigt | http://www.shamiro.ch | egalAT NOSPAMicu dot unizh dot ch
11/01/2003 10:07 AM
What a self-centric kindergarden. Have you guys realized there's life beyond Windows?Gerald Bauer | http://xul.sourceforge.net | geraldAT NOSPAMvamphq dot com
11/01/2003 10:09 AM
Gerald is so funny, let's give him a +2 for humorous troll!BillSaysThis | http://www.billsaysthis.com
11/01/2003 11:55 AM
Hmm, with 95% desktop market share and 55% server market share, it's all the life I want to handle for the moment. :-)BobSmith
11/01/2003 12:52 PM
I second Darrel Miller' opinion. XAML should be used to separate UI from code. Instead of def:code and def:class there should be a more powerful code binding mechanism for (dynamic) binding to compiled code behind.
I've read the XAML articles on the MSDN Longhorn dev center and my understanding is that IE will not be able to load XAML directly if the XAML contains/references event handlers. Unless my understanding is not correct, that basically means that I cannot have XAML generated dynamically and loaded in IE if this XAML contains/references event handlers. This seems like a big limitation to me. With such limitation XAML is just RC (although more expressive and flexible) - if I need to generate on the fly UI that needs to handle events, I still need to do all the coding myself.
Ideally, XAML will be used only for describing the UI and some simple behaviors for which coding will be an overkill (like "highlight this button on mouse enter", for example). A powerful code binding mechanism (ala XML Events) will ensure the seamless integration between XAML and code behind modules. Since rendering engines are not compilers, the code behind should always be compiled.
George Mladenov | mailto:mladenovAT NOSPAMpacbell dot net | mladenovAT NOSPAMpacbell dot net
11/01/2003 1:39 PM
Does XAML separate content from style? Code like this makes me barf:Button b = new Button();
b.Text = "Hello";
b.Background = Colors.Red;
or
<Button Text="Hello" Background="Red" />
Have you not learned anything from CSS, HTML and the future direction of not using inline styles, but using CSS for look and feel(color, font, position ...) outside of the HTML document (or at least in the head)?
Yves Reynhout | http://weblogs.asp.net/yreynhout
11/01/2003 1:57 PM
I wasn't able to go to PDC, so possibly a dumb question... Can XAML for an application be dynamically (re)generated or retrieved from a data source? Can an application discover what its UI layout (in XAML) is after it had started?Dimitri Glazkov | mailto:dimitriAT NOSPAMglazkov dot com | dimitriAT NOSPAMglazkov dot com
11/01/2003 2:45 PM
Dimitri: For dynamically generated UI you can either using databinding and repeater controls (like listbox) or invoke the parser for XAML directly... either should accomplish what you are looking for here.chris anderson | http://www.simplegeek.com | chris_l_andersonAT NOSPAMhotmail dot com
11/01/2003 3:15 PM
The more I read about XAML, the more frustrated I get. With XAML MS is going back to pre-Internet VB. The difference being that the old .frm file is now .xaml file. Unlike the old times, when developers were not supposed to edit the .frm file directly, the XAML file format will be well documented and therefore it will be possible to edit XAML files with a text editor. And while in pre-Internet VB there was a clear separation between UI and the code behind, developers are now empowered to embed code in the form file (aka as XAML file). Just like old VB, dynamic UI generation is not possible, since XAML is actually not used for rendering. XAML is essentially a template language for source code generation.
Instead of creating an advanced rendering engine and an application framework that will really show how pathetic it is to develop applications with HTML/JavaScript, MS came up with yet another language for creating VB applications.
George Mladenov | mailto:mladenovAT NOSPAMpacbell dot net | mladenovAT NOSPAMpacbell dot net
11/01/2003 3:24 PM
George: I'm not sure why dynamic UI generation would be hindered here. Are you refering to dynamically generating a projection UI experience (ala HTML, with generation occuring on the server and the client being a dumb rendering engine) or something else?In Avalon you can dynamically create elements, you can databinding, repeat, templatize, etc... all of this should produce the most dynamic experience that you have seen to date. However, yes, we are not focused on *projection* UI as the solution. Right now we are focusing on producing a rich client client solution that leverages the power of the PC to dynamically generate the UI on the client.
chris anderson | http://www.simplegeek.com | chris_l_andersonAT NOSPAMhotmail dot com
11/01/2003 3:52 PM
Chris: I concerned about the following. Let's say that as a result of some application event I need to display a dialog box. The layout and the number of controls on this dialog box depend on some runtime condition. Is it possible to generate a XAML sccript for this dialog box at runtime (by doing simpler string concatenations)? The dialog box should be able to handle events, like OnOK, for example. This is now possile with IE 6.0 and HTML.George Mladenov | mailto:mladenovAT NOSPAMpacbell dot net | mladenovAT NOSPAMpacbell dot net
11/01/2003 5:42 PM
George: Yes, easily accomplished with our layout model... i'll write about it later this weekend...chris anderson | http://www.simplegeek.com | chris_l_andersonAT NOSPAMhotmail dot com
11/02/2003 2:09 AM
Chris, as part of the layout model explanation, can you please also clarify if XAML files need to be compiled in order to be rendered. And if the answer is yes, why is it a better idea to generate application UI code (CAML or BAML) instead of rendering the UI at runtime with a rendering engine (provided that the UI markup does not contain any embedded code but does reference code behind). And finally, will my Avalon rich client application be able to render (and handle events from) UI forms generated with XSLT/XQuery transformations on data coming from a remote server at runtime.
George Mladenov | mailto:mladenovAT NOSPAMpacbell dot net | mladenovAT NOSPAMpacbell dot net
11/03/2003 7:51 AM
What was the reasoning for not making the UI elements extend XmlElement? Since XAML is supposed to be an XML language it would seem obvious that one should be able to use the W3C DOM.Did you ever conisder to create a general XML+CSS rendering engine and use CSS/RCC to do the styling for the UI controls?
Erik Arvidsson | http://erik.eae.net | erikAT NOSPAMeae dot net
11/03/2003 8:14 AM
Erik: Check out my later posting about XAML and CSS to address your second question. As for your first question - we did think about that, but the programming model would have been onerous - i'll write something up about this exact debate later today.Chris Anderson | http://www.simplegeek.com | chris_l_andersonAT NOSPAMhotmail dot com
11/04/2003 11:02 AM
I'm pretty familiar w/ CSS, but what's RCC?Nick Kramer | mailto:n kramer 5 1 2 at msn | n kramer 5 1 2 at msn
11/05/2003 8:52 AM
Excuse me if none of this makes sense.I am a novice programmer learning the world of .Net. From my limited experiences with asp.net, I think code and UI should be seperate entities joined by a common listener. This allows your artists to create the forms/ui and the programmers to create the logic. The UI created by the artist would be stored the UI structure (think of a house frame) in an XML format. The "look" would be stored in a CCS file. If this is confusing...I am sorry. Just thought I would throw my 2 cents out...as well as start my way into the programming community.
Jerry Aunspaw | mailto:JerryDotAunspawAtHotMailDotCom | JerryDotAunspawAtHotMailDotCom
11/05/2003 11:14 PM
+100 for Yves!!! Really the quesiton should be, has the WinForms team learned nothing from the fact that programmmers are extremely productive with XHTML and CSS even for all of its shortcomings. If I want a font, I should be able to use XHTML. If I want a crosstab, OK, I need a f*cking widget.Terris Linenbach | terris.com | terrisAT NOSPAMterris dot com
11/06/2003 8:10 PM
To talk about history of XAML with no mention of NetDocs and markup story is, well, a bit scandalous ;)..Michael Murray | mailto:mimurrayAT NOSPAMmicrosoft dot com | mimurrayAT NOSPAMmicrosoft dot com
11/10/2003 11:23 AM
11/11/2003 7:42 AM
While the debaters of XAML vs XUL make interesting claims for innovation, there is a preexisting standard for this kind of UI. Developed in the early nineties by a US Navy sponsored team, it was developed over SGML/HyTime, the standards of their day, but had significant inspiration from the Windows 3.1 resource file. It still exists as an ISO standard called ISMID.http://www.y12.doe.gov/sgml/sc34/document/0201.htm
1. The fact of several different groups coming up with the same invention independently means XAML passes Tim Berners-Lee's principle of independent
invention. That's good. The MID team was working on IETMs and needed to separate behavior from presentation. Having similar requirements led to similar solutions.
2. Now that even Tim Bray is on record as stating that standards should follow commercial development, not drive it, there is a case to be made for modernizing ISMID to meet the requirements of soon to be fielded advanced client applications. This isn't a hard sell unless people want to be hard headed or stick to NIH and other Spy Vs Spy arguments which are almost guaranteed to create a bad perception of the new UI languages.
ISO standards come up for revision. A forward looking group that needs to develop while working to ensure international standards are in accordance with that development would do well to consider modernizing ISMID to meet XML requirements.
Of course, if XAML isn't a conforming XML application language, this doesn't work. If it is, then the experience of the X3D community (formerly VRML) indicates that ISO can be extremely cooperative.
*****************************************
"The ISMID architecture includes:
Interface objects;
Container objects that are used to group other interface objects (e.g., Windows, Frames, Panels);
Content objects that are used to render specific information content (e.g., Video, Image, Audio, Animation, Text);
Control objects through which interaction with the MID takes place (e.g., Button, Scroll Bar, List Box, Check Box). Control objects enable users to make decisions and facilitate navigation through a MID instance;
External objects are used to allow the MID to communicate with external systems such as the computer operating environment or a diagnostic system.
Stimuli, which are actions received via the interface objects; and
Responses, which are reactions performed by the MID in response to a given stimulus."
Len Bullard | mailto:clbullarAT NOSPAMingr dot com | clbullarAT NOSPAMingr dot com
12/04/2003 3:29 PM
Is Avalon/XAML going to solve my #1 pet peeve with winforms? In HTML/CSS land nearly every control supports the same 100+ visual properties (borderColor, overflow, cursor, fontWeight, etc...). It could be a Div tag, a P tag, doesn't matter. In winforms it's every control for themselves. Hell, in winforms you cannot even change borderStyle (etched, dashed, dotted) or borderColor without overriding OnPaint. Please tell me you folks are working on this.Brian R. James | mailto:brianAT NOSPAMdigitalmarble dot com | brianAT NOSPAMdigitalmarble dot com
05/26/2004 3:35 AM
www.casino-online-on-line.comwww.casino-online-on-line.com | www.casino-online-on-line.com | www dot casino-online-on-line dot com
05/26/2004 3:35 AM
05/26/2004 4:45 AM
www.casino-online-on-line.comwww.casino-online-on-line.com | www.casino-online-on-line.com | www dot casino-online-on-line dot com
05/26/2004 4:45 AM
05/26/2004 5:17 AM
www.casino-online-on-line.comwww.casino-online-on-line.com | www.casino-online-on-line.com | www dot casino-online-on-line dot com
05/26/2004 5:17 AM
07/09/2005 11:54 PM
tomtums | 123456 | tomAT NOSPAMyahoo dot com
08/30/2005 2:39 AM
There are some disputable moments in your article. I do not absolutelyagree with the author.
siding contractor philadelphia | url: http://northeastunion.com/CommercialRoofing | sidingAT NOSPAMukr dot net
11/27/2005 2:50 PM
order cialis save up to 80order cialis | http://ordercialis.cutezone.com/ | cAT NOSPAMyahoo dot com
06/04/2006 11:42 AM
wow !cheap tramadol | http://mysite.com.ua/xdem8264/pagesxdem8264/1_1.html | box3eyrAT NOSPAMukr dot net