?

Log in

No account? Create an account

Previous 10 | Next 10

Mar. 9th, 2008

DevLynx

Progress Update

I had to leave town for a week on personal business so I didn’t get as much done as I would have liked. I have completed the class structure to manage command line arguments. I now need to create the automated build tools for managing the MD5 hash information. After that I will update the documentation to include the command line arguments classes. As soon as those tasks are complete I’ll do another source code release.

As I have said, we may not use the DevLynx ShellApp at work. However, we will almost certainly be using the ConfigurationStore and the command line arguments classes. So I have separated these general purpose classes into a DevLynx.Utilities solution. That way they can be used without the ShellApp.

I hope to have a source code release next weekend.

dlx

Feb. 24th, 2008

DevLynx

How do I compile the DevLynx ShellApp?

Based on a comment by manayat regarding my Feb 17th post, I thought it would be a good time to describe how to use the DevLynx ShellApp. So this weekend I created a virtual machine and loaded Visual Studio 2005 and the Developer Express components. I then documented how to get both the ShellApp and Address Book to compile. There were some modifications to make it easier for the first time user. There are way too many steps but I will hopefully automate some of them as the product gets more mature.

The documentation is in the help file found in the Source\ShellApp\Support\Help directory. Go to the task-based help and view the articles there.

This code (along with the help file) and a PDF of the blog can be found on my web site at http://www.tetzel.com.

dlx
Tags: ,

Feb. 17th, 2008

DevLynx

Documentation and Source Code Release

Well, I was right; documentation is a daunting task. Even the little bit that I have produced took much longer than expected - I have a whole new respect for technical writers. I don’t have everything documented but I do have a good start and will hopefully not fall behind again.

There have been very few changes to the code base since adding the splash screen.
•    ConfigurationStore.CreateStore now writes cleaner XML into the configuration section.
•    I have added a DefaultUxParadigm to the ProductInformation.config file. This value allows you to select which paradigm comes up when the application is first initialized.

The latest code and PDF of the blog can be found on my web site http://www.tetzel.com.

Next steps:
•    Keeping the MD5 hash codes in both the ProductInformation.config file and the ValidateProductInformation is too prone to error. I will be creating automated build tools which will allow these items to be set during the build process. There will be a series of console applications that can be run from batch files or integrated into build tools such as FinalBuilder.
•    The automated build tools will rely on command line arguments. I looked around the internet for a class that I could use. However, they were either too simple or more complicated than I wanted. So I will write a class to manage command line arguments.
•    I will also work on a feature to allow some rudimentary ordering of UxExtension elements. Right now my Exit menu item always appears at the top of the menu which would be very confusing for users expecting to see it at the bottom.

dlx
Tags: ,

Jan. 28th, 2008

DevLynx

Sandcastle January 2008 Release

I downloaded the Sandcastle January release earlier and just checked the speed. Compiling the DevLynx ShellApp help content took 9 minutes with their previous release; it now takes 1:48. Very nice work! Wow.

dlx
DevLynx

Protecting a decoupled ShellApp and the splash screen

One of the features that I added for the last release was a ProductInformation.config file. This configuration file stores information about the company, product and splash screen. This information is accessed via the ProductInformation service. From the help content:
The DevLynx ShellApp is designed to be used with multiple applications without recompiling. However, the ShellApp need to know some information about the product including the company name, product name, paths where product specific information is to be stored, splash screen image, etc. This information must be decoupled from the ShellApp. The product information service addresses this need.
The product information service reads the appropriate information from a configuration file. This file is named "ProductInformation.config" and must reside in the same directory with the application executable. The configuration file is a standard app config file with an appSettings section.
The ProductInformation.config file is designed to never be changed by the user or the application. So only place information in this file that is constant for the lifetime of this release.
Having a text file with your company name and splash screen may be an enticement for your users. They may want to change the company name or the splash screen image. So how do we go about protecting this information from the “vandalism” of users?

The ProductInformation service has the capability to store an MD5 hash for a file and then check that value to ensure that the file has not changed. This can be done for the splash screen image. But of course the ProductInformation.config file must be protected as well. Here we must store the pre-computed MD5 hash of the ProductInformation.config file somewhere else and check it against the file. The ValidateProductInformation method takes an MD5 hash string as a parameter. The stored string can be located anywhere. In the DevLynx Address Book I have it stored directly in the main Address Book assembly which can be strongly named as well. Of course if you don’t care if someone makes changes to these files then you don’t have to use these capabilities.

