Monday, December 17, 2012 #

Invoke operation '...' failed. Error in deserializing body of request message for operation '...'. OperationFormatter encountered an invalid Message body.

Sometimes even long error messages don't tell you much. This one is over 300 characters long and still does not clearly indicate what is wrong:

Invoke operation '...' failed. Error in deserializing body of request message for operation '...'. OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name '...' and namespace '...'. Found node type 'None' with name '' and namespace ''

Sure, considering the line of code where it was thrown it told me that WCF (RIA Services) failed to return an object in a call. I have hundreds of calls that work fine. Why did this one fail? 

I could not find it. So I decided to work around it and serialize the object myself:

    string result;
    var sb = new StringBuilder();
    using (TextWriter tw = new StringWriter(sb))
    {
       XmlSerializer ser = new XmlSerializer(typeof(...));
       ser.Serialize(tw, theObject);
       result = sb.ToString();
    }
    return result;

When this code ran it revealed the error (in the InnerException): I had a field of type enum, and the value I assigned to it (coming from a database) was not valid - I had forgotten to update the enum definition.

Anyhow, the bottom line is that if you get the long error message mentioned above you might want to serialize the object yourself, so that a more precise error message is revealed.

Posted On Monday, December 17, 2012 9:25 PM | Comments (0)

Monday, October 10, 2011 #

Silverlight 5 ComboBox more rigid: Cannot call StartAt when content generation is in progress

It looks like Silverlight 5's ComboBox is more restrictive. In Silverlight 4 I could change the ItemsSource of a ComboBox that had a SelectedItem != null, while in Silverlight 5 I have to set SelectedItem to null before I assign a new ItemsSource. Why even mention this? Isn't this obvious? Well, the Silverlight 4 ComboBox simply ignored the SelectedItem and did not complain about the new ItemsSource, so moving to Silverlight 5 may cause some (unexpected) pain. But the real reason for this post is the exception that is thrown: InvalidOperationException ("Cannot call StartAt when content generation is in progress.") Saying this (Cannot call StartAt when content generation is in progress) is not very helpful, is it? Moreover, this exception is not thrown at a place that refers to the cause of the problem (the assignment to a ComboBox's ItemsSource): System.Windows.Controls.ItemContainerGenerator.System.Windows.Controls.Primitives.IItemContainerGenerator.StartAt At that point the whole stack trace is grayed out. (It does hint toward the ComboBox' SetContentPresenter, though.) So if you got confused, searched for the error message, and ended up here, you may want to check your ComboBoxes' ItemsSource assignments.

Posted On Monday, October 10, 2011 8:34 AM | Comments (2)

Thursday, December 30, 2010 #

Event notifications for Reporting Systems

The last couple of months I have been working on an application that allows people to browse a data mart. Nice, but nothing new. In this context I have an idea that I want to publish before anyone else patents it: event notifications.
You see, reporting systems are not used as much as we’d like. Typically, users don’t know where to look for reports that might interest them. At best, there are some standard reports that people generate every so often, i.e. based on a time trigger. Or some reporting systems can be configured to send monthly reports around, for convenience. But apart from that, the reporting system is just sitting there, waiting for the rare curious user who makes the effort to dig a bit for treasures to be found.
Wouldn’t it be great if there were data triggers? Imagine we could configure the reporting system to let us know when something interesting has happened. It would send us a message containing a link that would take us to the relevant section of the reporting system, showing a report with all the data pertaining to that event, preparing us for proper actions.
Here in the North West this would really be great. You see, it rains here most of the time from October to June, so why even check the weather forecast? But sometimes, sometimes it snows. And sometimes the sun shines. So rather than me going to the weather site and seeing over and over again that it will be raining, making me think “why bother?” I’d like to configure the weather site so that it lets me know when the rain stops.
Now, hopefully nobody has patented this idea already. Let me know.

Posted On Thursday, December 30, 2010 9:37 AM | Comments (1)

Friday, April 2, 2010 #

Like camping on the moon

No Silverlight today. I made a mistake. I created an application to upload a file and store it encrypted on a server. But I forgot to check on what machine it needed to be deployed. Yesterday I heard it was on an old ASP.NET 1.1 machine. Oops. Oh well, how hard can it be to change this simple application?

Answer: much harder than I thought. Today I took out:

Encryption using X509 Certificates
Master Pages
Compression
Using statements
Generic lists
Upload control
ASP.NET Membership

All via a key hole to access a virtual machine. It has its charm, though, doing primitive things.
Like camping on the moon.

Posted On Friday, April 2, 2010 11:01 AM | Comments (0)

Sunday, March 14, 2010 #

Changing the action of a hyperlink in a Silverlight RichTextBox

The title of this post could also have been "Move over Hyperlink, here comes Actionlink" or "Creating interactive text in Silverlight." But alas, there can be only one.

Hyperlinks are very useful. However, they are also limited because their action is fixed: browse to a URL. This may have been adequate at the start of the Internet, but nowadays, in web applications, the one thing we do not want to happen is a complete change of context. In applications we typically like a hyperlink selection to initiate an action that updates a part of the screen. For instance, if my application has a map displayed with some text next to it, the map would react to a selection of a hyperlink in the text, e.g. by zooming in on a location and displaying additional locational information in a popup. In this way, the text becomes interactive text.

It is quite common that one company creates and maintains websites for many client companies. To keep maintenance cost low, it is important that the content of these websites can be updated by the client companies themselves, without the need to involve a software engineer. To accommodate this scenario, we want the author of the interactive text to configure all hyperlinks (without writing any code).

