Another week and another customer. I have a customer that I built a Outlook plugin for that displays active CRM data. The challenge this weekend was to provide a more updated UI experience with theme switching. There were several hurdles I had to overcome to the current design and problems to solve. To accomplish this task I had to resolve the following

1. Determine the color settings for each theme in outlook and build the appropiate .xaml resource dictionary for the matching theme
2. Theme the controls, extracting templates and updating the resources to point to the custom colors/fonts
3. Reconfigure each of the UI components to use the theme files
4. Create a theme service/switcher to change the themes dynamically
5. Create a service to determine when outlook changes a theme
6. Test and enjoy a donut and coffee

For determining the colors required I took a brute force method. Switching to each theme in outlook, taking a snapshot image and using Gimp to extract the required component colors. There were 4 themes that I attacked Dark, White, DarkGray and Colorful. It did not take long to extract the colors.

For each of the controls such as DatePicker, Combobox, ListBox .. etc I extracted a copy of the style template. I then updated the colors and fonts using the new resources I created. This took some time and tweaking to make sure that rendering was not broken.

The project had many Controls, Panels and Dialogs, each had to be updated to point to the new resource dictionaries. This was not much problem however depending on the location of the resources I had to update the source uri’s appropriately. In the end it work as expected

The interesting part of theme switching was about how the resources were added to the underlying components. Theme switching constitutes replacing one ResourceDictionary for another. For my case I just ensured that the style dictionary was in position 0 in the underlying component’s merged dictionaries. Basically just:

userControl.Resources.MergedDictionaries.RemoveAt(0);
userControl.Resources.MergedDictionaries.Insert(0, resourceDictionary);

I did find have an initial issue as I was not seeing my active changes however when I updated my components to use DynamicResource instead of StaticResource the UI updated correctly.

Digging around the internet to find out if VSTO provided any kind of notification for theme switching led me to an answer of NO. So I kept researching and found out that when Office updates the theme it writes the value to the registry. Given that I could poll the registry for changes I wrote a service to read the UI Theme value and on a change published an event to the outlook plugin. Once the event notification was received the theme switcher updated each of the UI components.

I was successful this weekend in updating plugin to use theming, and added a level of polish and professionalism that I believe my client will appreciate.

So I have this customer who is acquiring businesses at a rapid pace. Usually when this happens integration of systems or migration into the companies systems need to occur. This is where I get involved, as I have a life time of experience with system integration and data migration.

The project at hand was to migrate the data from SFDC into Infor CRM. I had not done a SFDC migration as of yet and was not sure of the effort or my plan of attack, however like all systems when there is a will there is a way. I knew there were tools out there to assist but I had to weigh the costs, time for training and any support for using a tool that ultimately is for a one time effort. So I did what I find most comforting, I rolled up my sleaves and dug in, learning how to extract the data out of Salesforce, doing a full review and creating a import solution for the primary data available. For this specific customer after review it seemed focus was around Accounts, Contacts, Opportunities, and Attachments (Documents).

After reviewing the data export from Salesforce I decided to build a custom service in Infor CRM to do the load. This way I could control the mapping, pre-processing, etc. as well as make sure that any and all business rules are executed ensuring consistent data after the process was completed.

I created the service and some base classes for a import file, so that for each of the entities that had to be imported I only had to focus on the differences in process and have the highest level of reusability. The only really interesting part was the pre-processing I had to do on the exported documents. You see the files are returned without a filetype prefix. This had to be discovered by looking at a .csv file and marrying up the data to the file. I decided to preprocess all the files outside of the Job Service data loader to ensure that the files were readable.

So after a weekend of building, testing and refining the process I was able to import all the data into Infor CRM, and navigate around and confirm all the entities, and their relationships were brought in successfully.

I have to say I do love to code still after all this time, and glad that I could provide great services to another customer. If you have an integration/migration need please do keep me in mind.