I also added a splash screen to the shell since I felt that the pause between launching the application and the shell appearing was too great. The splash screen is a modification of the asynchronous splash screen at: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=27DF8F87-37A7-4751-8198-B9A3526BBCDD This is a general purpose splash screen and all you have to provide an image to display and a few properties and the rest is done automatically. If you don’t provide an image it will still run but as a thin window with the status text displayed. The splash screen options are stored in the ProductInformation.config file and are listed below (again straight from the help content):
  • SplashImageFileName - Contains the file name of the image that will show on the splash screen. If this name is blank then ShellApp will look for DevLynx.ShellApp.Shell.exe.png for the splash screen image.
  • SplashImageFileMD5 - If this value is present the ShellApp will check to ensure that someone has not altered the splash screen image file. It must contain the MD5 hash of the image file.
  • SplashStatusLocation - The X, Y coordinates of the splash screen status text. The default location will be 10 pixels from the left and 10 pixels from the bottom of the image.
  • SplashTextColor - The color of the status text on the splash screen. The default is black. Colors must be one of the named colors from the System.Drawing.Color class.
  • SplashTransparencyKey - The portions of the image which are this color will be completely transparent. Note that partial transparency is not supported here. Hard edges are required to make this look good. Colors must be one of the named colors from the System.Drawing.Color class.
  • SplashOpacity - Setting the SplashOpacity to something less than 1.0 will make the splash screen transparent. This number needs to be between 0 and 1.0.
  • SplashIsHaloText - Since we are placing the status text directly on an image the text may blend into the image and be unreadable. By setting the SplashIsHaloText to "true" the status text will surrounded by a halo effect in the SplashTextHaloColor. Note that if the halo text goes into a transparent section of the splash screen it will not look very good.
  • SplashTextHaloColor - The color of the halo surrounding the status text on the splash screen. The default is WhiteSmoke. Colors must be one of the named colors from the System.Drawing.Color class.
