Josh the Developer

"Value does not fall within the expected range." When Adding a Control in Code

2012-01-04T11:50:00.000-08:00

"Value does not fall within the expected range" is an error I expect to receive when attempting to access an element of an Array that does not exist. Unfortunately, I have spent the last day receiving this message intermittently when trying to perform an Add on a UIElement's Children in Silverlight.

If you're like me, you received this error and immediately started Googling how to fix it by typing in the error and adding things like "Add" and "Silverlight." If you do this, you'll find a few results - almost exclusively about namescope conflicts. Well, there's a reason - that really is the problem no matter what all of your other investigations point towards.

Here were my exact symptoms: I was adding a context menu to a Grid dynamically. When the Grid initially loaded, the context menu was added. It was performed this way so that we could have a generic GridBehavior that included the ContextMenu instead of having a hard coded ContextMenu on each of our Grids. However, this code worked fine for years - why did it suddenly break?

Well, what changed? We had recently performed a merge, and this is when the problem started occurring. So, easy enough - I rolled back all of the GridBehavior changes (this is where the error was actually occurring after all), as well as any other file that seemed to be impacted by the GridBehavior changes (those that didn't build correctly after I rolled the first file back). This would fix it if it were merge related right? Well, no luck - it still failed.

What else can I try? Well, everything told me that it was about namescope conflicts. So, right before I added the control, I appended a random modifier to the Name - this should fix it, right? No luck.

What if I check for the Name to be used in the namescope of the parent I was adding it to? Or even the Application's RootVisual? Well - I told you that this error was occurring intermittently, and none of these checks coincided with whether the error would occur or not - they would always be either true or false, but not change based on whether the code blew up.

Then I noticed something - this control had a name. And it received that name in the XAML. I started thinking about this for a bit, and I wondered how long it had had that name. Checking the history - it received it in that last merge! Therefore, I ripped that name out and started testing again. Lo and behold, everything worked!

Here's the moral of this story: that error message really is about a namescope conflict. Believe it! It's somewhere in there! Secondly - don't name things in XAML that don't need names - especially don't do this if you're later going to add them dynamically - you can't guarantee that you'll only add it once instead of multiple times in the namescope!

Silverlight Screen Disabling When Closing ChildWindow

2011-12-30T10:38:00.000-08:00

An obnoxious problem has been plaguing a project that I've been working on for the last couple of months. As we would be testing various pieces of functionality, the screen would inexplicably become completely disabled. Now, we were working in a TabbedPane, so it was quite odd that the entire browser screen was being disabled (and not just our current Tab). Well, as I'm sure you realize - this is not acceptable production behavior! So, as we began drawing closer to our release date, this became more of a pressing concern - and so I was able to dedicate several hours to investigating the problem (and now writing this so that I didn't forget the solution!)

Ok, here are the steps I found to reproduce.

Go to a certain tab
Bring up the ChildWindow
Click the "X" (built in Close) button
Go to a different tab
Bring up a different ChildWindow
Close the new ChildWindow
*poof* your screen was disabled!

So, if you're like me, you assume that the problem is in the second ChildWindow - after all, that's the one showing the symptoms... except that it works most of them time - just not when you go to the other ChildWindow first.

Anyway, I scoured the Internet looking for anyone that was having any kind of similar problems. There were people talking about setting both a DialogResult and calling the Close() method, so I looked for that. Nothing.

There were people that talked about calling Close() twice (setting DialogResult actually calls Close() so this is really the same as the last problem). I looked all over the ChildWindow that was exhibiting the symptoms - still nothing.

What actually happened was that my FIRST ChildWindow was calling Close() from the Closing event handler, because it was calling an inherited block of code without realizing all of the implications - and this somehow decided to mess up the next ChildWindow's close operation. Who knew?

So, long story short - if you're experiencing a disabling of your main screen when a ChildWindow closes, look for Close() to be called twice - but be mindful of Close() being called on a previous ChildWindow after it is already in the Closing event handler as well!

Validation States on TextBox in Silverlight

2011-11-02T05:43:00.000-07:00

So, one of the requirements on the project that I'm working on is that we have a Silverlight TextBox that has to display the error balloon/tooltip. Simple, right? However, this TextBox is actually just displaying data, and the data is entered through a dialog, not directly as text on the screen. Furthermore, to ensure that the user does not attempt to enter the data directly, the TextBox is disabled.

You may know where I'm going with this - my Validation Error tooltip never appears! Why? The default style of a TextBox only shows the tooltip in a focused state! Eventually, I realized this. After looking in the MSDN documentation about TextBox, I was able to get the default style of a TextBox, and I was able to override it's InvalidUnfocused state to do the same as the InvalidFocused state - and it worked!

Now to find a more intuitive way for the user to see that error message without it always being on the screen...

Why is my Silverlight DataForm acting like that?

2011-09-25T07:56:00.000-07:00

The other day, as I was using Silverlight, I put a DataGrid inside of a DataForm. Seems innocent enough, right? Specifically, what I wanted to accomplish was to allow users to add elements to a DataGrid with drag and drop functionality. Therefore, there were two DataGrids - one that the user dragged from, and the other that would receive the drop event. What I noticed, though, was that the added elements were not being saved.

We are using WCF RIA services, so I first assumed that I had created my composition objects incorrectly, and so I spent quite a bit of time looking into and verifying that code. After adding more and more breakpoints, I discovered that the WCF RIA service call was not to blame - the added elements were not even in the Submit operation, and so they were being removed sometime before the Submit was called.

Next, life got even more strange - if I edited one of the DataFields on the DataGrid, and then I dragged an item over, everything saved correctly. This left me quite puzzled. Then, eventually, a co-worker helped me discover the problem (which I thought was strange enough to warrant a blog post - maybe this will help other people (or even myself) next time one of us runs into this situation).

A Silverlight DataForm Rejects changes on EditEnded.

What? Yeah, I thought that this was quite strange. Why was I hitting this event? My "Save" button was not in the DataGrid! However, once you know this, it is easy enough to fix. Handle the EditEnding event on the DataForm and mark the event canceled:

private void DataForm_EditEnding(object sender, DataFormEditEndingEventArgs e)
{
e.Cancel = true;
}

Done! Now my DataForm stopped rejecting my changes.

Making Values Required in a Silverlight DataForm

2011-07-05T14:37:00.000-07:00

For those of you who have done validation in a Silverlight DataForm before, you probably are used to setting the [Required] attribute above all of the necessary fields in your WCF RIA project. From there, .NET will auto-magic the necessary code and, combined with lots of NotifyOnValidationError and ValidatesOnExceptions tags (and potentially some GetBindingExpression().UpdateSource()), viola! it will successfully perform validations. However, I ran into a situation where I was actually taking a couple of fields and transforming them into a single field from my WCF RIA service data object. After a long time of scratching my head, I was really stuck on trying to figure out how to force this validation to work. I had tried setting the [Required] attribute on the field they were bound to, added all the usual NotifyOnValidationError tags... nothing.

Eventually, I realized how to get around this issue (and it made me feel a bit silly for not coming up with this earlier.) You know where we set "ValidatesOnExceptions=true"... well... let's throw a ValidationException! So, in the setter of the property that I was binding the DataField to, if the data was invalid, I simply threw a ValidationException. Poof! It suddenly started working. Is there a better way to do this? Probably. However, this was able to get me back on the right path, and I was able to resume being productive.

Systematically Update Binding in Silverlight

2011-04-01T13:48:00.000-07:00

So, after quite a bit of time in Silverlight, I have learned that DataForms are very powerful entities. However, they like to hide from me what they are doing. Therefore, when I get into a situation in which I need to simulate their behavior, this often ends with me banging my head against a wall and typing my query into Google in as many different ways as possible. Recently, I have been attempting to force a validation on an object that was not in a DataForm... and I had no idea how. Fortunately, I stumbled upon this forum and it helped me. So that you don't have to bother reading it (that's why you're at my site, anyway, isn't it?) I have placed the important code snippet here:

BindingExpression bindingExpression = myTextBox.GetBindingExpresion(TextBox.TextProperty);
bindingExpression.UpdateSource();

Poof! Your TextBox (assuming your TextBox variable is called "myTextBox") will validate.

Silverlight Data Forms with BusyIndicator

2011-02-17T11:09:00.000-08:00

So, I'm sure that this has been posted elsewhere, but I don't really remember where, so I figured I would re-post it if for no other reason than it would allow me to find it again.

When using Silverlight 4 with the toolkit, I ran into an interesting bug. Sometimes when I would use a DataForm along with the toolkit's BusyIndicator, the DataForm would appear to be disabled, even after the BusyIndicator was no longer showing. (To see more about the bug itself, you can go here.) After discovering what the issue was, I researched on Google how I should fix this. As it turns out, it is a pretty simple fix. I simply added the following (note that DataForm is the variable name of the DataForm in my XAML):

DataForm.IsEnabledChanged += new DependencyPropertyChangedEventHandler(DataForm_IsEnabledChanged);

and

        void DataForm_IsEnabledChanged(object sender, DependencyPropertyChangedEventArgs e)
        {
            if (!IsEnabled)
            {
                VisualStateManager.GoToState(DataForm, "Disabled", true);
            }
            else
            {
                VisualStateManager.GoToState(DataForm, "Normal", true);
            }
        }

Poof! The code was able to go back to the correct state. Hopefully Microsoft will fix this so that this workaround is no longer required, but in the meantime, I figured it might help someone to see this.

Silverlight DataForms with IsEditable

2010-12-15T14:46:00.000-08:00

This may be something that everyone else knows already, but since this tripped me up for a little while, I figured I might as well post a blog about it.

Today, as I was tweaking one of our DataTemplates that was being used in a DataForm in Silverlight 4, I was running into a problem related to the IsEditable property. I had a ComboBox in my template, and I tried everything I could to get it to be read-only (I needed it to be read-only only some of the time - depending on what was set in a different property). After eventually thinking maybe my binding was broken, even though I saw it call the get of my property, I tried hard coding IsEnabled to false. Still to no avail - it kept being editable (much to my chagrin). Eventually, after reading about how DataForms worked, I came up with an idea - I put the IsEnabled binding on the DataField tag instead of on the ComboBox itself. Sure enough, poof! it instantly started working and my ComboBox was enabled or disabled depending on the value that my DataField was bound to.

Hopefully this helps someone who runs into a similar problem. As a sidenote, I also discovered during my testing that you can set something inside a DataForm to be read only by changing the Editable attribute on the property that is being bound to. This wouldn't work in my situation, however, since whether the value was read only or not was dependent on the value of another property, so it made the attribute route more tricky.

New Blog

2010-11-02T06:29:00.000-07:00

Just for those of you that are interested, I have created a new blog at the following link: http://jedwards14thegamer.blogspot.com This will be a personal (non-technical) blog. One of my primary hobbies is playing board games, and so I will be reviewing games that I play on that blog. If you are interested in board games, feel free to follow that one, too!

Asynchronous Silverlight Unit Tests

2010-10-15T09:42:00.000-07:00

So, after beginning to do some unit testing of View Models in Silverlight, I discovered that there have not been that many articles written about how to do this. Fortunately, I did find http://www.jeff.wilcox.name/2009/03/asynchronous-testing/ but other than that, most of what I have learned has been by trial and error. Therefore, here are my findings. Hopefully this will help someone else.

1. "Asynchronous" is a bit of a misnomer. Think of all of the "Enqueue" commands as "Do this later". In traditional asynchronous processing, if you fire off something like an "EnqueueConditional" command, it will fire off a new thread that will begin executing immediately. This is not the case with the Silverlight unit tests. Here is what I did as an example:


[TestMethod]
[Asynchronous]
[Description("Whatever")]
public void TestMethod()
{
  int x = 0;
  EnqueueConditional(() => x == 2);
  EnqueueCallback(() => { method1(); });
  x = 1;
  EnqueueConditional(() => x == 1);
  EnqueueCallback(() => { method2(); });
  x = 2;
  EnqueueTestComplete();
}

Now, what I would expect would be that method2 would be called before method1. After all, x == 1 as soon as the 2nd condition is enqueued. However, as I said earlier "Enqueue" should be thought of as "do this later". Therefore, what actually will happen is that method1 will be called (because at the end of the method's synchronous processing x == 2), and method2 will never be called (because x != 1 ever again in the method - also, this will never get to the TestComplete, and so will be an infinite test, just so you're warned).

2. "EnqueueConditional" basically means "wait until". This seems to be the most important piece of the processing. This is the key that will allow you to ensure that a condition is met. After this happens, all of the EnqueueCallbacks (including EnqueueTestComplete) are executed until the new "EnqueueConditional", which will then perform another wait until the condition is completed.

3. "EnqueueCallback" just allows code to be done later. The "later" is driven based off of the EnqueueConditionals. Consider the following code snippet:


[TestMethod]
[Asynchronous]
[Description("TestMethod2")]
public void TestMethod2()
{
  int x = 0;
  EnqueueCallback(() => x = 2);
  x = 1;
  EnqueueConditional(() => x == 2);
  EnqueueTestComplete();
}

In this situation, the EnqueueCallback has nothing that it has to wait on, but since it is an "EnqueueCallback", it will not execute until the end of the method. It will function the same as if I had written the code this way:


[TestMethod]
[Asynchronous]
[Description("TestMethod2")]
public void TestMethod2()
{
  int x = 0;
  x = 1;
  EnqueueConditional(() => x == 2);
  EnqueueTestComplete();
  x = 2;
}

The Importance of Unit Testing

2010-09-01T06:09:00.000-07:00

So, a while back, a friend and I started working on developing a game in a new language, mainly as a means of learning that language. Because of this, it didn't really matter how well the code was written, or if we tested it all that thoroughly. However, once our code seemed pretty stable, we decided to go ahead and open it up to the Open Source community. At this point, we started getting reports of some weird errors that we had never seen.

As it turns out, we had tested our game within the confines of what "normally" happens in a game, and in those situations, everything worked out fine. What we did not test is what happens when something "abnormal" happens, ie, the game runs out of money, the game is especially high scoring, etc. Now, of course, these do not often happen - in fact, we did not even think about them. Also, since we simply had a stack trace, it was at first confusing to try to hunt these bugs down, as the piece of code looked correct. Had we written unit tests to test both positive and negative test conditions, then theoretically, we would have caught this and our users wouldn't have had to report it. Realistically, however, you can't catch everything. Needless to say, there are unit tests for these conditions now.

REST Services in WCF and ASP.NET MVC

2010-07-30T06:03:00.000-07:00

So, recently my team has started a project with a large base of legacy code, causing us to switch from the Java world, in which we have a large amount of experience to the .NET world in which we are much more limited. In doing this, one of the first things we needed to determine was how we were going to create Web Services, and if they were going to be in REST or SOAP. After some banter about SOAP and REST, we decided to use REST for now, delivering the responses in JSON. The next obvious question was, how are we going to implement the REST services. Here are the two ways that we have gotten them implemented so far:

ASP.NET MVC:
To do this, we simply created a new ASP.NET MVC 2 Application. From here, it was a simple matter of adding a Controller to the Controllers folder, and viola, we had a REST Service. The next thing we had to do was to make it return the response in JSON. This was another fairly simple matter, and eventually, we had a method returning an "ActionResult" and ending with this line:


return Json(result, JsonRequestBehavior.AllowGet);

We were disappointed that result had to be an actual object instead of a dynamic object, however (unless we just haven't figured out how to get around that).

We did run into a couple of lessons on this, though:

1. This works great with IIS 7 (and much less great with anything before it). To get around this, we have used wildcard extensions for now. If you are getting 404 errors when trying to hit your Controllers in IIS, but everything works while debugging, Google this, as it will help.

2. Our controller's method really likes being called "Index". I'm sure there's a configuration where we can change this, but we have realized that configurations can be hard to find in .NET.

3. When deploying, there seem to be a large number of files that are always necessary, instead of neatly bundling into a single artifact.

WCF:
To create a service in WCF is just as simple as creating one in MVC. Just create a new WCF project, and *poof* you have a Web Service. Unfortunately, it's SOAP. To get around this, you have to perform some configuration of your Web.config file. I don't understand all of it, but in the end, this is what I came up with that worked for ours (note that this is just the Services and Behavior tags inside of the system.serviceModel tag - this is not the whole file):



<services>
      <service name="RestLayerInWCF.Service1">
        <endpoint 
          behaviorConfiguration="webby" binding="webHttpBinding" bindingConfiguration=""
          name="Rest" contract="RestLayerInWCF.IService1" />
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="webby">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>

Also, we had to mark our services with an extra line:


[WebGet(UriTemplate = "/", BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = System.ServiceModel.Web.WebMessageFormat.Json)]

We had some observations about this one, too:

1. The Web.config is a pain to figure out the first time.

2. You have to maintain both an Interface and an implementation of each Service.

3. You seem to have to type the .svc to navigate to the service instead of having the freedom to name your service whatever you want.

4. An interesting thing we noticed is that the return of JSON is smarter than I thought. I had a problem here where my method signature returned a string, and so I was converting things to Json to return. This caused them to all return the quotes as \". Instead, I should have just let the method "do it's thing" and return the original object - it converts it to Json for me.

Anyway, now we have the tough decision to make - which one are we going to use? I have no idea....

Dangers of setTimeout in Flex

2009-08-05T14:09:00.000-07:00

So, after fighting a memory leak in Flex for the last week, I have learned a valuable lesson that hopefully will help. The setTimeout method in Flex is dangerous. It turns out that it is not automatically garbage collected when your Flex app is in operation (indeed, I don't even know of a manual way to force it to be garbage collected). Here was my situation:

I needed a clock that would increment itself every second. To do this, I created a little method called runClock that simply updated the time on the clock face and then had a setTimeout(1000, runClock). Without realizing what I had done, I was now creating a new Object every second that was never reclaimed by the Flex garbage collection process.

What I should have done (and what I now have) is a Timer. I have simply set my Timer to fire every 1000 ms, to call runClock and to run indefinitely. Problem solved and memory leak patched!

A Pragmatic look at the Groovy-ness of Groovy

2009-06-19T16:43:00.001-07:00

So, now that I've been familiar with Groovy for a while, I figured that I would post a blog about my opinions of it from a pragmatic perspective.

First off, I think that Groovy is an awesome language, and development in it allows code to be much more streamlined, and it is wonderful to finally be able to give up on some of the nuisances of Java. My favorite part is the ?, but I also enjoy only writing try-catches when I actually intend to catch an Exception, not writing getters and setters, and the metaClass ability is like finding a superpower. However, life is not all good in Groovy-land.

There is another tool in my development arsenal that is at least as powerful as Groovy, and which also enhances my development speed. This tool is code complete. Unfortunately, these two tools are currently mutually exclusive. I know that Groovy is dynamic, but when I specifically set a variable type declaration, you would think that my IDE should at least be able to kick into Java mode and tell me what the methods of String are without me having to type them manually or look up the oft-forgotten ones in the JDK. But lo and behold, it appears that none of the IDEs have found a way around this hicup yet.

The grand conclusion! Again - I like Groovy. But in a real world environment, before I develop a new class, I have to look at which tool will help me develop my code faster and maintain it more easily in the long run. So far, it appears that the main purpose of Groovy in my life will be to writing very brief classes, writing unit tests, and working with XML. Hopefully my IDEs will develop, and I'll be able to use both of these tools at the same time sometime in the near future.

Spherical Mercator - Because the World Really is Flat

2008-11-11T09:10:00.000-08:00

So, recently I have been working with OpenLayers and KML, just learning each of the technologies, and I discovered something odd. When I added a KML path as a Layer on my OpenLayers, my path liked to move around. No matter where the map was centered, the path was in the same place in the window. That is when I started investigating spherical mercator. Its not too tough to add, and it will quickly fix this problem. Basically, what is happening is that your map is round, but your KML is flat. You will need to fix this by making both of them flat.

Here are the basics that you need:

var map = new OpenLayers.Map(('map'),
{projection: new OpenLayers.Projection("EPSG:900913"), displayProjection: new OpenLayers.Projection("EPSG:4326"), units: "m",
maxExtent: new OpenLayers.Bounds(-20037508, -2003750, 20037508, 20037508.34)});

var mapService = new OpenLayers.Layer.Google( "Google", { sphericalMercator: true, type: G_PHYSICAL_MAP } );

map.addLayer(mapService);

map.addLayer(new OpenLayers.Layer.GML("KML",
"http://youraddress/kmlFile.kml",
{projection: map.displayProjection,
format: OpenLayers.Format.KML,
formatOptions: {extractStyles: true,
extractAttributes: true}}));

Once you've added this, now your path (or whatever KML you want to use) should stay in place, and you're done.