In Traction

I am currently moving Uiml.net towards MSBuild files (a.k.a. Visual Studio project files) and experienced a few problems such as a restriction with Compact .NET’s OpenFileDialog.

After a bit of Googling, I finally know why I can’t seem to get the OpenFileDialog to look for files in \Program Files: it was just designed that way (do a quick search for OpenFileDialog on that page). Apparantly they wanted to help users organize their files, by restricting them to the \My Documents folder. Too bad they didn’t think of what developers might want to do … I want to allow people to try UIML examples when they click the “Select UIML file” button. Of course these files reside in the Uiml.net application directory itself, so I need to allow them to pick a file outside of the My Documents folder. If that wasn’t bad enough, it further restricts you to one level of subfolders within the My Documents folder!

I also noticed MSBuild has no nice way of copying a file to another path then the one it is being referenced from. I orginally wanted to copy the front-end files and vocabularies in the root directory where the Uiml.net executable is placed. Since I didn’t find a solution, I made dedicated directories for these files, and modified the code to look for them in those directories instead.

If I could tell MSBuild to copy a file to another path, I could also solve the OpenFileDialog problem just by copying the Uiml.net examples to the My Documents folder, while the rest of the application would stay in the Program Files folder.

So my (hackish) solution is now to copy all examples first into a direct subfolder of the user’s My Documents folder. Not very elegant, but it works.

I spent some time yesterday to update the Uiml.net homepage:

[img:509026066,medium]

We set up a wiki somewhere last year to provide more information about our UIML research. However, since Uiml.net is the main focus of our research efforts, I reorganized the wiki to be more of a homepage for Uiml.net, while still listing our publications.

I am hoping to migrate all the content of the old website (still located at Kris’ homepage) to the wiki soon.

Lately I have been enjoying Launchpad for hosting my projects and Bazaar branches. It has integrated specifications (_blueprints_), bug tracking, some kind of forum (_answers_). I have moved Uiml.net over to Launchpad as well. Launchpad’s integration of Bazaar branches will be useful for managing multiple experimental contributions from myself, Kris or our Bachelor’s or Master’s students.

Finally I’m hoping to put out a more or less stable release of Uiml.net by September. More information can be found at Launchpad.

I just registered Uiml.net and Cassowary.net in Launchpad.

Launchpad automatically creates a Bazaar branch from the CVS repository, which allows me to maintain my work in Bazaar, while still importing changes from the Uiml.net CVS tree.

It’s been a while since I reported on Uiml.net. We set up a wiki recently, which will eventually replace the old project page. There is still some content to be added though.

This year we also had some students working with or on our implementation:

• Jan Meskens, a computer science student at our university, has been working on template parametrization for his Bachelor’s thesis
• Pieter Gevers, an industrial engineer student at KHLIM, built a working car radio user interface using Uiml.net for his thesis
• Volker Janzen, a computer science student at the university of Ulm worked on a Windows CE application that retrieves meta-information about medical studies from a CDISC-ODM file, and transforms this data into UIML. This work was done for his diploma thesis.

A question we receive frequently is if we can send people the Visual Studio workspace. It would be good to upload that to the Wiki, and maybe do a formal release in the near future.

As I posted in an earlier article, Uiml.net allows us to connect the application logic with the user interface.

I showed that it’s possible to create a callback that listens to certain events, optionally only coming from a specific part. In these callbacks we can examine the part that has sent the event using the Uiml.net API.

But is it also possible to modify that part?

Of course we could operate on the widget-set specific user interface object (e.g. a System.Windows.Forms.Button), but that would require different code for each target widget set. Here is how we would change a button’s label when it is clicked using this approach:

public class ModifyTest
{
  public ModifyTest()
  {
    ...
 
    // connect only to the hello button
    uimlDoc.Connect(this, "b_hello");
 
    ...
  }
 
  [UimlEventHandler("ButtonPressed")]
  public void OnButtonClicked(Part sender, UimlEventArgs e)
  {
    // get the concrete UI object
    System.Windows.Forms.Button b = (System.Windows.Forms.Button) sender.UiObject;
 
    // change its text to 'Do it again!'
    b.Text = "Do it again!";
  }
}

Uiml.net provides a property setter interface that can apply any property. We only need the renderer instance in order to access it. We could use this API to modify the user interface in a generic way, if we rely on a shared class and property among all widget set vocabularies. In our example, the Button class exists for all vocabularies that Uiml.net supports, and has a label property in each vocabulary.

Let’s have a look at the generic solution. We only list the important code:

public class ModifyTest
{
  IRenderer _renderer;
 
  ...
 
  [UimlEventHandler("ButtonPressed")]
  public void OnButtonClicked(Part sender, UimlEventArgs e)
  {
    // create a label property
    Property p = new Property();
    p.PartName = sender.Identifier;
    p.Name = "label";
 
    // set its value to 'Do it again!'
    p.Value = "Do it again!";
 
    // apply the property on the sender part
    _renderer.PropertySetter.ApplyProperty(sender, p); 
  }
}