A real head-scratcher this one since this worked fine on our development machines, and our test and staging environment (the majority of bugs are picked off from our test servers, a few unusual ones may creep through to the staging servers, before giving the all-clear to be released live!). This made it a tough problem to diagnose (since you can’t debug something that is essentially “working” on your development pc!). What made it even more difficult is that the lead Silverlight developer on the charting project is on holidays (always the time when something goes wrong!). Even more interesting about the problem was that in both “fullscreen” Silverlight mode and when the “Annotations” panel was pinned, the slider sticking problem simply went away! Two modes completely unrelated to the menus appeared to “fix” the problem!
To make a long story (in my case a two day trawl through thousands of lines of code) short, it turned out that during an asynchronous, looping call to an animation (the “Slide” in question) the code was stepping through the animation at intervals of 29px and was trying to tell the main class that the animation was over when the animation reached or exceeded the maximum height of the panel. In our case, with the new version of the Charts, the maximum height happened to by 377px. Now purely coincidentally, 29 happens to divide into 377 exactly 13 times, so when the line of code read something like “if x > y, finish animation” then because 377 is not greater than 377 it kept going... going nowhere! So a simple addition of an “=” character to read “while x >= y, finish animation” solved the problem.
Such a simple solution, but unfortunately to a problem buried deep in code that would work perfectly on a developer’s pc and only go wrong when the height of the Silverlight application was constrained to a multiple of 29, making it a needle in a haystack to find.
Scott Tattersall, Chief Technology Officer, Zignals.com the free stock alerts, market alerts, and stock charts website