Using these options you can develop nearly any splash screen that is desired. I’ll admit I got a little carried away with the splash screen options. I always wanted to see an algorithm for halo text (http://www.bobpowell.net/halo.htm) and once I found one I had to implement it.

I also continued to develop the help content. While it is far from complete I am pleased with what I have to this point. The next step is to write the help content for all of the features that I have developed so far - time to play catch up. As with many developers, I would like to continue adding features; but if I don’t catch up with the help content now it will be too daunting a task.

dlx

Jan. 20th, 2008

DevLynx

Refactoring, Sandcastle, Data Access, and Source

This is the first release in which I have included the sample program, DevLynx Address Book (DAB). The DAB has all of one function, it will allow you to enter contact names. It uses the new DataAccess service which centralizes some of the common data access needs; more on that later. The DAB comes with source and a zip file which includes the running executable.

Here are some of the new features/refactorings: First I removed the “Infrastructure” level of the ShellApp. The SCSF added the infrastructure level as an organizational method anticipating that business modules would be in the same solution. Since that is not the case with the ShellApp and everything was in the infrastructure directory I felt it needed to be removed.

I found and added the Versioning Controlled Build application to help synchronize the version numbers. This tool has both a Visual Studio add-in and a command line tool. I added the command line tool to the FinalBuilder automated build and now I no longer have to think about versioning any builds.

As soon as I started the DAB sample application I immediately needed a way to persist the data. I wrote the DataAccess service which handles connection string storage, concurrent connections to multiple databases and in memory data sources. The DataAccess service is based on the DevExpress eXpress Persistent Objects (XPO) which allows connecting to a number of different databases without code changes (XPO is an Object Relational Mapping tool). I have tested it with the in memory data source, VistaDB3, Access and SQL Server.

One of the nice features of XPO is support for an in memory data source. It stores persistent data in a .NET DataSet but allows access via the same method as other databases. The DataAccess service can use the in memory data source and includes the ability to save and load the dataset from the disk. This was first developed for testing speed but will have use in general purpose development.

The final functionality was to create additional content for the DevLynx ShellApp help files. There is now an overview topic discussing the functionality of the ShellApp. I will add examples from the DAB in the future. The additional content is simply HTML files included by the Sandcastle Help File Builder. However, I wanted the additional content to use the same CSS files, scripts and images and look and feel of the XML comment generated source. After a bit of experimentation it seems to be working great. I encountered two problems. First Sandcastle is SLOW. It takes about nine minutes to generate the help files. So every time I needed to test my new content I would have to wait. I hope that Microsoft speeds up the processing a bit. I looked around for a free HTML editor that would satisfy my simple needs. After a bit of searching I settled on Komposer. I worked with it for a few hours but finally got tired of it reformatting my HTML source into something unreadable. I set the option to keep the original formatting but it didn’t matter. So I finally downloaded a trial copy of TopStyle by Nick Bradbury. It provides few frills but it works and doesn’t try to “help me out”.

To run the DAB all you need to do is to unzip the files and run the executable. It places nothing in the registry and does not register anything on your computer. It does, however, place configuration files and its database into the directories pointed to by Environment. SpecialFolder .CommonApplicationData and Environment. SpecialFolder. ApplicationData. To change the database used by the DAB you can modify the SharedProductSettings.config file in the CommonApplicationData directory. Just change the “Primary” stringVaue connection string link to point to one of the other connection strings in the ConnectionString category. You can look into the connection strings group to see the different databases that have been tested. If you use the SQL Server connection string you will need to insert your own server and instance names.
  <category name="ConnectionStringLinks">
<value name="Primary" stringValue="VistaDB3" />
</category>
You can change to the menu/toolbar paradigm by changing UserCommonSettings.config in the ApplicationData directory. Just change UxExtensionName stringValue from DxRibbon to DxMenu.
  <category name="UxSettings">
<value name="UxExtensionName" stringValue="DxRibbon" />
</category>
You will find the source code at: http://s3.amazonaws.com/DevLynx/2008 01 20 DevLynx CAB Source.zip and the DAB binary at: http://s3.amazonaws.com/DevLynx/2008 01 20 DevLynx CAB.zip

dlx

Jan. 14th, 2008

DevLynx

Delay in source release

Well, unfortunately I ran into some coding issues and I'm a bit late on my promised release. I'll try to get it done in the next couple of days. I apologize for the inconvenience.

dlx

Jan. 8th, 2008

DevLynx

NUnit, NMock2 and Sandcastle

It’s been a month since my last update. The holiday season is over and I’m back to work on my CAB test application. These past few weeks I have been focusing on unit testing, documentation and automated builds. I have also added one service, the ConfigurationStore.

The ConfigurationStore allows the user to generically read and write type safe values to configuration files in a more structured way then the standard appSettings. It allows multiple stores with categories and values - basically a two organizational levels and a terminal nodes to store key-value pairs. Currently types supported are: Bool, DateTime, DateTimeUtc, Double, Enum, Integer, and String. I will add more as they become required. Since I am testing the CAB for multiple large scale projects the ConfigurationStore can manage information for the following situations:
•    AppConfig: application specific values that the user should not change (we are assuming that the user does not have access to the application location so we don’t store values that should be user modifiable in the application configuration file).
•    SharedCommon: values which are shared between users and common to all products.
•    UserCommon: values which are user specific and common to all products.
•    SharedProduct: values which are shared between users and product specific.
•    UserProduct: values which are user specific and product specific.
•    UserCustomization: values which are user specific and holds user customizations (such as window placement, etc).

The ConfigurationStore class has 100% code coverage through NUnit tests. This is my first real attempt at unit testing (I know, I’m a late bloomer :-). I’m sure that all paths are not covered but I hope that will be resolved as I learn better testing techniques.

Overall unit testing is up to date. I have unit tests on much of my code but have excluded unit tests on classes that the SCSF created. The code that does not have unit tests are the Shell and those that must interact with the WorkItem.UIExtensionSites. The CAB code included a TestableWorkItem that recreated some of the WorkItem but it did not include the UIExtensionSites. I may be able to work something out at a later date but for now I’m going to continue.

I also experimented with mock objects for the first time. This was a bit frustrating since NMock2 does not have the best documentation; but I was pleased with the final result. All of the tests will be included in the next source release.

I have also started to smooth out the XML documentation of classes. It’s by no means complete but it is usable. I’m using Microsofts SandCastle with Eric Woodruffs Sandcastle Help File Builder to produce a help file. I have also experimented with adding additional content to the generated help files so that I can include a framework overview and task oriented entries into the help file. I’m going to say something that is perhaps not so popular when dealing with open source software. My job is to create software for sale. I don’t have time to peruse the code of an open source tool to figure out how it works-I want documentation. If a development tool has insufficient documentation then it’s not going to be used. Documentation is important to me and I’m going to supply it.

So where to next? I have enough structure in place to start the actual test application; the DevLynx Address Book. The next task is to set up a database and start using the framework. As framework issues arise I’ll make modifications to ensure that it meets the goals.

dlx

Dec. 8th, 2007

DevLynx

Source Code Release

I have consolidated all changes to date for another source code release. Since my work on the CAB and Developer Express components is a work in progress there will be breaking changes in this code. Most of the code releases that I will publish in the next months will have breaking code changes. I apologize in advance for this inconvenience.

This release includes all changes since the last source code release, the items mentioned in my Dec 2, 2007 entry as well as an additional UIElementAdapter for the Ribbon Quick Access Toolbar. I also changed the name of the ApplicationMenuUIAdaptor to RibbonApplicationMenuUIAdaptor so that all of the Ribbon centric classes are prefixed with ‘Ribbon’.

The RibbonQuickAccessToolbarUIAdapter code follows:

using System;

using Microsoft.Practices.CompositeUI.UIElements;

using DevExpress.XtraBars;

using DevExpress.XtraBars.Ribbon;

using Microsoft.Practices.CompositeUI.Utility;

 

namespace CABDevExpress.UIElements

{

    public class RibbonQuickAccessToolbarUIAdapter : UIElementAdapter<BarItem>

    {

        private RibbonQuickAccessToolbar ribbonQuickAccessToolbar;

 

        public RibbonQuickAccessToolbarUIAdapter(RibbonQuickAccessToolbar ribbonQuickAccessToolbar)

        {

            Guard.ArgumentNotNull(ribbonQuickAccessToolbar, "ribbonQuickAccessToolbar");

            this.ribbonQuickAccessToolbar = ribbonQuickAccessToolbar;

        }

 

        protected override BarItem Add(BarItem uiElement)

        {

            Guard.ArgumentNotNull(uiElement, "uiElement");

            if (ribbonQuickAccessToolbar == null)

                throw new InvalidOperationException();

 

            ribbonQuickAccessToolbar.ItemLinks.Add(uiElement);

            return uiElement;

        }

 

        protected override void Remove(BarItem uiElement)

        {

            Guard.ArgumentNotNull(uiElement, "uiElement");

            if (ribbonQuickAccessToolbar == null)

                throw new InvalidOperationException();

 

            ribbonQuickAccessToolbar.ItemLinks.Remove(uiElement);

        }

    }

}


As I mentioned in the Dec 2, 2007 entry, I have added support for both common command images as well as command overlays images. Images that I use have been purchased from glyFX and, therefore, I cannot release the actual images. I have blurred the images (using ImageMagick) so that I could include placeholders in the source distribution. You will have to replace these blurred images with your own if you choose to use the command images and overlays.

You will find the source code at:
http://s3.amazonaws.com/DevLynx/2007 12 08 DevLynx CAB Deployment.zip

You will also find an updated PDF of this blog series at: http://s3.amazonaws.com/DevLynx/LiveJournal Blog.pdf

dlx

Dec. 2nd, 2007

DevLynx

Status Update

It’s been two weeks since my last entry. I have been busy with the day job as well as other personal matters. So, I have not had a great deal of time to contribute to the project. Some of the issues that I have worked on:
•    Removing the Source/Infrastructure directories in the ShellApp. Since the ShellApp is going to be shared and no other modules placed into the solution it seemed wrong to have the additional directory levels. So I flattened out the directory structure.
•    In the previous released source of the ShellApp I had placed our standard copyright notice from the day job. This has been replaced with the MIT License so that others can legally use my additions.
•    Added structure to centralize some of the common command images that are invariably in most projects. This way when someone demands something silly like  “We must change the ‘cut’ command image to a bloody butcher’s knife?” it can be done in all projects at once.
•    Added command overlay images. At work I always seem to be the one who creates command images. I know, we should get a graphic artist to do this - and actually we have access to one now! I have spent untold hours creating various images for our commands (they were adequate but I am not an artist). One of the things that takes so much time are what I call overlays. An overlay is a small command image modifier such as a plus sign for ‘add’. For instance a ‘Project’ command will have modifiers for add, delete, edit, import, export, make it spin around on it’s head three times, etc. I always do this with a base image and the modifier is placed in the lower right hand corner. When someone asked for an overlay replacement I would have to go in and change many command images. Now overlays can be placed on the image automatically, are easy to change, and are consistent across commands and projects.
•    Created automated builds using FinalBuilder.
•    I have set up FogBugz to use as an issue tracking system and have started to track issues.

In other words, I have not been completely idle. My next step is also going to be more structure. I will be adding unit tests and doing code coverage. So it probably won’t be until after the holidays that I have more features implemented.

dlx
Tags:

Previous 10 | Next 10