CLASS Extensions. Making of (Part II)

Crashing your LightSwitch project with your extensions is a piece of cake. The first simplest thing I did was change the business type to handle integer values instead of string ones. But I changed “:String” to “:Int”. That was enough to do it. It should be “:Int32”.
So, after managing to create and use (declare as a type for an integer field in an entity) my business type, keeping my LightSwitch project in one piece, I had to work on my control. As I have already mentioned I had my custom control ready and tested, so, it should be easy.
I had used my custom control only in detail parts and although the expander used was “deforming” the layout when expanded (I have to fix this anyhow in the future) everything were going back to normal after collapsing the expander. This was not so for collections. Using my control in a grid the result after collapsing the color picker control was a grid row having a height of the expanded control. The reason is that the grid rows are auto-sized and have no specific height so…
I was only after having implemented a wrapper control to provide 2 different controls, one for collections and one for details, based on the reply by Justin Anderson to a thread initially intended to help me handle read-only controls, that I got an answer from Silverlight forum where I knew it was the right place to post my question. Either way, implementing what the reply suggested (although it works fine) required a lot of handling of transitions between expanded and collapsed. Also the “deform” in a grid when the control is expanded(even temporary) is, in my opinion, more annoying than in details.

if ((this.DataContext as IContentItem).ContainerState.HasFlag(ContainerState.Cell)) {
  ColorControl control = new ColorControl();
  control.DataContext = this.DataContext;
  control.SetBinding(ColorControl.IsReadOnlyProperty, new Binding("IsReadOnly"));
  MainGrid.Children.Add(control);
}
else {
  ColorPickerDrop control = new ColorPickerDrop();
  control.DataContext = this.DataContext;
  control.SetBinding(ColorPickerDrop.IsReadOnlyProperty, new Binding("IsReadOnly"));
  MainGrid.Children.Add(control);
}

In the code above you can see selecting the control to “use” based on the ContainerState property of the IContentItem that is passed as DataContext. You can also see the attempt to make the control read-only. My attempt was to make the controls automatically read-only when “Use read-only controls” is checked from the designer. I was that close…
Also for some reason my control when implemented in extension tended to take too much space by default. I had to change alignment to left/top by hand. It was only after releasing the first (and only one available until now) version that I managed to handle this along with other issues regarding designer behavior.
Hopefully before the end of 2011 I will be able to publish the next version, which contains also one more business type (rating) and respective control.
In the next post I will discuss the read-only issue that I didn’t manage to deal with in the published version…

DisplayName like family name is inherited.

Did you know that setting the Display Name property of your table (entity) and all fields will make screen customization even easier?
All display names you define in your data sources are automatically used in all your screens. This practically leaves you with the collection name translations in the Screens as the display name of your table is used only in singular.
Also, not only new screens are initialized by display names defined at the table level, but if you don’t change a display name manually in a screen, any change made in the table is propagated to the screen.
This makes screen customization much easier and also localization.
For less beginners or more curious than average ones: What actually happens is that LightSwitch uses the DisplayName attribute (which decorates almost all objects and their properties in LightSwitch) which is inheritable, to…display names (what else). When you first create a screen (either you have changed the display name of the table column or not) you will notice Display Name fields in the properties pane are dimmed and oblique (italic). This is to denote DisplayName attribute has not been defined but inherited instead. Once you change the display name of a field on a form, it automatically acquires it’s own DisplayName attribute and therefore the DisplayName attribute of the table column stops being inherited any more.

Even elements not related to tables (layout groups for example) have by default their display name dimmed and oblique.

The full story is that for every single element LightSwitch first looks for an “explicit”, so to say, DisplayName attribute. If not found then it looks for an inherited one and if not found either (the case of a new group layout) then derives the Display Name from the Name property of the element (inserting space before every upper-case letter found after a lower case one).
I hope this was actually a tip and not a trip…

Large Small Medium Large?

Did you know that everything you design in a LightSwitch application (tables, screens, queries etc) is stored in a file called ApplicationDefinition.lsml?
LSML extension stands for the title of the post…no, I’m kidding of course. It stands for LightSwitch Markup Language. This file can be found in the folder <Project Path>\<Project Name>\Data.
Working in Logical View this is file is not visible (no files are visible in this view either way). Turning to File View you can see links to this file in all three projects Client, Common and Server. Notice they are links. The original file is not included directly in any project.
The reason there is only one file and all projects have link to it, is that it’s common to all of them and any change made to it should be available simultaneously to all projects.
The reason it’s not included to any project, in my humble opinion, is mainly because it’s not meant to be edited in any way. It could be included in the Common project for example as it IS common.This file is the product of all designer work done in LightSwitch. Even when you change the Theme, or Access Type properties of the application from the Properties of the project this change is stored in this file.
This is the reason also, that only ONE (or none) “<Project Name> Designer” window is available at any given time in your workspace. Because there IS only one such window displaying a different part of the ApplicationDefinition.lsml file every time you double-click a table or a form or whatever opens a designer window.
One tip for the end. When you plan a major change in your model (data design), especially if you are NOT using a native datasource, keep a backup of ApplicationDefinition.lsml. If you are using version control, check a version in, even temporarily. If not, keep a backup copy of the file. One day you might thank me for this advice…