The first release of MCMLookalike is done. I threw the project and installer together in around about 45 minues (not counting the 'controls.mcml' file), so I hope there are no GLARING errors in the code.
If you are an MCML developer, take a look. It's a basic program using a couple of simple pre-defined controls. It also includes a template installer you can use to distribute your program.
http://www.sourceforge.net/projects/mcmlookalike
Showing posts with label MCE. Show all posts
Showing posts with label MCE. Show all posts
Monday, February 19, 2007
Wednesday, February 7, 2007
Navigating - and Another MCMLPad Warning
There's another minor bug/issue in MCMLPad - something you should be aware of once you start doing more advanced development.
To navigste from 'page' to 'page' (eg. between UI's) you can use the <Navigate> action within any Rule.
The only required member of this tag is URI - the address to the next page. Most frequently, this will be a link to an MCML file that you have enclosed in a resource (usually the same DLL that contains your .NET application).
You can also pass objects in this Navigate tag. Since Navigate opens another UI as the main interface, you pass objects to this new UI exactly the same way that you do between UI's in a single interface - by passing them as properties.
So, for example, you can create a property on the base-UI in 'Page2.mcml', and set it with the Navigate tag in 'Page1.mcml'. This is how you can continue to pass information between pages and propagate information through your entire application.
ONE WORD OF WARNING: MCMPad has a small glitch (I hesistate to call it a 'bug', but it IS annoying) where pressing F5 to refresh the page will NOT work correctly for any page that has been passed a property. The property will not be re-sent, which means that any strings will be reset to empty and any objects will be set to 'null', which will normally mean that MCMLPad will close with an exception.
To navigste from 'page' to 'page' (eg. between UI's) you can use the <Navigate> action within any Rule.
The only required member of this tag is URI - the address to the next page. Most frequently, this will be a link to an MCML file that you have enclosed in a resource (usually the same DLL that contains your .NET application).
You can also pass objects in this Navigate tag. Since Navigate opens another UI as the main interface, you pass objects to this new UI exactly the same way that you do between UI's in a single interface - by passing them as properties.
So, for example, you can create a property on the base-UI in 'Page2.mcml', and set it with the Navigate tag in 'Page1.mcml'. This is how you can continue to pass information between pages and propagate information through your entire application.
ONE WORD OF WARNING: MCMPad has a small glitch (I hesistate to call it a 'bug', but it IS annoying) where pressing F5 to refresh the page will NOT work correctly for any page that has been passed a property. The property will not be re-sent, which means that any strings will be reset to empty and any objects will be set to 'null', which will normally mean that MCMLPad will close with an exception.
Monday, February 5, 2007
Input Handling
Welcome back for another blog entry.
Today we have a quick tip on input handling (and playing with .NET variables) in your MCML interfaces.
Every object in your MCML interface has an Input object associated with it. This is what allows you to find out if the item has mouse or keyboard focus. It ALSO lets you control how that focus works.
To tell if the mouse is hovering over an object, you need to check the [Input.MouseFocus] property. Since every object has it's own 'Input' object, the properties of Input will always refer to this object only (or it's children, if you are using DeepFocus).
<UI Name = "Selectable">
<Rules>
<Condition Target="[Input.MouseFocus] Value="true"\>
<Actions>
<Set Target=[TextObject.Color]" Value="Red"\>
</Actions>
</Condition>
<\Rules>
<Content>
<Text Content="Push Me" Color="White" Name="TextObject"\>
<\Content>
<\UI>
The trick to using their advanced properties is simple, but can throw you if you are new to MCML. Objects like Input are NOT actually XML tags, despite the fact that in the documentation they are shown as XML. Instead, they are .NET objects, and you set the properties of the Input object through the Default tag of your Rules object.
For example, we can mark a panel as being able to receive focus with the KeyInteractive property.
<UI Name = "Selectable>
<Rules>
<Default Target="[Input. KeyInteractive] Value="true"\>
<\Rules>
<Content>
<Text Content="Push Me"\>
<\Content>
<\UI>
This creates a text object that you can navigate to with you remote/keyboard.
One more hint - MCML's default is that a mouse-focus event always fired off a matching key-focus event. Sometimes, this just isn't right.
For example, in the AreaBar (the pivot bar, or the blue list of sorting options that appears in most genuine Media Center screens), you find that when you navigate by key-press or remote, you automatically select the next area/option that you navigate to.
When using a MOUSE, you only HIGHLIGHT it. You have to click the mouse button to select the option.
However, the default behaviour for Media Center is to automatically set 'KeyFocus' to true every time 'MouseFocus' is. This sort of thing is great for regular buttons, but isn't effective for this particular control.
So to emulate this behavior, you need to use
<Rules>
<Default Target="[Input. KeyFocusOnMouseEnter] Value="false"\>
<\Rules>
This prevents [Input.KeyFocus] from being true every time that [Input.MouseFocus] is.
Today we have a quick tip on input handling (and playing with .NET variables) in your MCML interfaces.
Every object in your MCML interface has an Input object associated with it. This is what allows you to find out if the item has mouse or keyboard focus. It ALSO lets you control how that focus works.
To tell if the mouse is hovering over an object, you need to check the [Input.MouseFocus] property. Since every object has it's own 'Input' object, the properties of Input will always refer to this object only (or it's children, if you are using DeepFocus).
<UI Name = "Selectable">
<Rules>
<Condition Target="[Input.MouseFocus] Value="true"\>
<Actions>
<Set Target=[TextObject.Color]" Value="Red"\>
</Actions>
</Condition>
<\Rules>
<Content>
<Text Content="Push Me" Color="White" Name="TextObject"\>
<\Content>
<\UI>
The trick to using their advanced properties is simple, but can throw you if you are new to MCML. Objects like Input are NOT actually XML tags, despite the fact that in the documentation they are shown as XML. Instead, they are .NET objects, and you set the properties of the Input object through the Default tag of your Rules object.
For example, we can mark a panel as being able to receive focus with the KeyInteractive property.
<UI Name = "Selectable>
<Rules>
<Default Target="[Input. KeyInteractive] Value="true"\>
<\Rules>
<Content>
<Text Content="Push Me"\>
<\Content>
<\UI>
This creates a text object that you can navigate to with you remote/keyboard.
One more hint - MCML's default is that a mouse-focus event always fired off a matching key-focus event. Sometimes, this just isn't right.
For example, in the AreaBar (the pivot bar, or the blue list of sorting options that appears in most genuine Media Center screens), you find that when you navigate by key-press or remote, you automatically select the next area/option that you navigate to.
When using a MOUSE, you only HIGHLIGHT it. You have to click the mouse button to select the option.
However, the default behaviour for Media Center is to automatically set 'KeyFocus' to true every time 'MouseFocus' is. This sort of thing is great for regular buttons, but isn't effective for this particular control.
So to emulate this behavior, you need to use
<Rules>
<Default Target="[Input. KeyFocusOnMouseEnter] Value="false"\>
<\Rules>
This prevents [Input.KeyFocus] from being true every time that [Input.MouseFocus] is.
Wednesday, January 31, 2007
Tips & Tricks: 'Global' Variables
A quick word for the wise when it comes to MCML and your variables.
As much as you would like every UI to be it's own completely autonomous control, there are times when you need real feedback from your UI's.
This can actually be quite a problem, since a UI can not talk to it's parent.
So what is the trick? It's actually not too difficult, but for the newbie it can be very confusing.
We have already introduced properties, allowing you to set the attributes of the UI's you are creating. As well as properties, we have locals. These are in a very similar form to properties, with the only real difference being that you can't tell a UI what it's locals should be.
The trick is to take one of your local variables and basically just 'pass it on' as properties to all other objects that need access to it.
BUT - and here's the trick - you need to be aware of what TYPE of property you are using. This is because the variables work differently depending on what type you use.
If you use an object from the cor: namespace (such as cor:String, cor:Int32, cor:Boolean etc.) then you have created a simple type, like 'int' or 'long' in C. If you pass simple objects to a UI, it gets it's own new copy of the variable, meaning that if you change the value in any of your sub-items, the change will only effect THAT ITEM.
However, if you use something more complicated, a CLASS like EditableText for instance, every UI that is sent it as a property gets a reference to the object. This means that when you change a value in ANY of the UI's you have passed it to, it will be changed for ALL UI's.
<UI Name="MainUI">
<Locals>
<cor:String Name="Brand" cor:string="My Brand">
<EditableText Name="Area" EditableText="None">
</Locals>
<Content>
<Panel Layout="VerticalFlow">
<Children>
<Text Name="BrandName" Color="White" Font="Tahoma,20"/>
<Text Name="AreaName" Color="White" Font="Tahoma,20"/>
<me:BrandedOption BrandVar="[Brand]" AreaName="Option #1" BrandName="ACME" AreaVar="[Area]"/>
<me:BrandedOption BrandVar="[Brand]" AreaName="Option #2" BrandName="Someone Else" AreaVar="[Area]"/>
</Children>
</Panel>
</Content>
<Rules>
<Binding Source="Brand" Target="BrandName.Content">
<Binding Source="Area" Target="AreaName.Content">
</Rules>
</UI>
<UI Name="BrandedOption">
<Properties>
<cor:String Name="BrandVar" cor:string="$Required">
<cor:String Name="BrandName" cor:string="$Required">
<EditableText Name="AreaVar" EditableText="$Required">
<cor:String Name="AreaName" cor:string="$Required">
</Properties>
<Content>
<Panel Layout="HorizontalFlow">
<Children>
<Text Name="ButtonArea" Color="Red" Font="Arial,20" Content="[AreaName]"/>
<Text Name="ButtonBrand" Color="Red" Font="Arial,20" Content="[BrandName]"/>
</Children>
</Panel>
</Content>
<Rules>
<Condition Source="[Input.MouseFocus]" SourceValue="true">
<Actions>
<Set Target="[BrandVar]" Value="[BrandName]">
<Set Target="[AreaVar]" Value="[AreaName]">
</Actions>
</Condition>
</Rules>
</UI>
I haven't actually TESTED this UI (although I do something similar in my existing MCML) but that will give you the basic outline.
What we have is an interface that has two text boxes in white, giving you the current brand name setting, and the current area name setting. These are constantly updated with the rule we have specified, which makes sure the value of 'Area' and 'Brand' are copied into the text controls whenever the values are updated.
There are also two buttons. Each button has two text elements, the brand and the area/type of a product (set with the AreaName and BrandName properties) and the button is also passed our global Brand and Area variables through the AreaVal and BrandVal.
In the buttons, we have a rule that says that whenever the object is given mouse focus (Input.MouseFocus = true) then we are to set the AreaVal and BrandVal properties to AreaName and BrandName (the names displayed on the button).
What you should find when you do this is that when you roll over a button, the AREA will change, but the BRAND will not. This is because of the rules I explained earlier.
So now you know how to share a variable through your entire UI. This will come in handy in the next project discussed.
As much as you would like every UI to be it's own completely autonomous control, there are times when you need real feedback from your UI's.
This can actually be quite a problem, since a UI can not talk to it's parent.
So what is the trick? It's actually not too difficult, but for the newbie it can be very confusing.
We have already introduced properties, allowing you to set the attributes of the UI's you are creating. As well as properties, we have locals. These are in a very similar form to properties, with the only real difference being that you can't tell a UI what it's locals should be.
The trick is to take one of your local variables and basically just 'pass it on' as properties to all other objects that need access to it.
BUT - and here's the trick - you need to be aware of what TYPE of property you are using. This is because the variables work differently depending on what type you use.
If you use an object from the cor: namespace (such as cor:String, cor:Int32, cor:Boolean etc.) then you have created a simple type, like 'int' or 'long' in C. If you pass simple objects to a UI, it gets it's own new copy of the variable, meaning that if you change the value in any of your sub-items, the change will only effect THAT ITEM.
However, if you use something more complicated, a CLASS like EditableText for instance, every UI that is sent it as a property gets a reference to the object. This means that when you change a value in ANY of the UI's you have passed it to, it will be changed for ALL UI's.
<UI Name="MainUI">
<Locals>
<cor:String Name="Brand" cor:string="My Brand">
<EditableText Name="Area" EditableText="None">
</Locals>
<Content>
<Panel Layout="VerticalFlow">
<Children>
<Text Name="BrandName" Color="White" Font="Tahoma,20"/>
<Text Name="AreaName" Color="White" Font="Tahoma,20"/>
<me:BrandedOption BrandVar="[Brand]" AreaName="Option #1" BrandName="ACME" AreaVar="[Area]"/>
<me:BrandedOption BrandVar="[Brand]" AreaName="Option #2" BrandName="Someone Else" AreaVar="[Area]"/>
</Children>
</Panel>
</Content>
<Rules>
<Binding Source="Brand" Target="BrandName.Content">
<Binding Source="Area" Target="AreaName.Content">
</Rules>
</UI>
<UI Name="BrandedOption">
<Properties>
<cor:String Name="BrandVar" cor:string="$Required">
<cor:String Name="BrandName" cor:string="$Required">
<EditableText Name="AreaVar" EditableText="$Required">
<cor:String Name="AreaName" cor:string="$Required">
</Properties>
<Content>
<Panel Layout="HorizontalFlow">
<Children>
<Text Name="ButtonArea" Color="Red" Font="Arial,20" Content="[AreaName]"/>
<Text Name="ButtonBrand" Color="Red" Font="Arial,20" Content="[BrandName]"/>
</Children>
</Panel>
</Content>
<Rules>
<Condition Source="[Input.MouseFocus]" SourceValue="true">
<Actions>
<Set Target="[BrandVar]" Value="[BrandName]">
<Set Target="[AreaVar]" Value="[AreaName]">
</Actions>
</Condition>
</Rules>
</UI>
I haven't actually TESTED this UI (although I do something similar in my existing MCML) but that will give you the basic outline.
What we have is an interface that has two text boxes in white, giving you the current brand name setting, and the current area name setting. These are constantly updated with the rule we have specified, which makes sure the value of 'Area' and 'Brand' are copied into the text controls whenever the values are updated.
There are also two buttons. Each button has two text elements, the brand and the area/type of a product (set with the AreaName and BrandName properties) and the button is also passed our global Brand and Area variables through the AreaVal and BrandVal.
In the buttons, we have a rule that says that whenever the object is given mouse focus (Input.MouseFocus = true) then we are to set the AreaVal and BrandVal properties to AreaName and BrandName (the names displayed on the button).
What you should find when you do this is that when you roll over a button, the AREA will change, but the BRAND will not. This is because of the rules I explained earlier.
So now you know how to share a variable through your entire UI. This will come in handy in the next project discussed.
Monday, January 29, 2007
Project 1 - A Basic MCML File
This is the first part of my project. Like all my Media Center interfaces, the new version of Yougle is going to have the same look and feel (or as close as I can get to it, anyway) as the Media Center interface.
But I'm just starting out here, so let's get the basics covered.
Step 1: Make sure Visual Studio 2005 (Express or Pro) is installed. They aren't required for a basic application, but chances are you'll want to write some code to work behind the UI eventually - that, and the fact that Intellisense works for your MCML file in Visual Studio is just plain invaluable.
Step 2: Download and Install the Windows Media Center 5.0 SDK from http://www.microsoft.com/downloads/details.aspx?familyid=a43ea0b7-b85f-4612-aa08-3bf128c5873e&displaylang=en
Step 4: Create a new project in Visual Studio. Once the SDK is installed, you will have a new template under 'Media Center Applications', called 'Windows Media Center Presentation Layer Application'. This will set up a project so you can get started quickly and easily.
Step 5: Now, it's time to write some MCML code. MCML is an XML based language, so all the usual rules to tagging apply. You'll have an MCML application already generated with colour-changing text and a bouncy smiley button. But for now, Let's kill that off and learn a couple of new tags...
<mcml> - Just like the 'html' tag in web pages, this tag is the first one that should appear in any MCML file, after the schema information.
<ui> - This defines a User Interface. These are also used to define new types of reusable control. We will explore this a lot more later. Right now, we just need to get us a working page, so simply know that everything inside a UI tag is part of your user interface.
<text> - This, quite obviously, displays some text.
So, let's get some code in.
<mcml> <ui name="HelloWorld">
<content>
<text content="Hello World" color="White">
</content>
</ui>
</mcml>
There ya' go. A working MCML file, which should give you a 'Hello World' in pretty white, sitting in the middle of the screen.
Don't you feel special?
Next up: Using UI's
But I'm just starting out here, so let's get the basics covered.
Step 1: Make sure Visual Studio 2005 (Express or Pro) is installed. They aren't required for a basic application, but chances are you'll want to write some code to work behind the UI eventually - that, and the fact that Intellisense works for your MCML file in Visual Studio is just plain invaluable.
Step 2: Download and Install the Windows Media Center 5.0 SDK from http://www.microsoft.com/downloads/details.aspx?familyid=a43ea0b7-b85f-4612-aa08-3bf128c5873e&displaylang=en
Step 4: Create a new project in Visual Studio. Once the SDK is installed, you will have a new template under 'Media Center Applications', called 'Windows Media Center Presentation Layer Application'. This will set up a project so you can get started quickly and easily.
Step 5: Now, it's time to write some MCML code. MCML is an XML based language, so all the usual rules to tagging apply. You'll have an MCML application already generated with colour-changing text and a bouncy smiley button. But for now, Let's kill that off and learn a couple of new tags...
<mcml> - Just like the 'html' tag in web pages, this tag is the first one that should appear in any MCML file, after the schema information.
<ui> - This defines a User Interface. These are also used to define new types of reusable control. We will explore this a lot more later. Right now, we just need to get us a working page, so simply know that everything inside a UI tag is part of your user interface.
<text> - This, quite obviously, displays some text.
So, let's get some code in.
<mcml> <ui name="HelloWorld">
<content>
<text content="Hello World" color="White">
</content>
</ui>
</mcml>
There ya' go. A working MCML file, which should give you a 'Hello World' in pretty white, sitting in the middle of the screen.
Don't you feel special?
Next up: Using UI's
Subscribe to:
Posts (Atom)