Tuesday, February 5, 2013

Update about Updates

It has been a little while since my last update, but I am still making progress toward the first release of Xaml Helpmeet. In fact I think it will be ready for to publish an alpha version within the next seven days.

There have been a number of bugs that simply made the extension unusable, but many have been identified and resolved. Among the most significant bugs to be fixed are these:
  • Menu items which should have been disabled were not disabled until the first menu item of the package was clicked. This was due to the way extensions are normally loaded by Visual Studio. Ordinarily they are loaded on demand, i.e., when the first menu item is clicked. The package was unable to check conditions for the menu items during that time. I could configure the menu items to be disabled during that time, but that would have been just as bad, because they would continue to be disabled, even after text was selected. The solution was to add an attribute to the Package class that causes it to be loaded earlier in the process. Check out XamlHelpmeetPackage.cs for that change.
  • There were a number of problems with the CreateBusinessFormWindow class that needed to be resolved. Some of the issues were minor having to do with control placements on the window, but there were binding issues that had to be worked out as well. I redid some of the binding to make is a little simpler than my original translation. There are slight differences in the way Xaml is written for VB I supposed that necessitated some of this.
  • The same thing was true for the UIControlDefaultsWindow, plus I had to work some serialization issues with it as well. This window is used to set default values for controls, so that in those places where XamlHelpmeet creates controls for the user, these settings will be used as defaults rather than static values. The first thing the window does when it opens is to check to see if a settings file has been created, and creates if if necessary. This is simply a serialized collection of controls with the default values attached. When the window opens again, those defaults are loaded instead of the values programmed within the code. The biggest problem with this was that one of the properties would not make the round trip. When the settings file was read in the ControlProperties property would be initialized with a collection of null values rather than UIProperty objects as it was supposed to do. This was resolved finally by creating a new subclass of ObservableCollection called SerializableObservableCollection, and using that class for the property instead.

Many other bug fixes have been applied where I've found issues, and no doubt many more will need to be found, but I think the most complex issues are all out of the way. If that's right I should be able to package a binary for release perhaps this weekend and solicit willing users to install the package and try it out. I know there will still be some bugs, and there will be some design changes here and there to make before the beta and RC versions are ready, but the package should still be useful, and shouldn't be such as to cause any real problems.

There is one problem though that may be a show stopper. While debugging I have noticed that if I try to drag one of the packages windows to a new location on the screen, a fatal exception will be reported and VS will close. I do want to resolve that before the Beta release at least, but I'm not sure of the cause or how to go about resolving it. If anyone has seen anything like this before, please let me know, especially if you know how to resolve it.


Last edited Feb 5, 2013 at 8:12 PM by gloder, version 2


No comments yet.