In a Silverlight RichTextBox, the default action of a Hyperlink is the same as a traditional hyperlink, but it can be changed: if the Command property has a value then upon a click event this command is called with the value of the CommandParameter as parameter. How can we let the author of the text specify a command for each hyperlink in the text, and how can we let an application react properly to a hyperlink selection event?

We are talking about any command here. Obviously, the application would recognize only a specific set of commands, with well defined parameters, but the approach we take here is generic in the sense that it pertains to the RichTextArea and any command.

So what do we require? We wish that:

  1. As a text author, I can configure the action of a hyperlink in a (rich) text without writing code;
  2. As a text author, I can persist the action of a hyperlink with the text;
  3. As a reader of persisted text, I can click a hyperlink and the configured action will happen;
  4. As an application developer, I can configure a control to use my application specific commands.

In an excellent introduction to the RichTextBox, John Papa shows (among other things) how to persist a text created using this control. To meet our requirements, we can create a subclass of RichTextBox that uses John's code and allows plugging in two command specific components: one to prompt for a command definition, and one to execute the command. Since both of these plugins are application specific, our RichTextBox subclass should not assume anything about them except their interface.

  public interface IDefineCommand  
  {
    void Prompt(string content,                     // the link content
                Action<string, object> callback);   // the method called to convey the link definition
  }
  
  public interface IPerformCommand : ICommand {}

The IDefineCommand plugin receives the content of the link (the text visible to the reader) and displays some kind of control that allows the author to define the link. When that's done, this (possibly changed) content string is conveyed back to the RichTextArea, together with an object that defines the command to execute when the link is clicked by the reader of the published text.
The IPerformCommand plugin simply implements System.Windows.Input.ICommand.

Let's use MEF to load the proper plugins. In the example solution there is a project that contains rudimentary implementations of these. The IDefineCommand plugin simply prompts for a command string (cf. a command line or query string), and the IPerformCommand plugin displays a MessageBox showing this command string. An actual application using this extended RichTextBox would have its own set of commands, each having their own parameters, and hence would provide more user friendly application specific plugins. Nonetheless, in any case a command can be persisted as a string and hence the two interfaces defined above suffice.

For a Visual Studio 2010 solution, see my article on The Code Project.

Hopefully someone at Microsoft can make sure the CommandParameter property is supported in TextSelection.Xaml.

Posted On Sunday, March 14, 2010 9:01 PM | Comments (0)

Wednesday, February 3, 2010 #

Get rid of Web Application pages

Sometimes it is really, really difficult to get rid of bad habits. One of these habits in our profession is the use of pages in web applications. The World Wide Web started as a system of interlinked hypertext documents contained on the Internet. Why is it that nowadays, two decades later, we still build web applications using the document concept, putting content on pages?

The worst use of pages is when we force the user to switch between pages while doing a single task. Every page change means a short wait: the page needs to be loaded and rendered. Data needs to be retrieved. It also means the server gets hit, often needlessly (as the same data has been retrieved before). Moreover, every time a user needs to open a different page, she gets a context switch and needs to reorient herself. Eyes need to be focused. Things need to be recognized. Sometimes we even need to scroll the page! If this happens once or twice it's no big deal. But if it happens all day it becomes a headache.

Instead, an application should allow a user to put all tools needed to perform a task on one desktop. Of course we then get into the issue of screen real estate - is there enough space to display all tools (DataGrids, Forms, etc) on a single screen? This problem has been solved decades ago: we have used windows ever since. So what is holding us back from using windows instead of pages in web applications?

Sometimes it is really, really difficult to get rid of bad habits. Now that we have Silverlight we are free and could dump pages right here and now. But what is the first Silverlight Business Application template that appears in Visual Studio? One that is based on pages. Desktop applications never have pages. Why would they?

So I call upon all web application developers of the world: "Stop using pages! Put related controls in a window. Have a taskbar that contains for each window an icon that when clicked causes the corresponding window to appear on top. Allow windows to be resized, dragged, and closed."

Your customers will love it. Finally, finally they are free from pages!

Posted On Wednesday, February 3, 2010 9:41 AM | Comments (2)

Monday, February 1, 2010 #

Changing the FontSize in a RichTextArea

It's nice if a user can set the font size of all text displayed in an application, especially if this user is me and I am giving a demo - the font size that works for me (12.0) at my desk is not necessarily ideal during a presentation. So I have a FontSize property in my ViewModel that all controls observe. For RichTextArea controls that simply display text authored previously, changing the FontSize has no effect, since the FontSize of the text displayed is a property of the text itself, not of the control.

The excellent introduction to the RichTextArea by John Papa taught me a bit on the data structure this control uses to store the text. And so I could let my RichTextArea control react to any change in the ViewModel property by executing:

        public void IncreaseFontSize(double factor)
        {
            var res = from block in StoryTextArea.Blocks
                      from inline in (block as Paragraph).Inlines
                      select inline;
            Array.ForEach(res.ToArray(), (i) =>         // i stands for inline
            {
                i.FontSize = factor * i.FontSize;
                Hyperlink hl = i as Hyperlink;
                if (hl != null)
                {
                    Array.ForEach(hl.Inlines.ToArray(), iHL => iHL.FontSize = factor * iHL.FontSize);
                }
            });
        }

It's fast enough (for the typical texts I have) to adjust the font fluently. Cool!

Posted On Monday, February 1, 2010 9:21 AM | Comments (0)

Copyright © Marc Schluper

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski