Monday, September 29, 2008

Object Identity (Make Object ID)

In Visual Studio for C# there is this cool feature (Make Object ID), which allows you to assign an ID to the object you're debugging. it is very important to note that the object has to physically exist before you can assign an ID to it. so, you can not make this at design time. Even at run time you can not create the ID before the object has been created.

Here is how to use this cool feature given the following program.

            StringCollection ls = new StringCollection();
            ls.Add("ayman");
            ls.Add("ayman");

            foreach (string ss in ls)
            {
                MessageBox.Show(ss);
            }

The foreach loop above declares a string called ss. this ss is not the same ss every time a loop cycle is created. to enjoy the pleasure of seeing this fact, you can set a break point at the foreach line, and then when the debugger stops at the foreach line click F10 once so that ss is created and then hover over the variable ss. at this time, right click and choose "Make object ID" as per the picture below (notice that the debugger has executed the foreach line already and is about to enter the foreach block)



There is also delete object Id if you care to use it.

Friday, September 12, 2008

SCSF Events (One firer and multiple (Not wanted) subscribers)

So when working with SCSF you may face a problem like this.

You have built two views as part of a module (View1 and View2). View1 fires an event that View2 is  subscribed to. this all seems very legal until now. but what if View2 and View2 are loaded and displayed more than one time. now comes the illegal part. every time any of the View1 fires the event, all instances of View2 will receive it and react to it.

To illustrate it even further, assume you have built a hospital application that consists of two views. SearchView and DisplayView. the search view allows the user to search for a patient by specifying part of the patient name. but the SearchView does not display the search result, it is the DisplpayView that displays the results after receiving the Event showResults. now when the user types part of the patient name and click search, the event ShowResults will be raised and DisplayView will receive it. DisplayView will use the EventArgs to find the patient and then display him/her. the problem happens if you loaded two of the SearchView and two of the DisplayView. now when you type part of the paient name in any of the SearchView loaded and click Search, both of the loaded DisplayView will receive this event and will display this patient.

The solution to this problem is to make your module create a new work item every time it wants to add views. then add the views (SearchView and DisplayView) to this new work item.

when you fire the event you fire the event to the subscribers within the work item.
Here is how.
in your ModuleController.cs declare a new workitem as follows

WorkItem instancewi = new WorkItem();

Next, in the AddViews method add this new workitem to the WorkItems collection of the current item

instancewi = WorkItem.WorkItems.AddNew<WorkItem>();

now when adding views add then in this new workitem as follows

instancewi.SmartParts.AddNew<WhateverYourViewIs>();


now when firing an event, you should always be limiting the scope to the work item using PublicationScope.WorkItem enumeration and specifying the current workitem as follows

WorkItem.EventTopics[WhateverYourTopicIs].Fire(this,new EventArgs(WhaeteverWahtever), WorkItem, PublicationScope.WorkItem);

This way when you fire an event from one view, only the other views that were loaded with the same view will receive this event, since they are in the same workitem.
Hope that helps.

CAB/SCSF Visualizer

So I have an announcement to make: if you are a programmer working in 2008 and you don't know the basics of SCSF and the Visualizer, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will.

The SCSF/CAB visualizer allows you to see interesting facts about your Workitems. I used it recently to debug and solve a problem in an application that I will be talking about in a next post. The visualizer allows you to see what your currently loaded work items are and shows the hierarchy that the object builder have built for you.

you can still see the same thing using the usual debugger as per the screen shot below, however the visualizer will make it easier for you since you do not need to stop and look for your root workitem to examine its contents. the visualizer will grasp the root workitem for you and will monitor it at all times. 



The screen shot below shows what the Visualizer screen looks like.


The visualizer shows you the root Workitem and its known collections (Items, UIextensionSites, etc..). using the WorkItems collections within the root workitem you will be able to examine what views are loaded and the relationships between your Views and workitems

one interesting thing I notices working with the visualizer is that you can double click a view and the Visualizer will show it to you in the WorkItem Visualization window. even more, it will allow you to interact with it.

To use the visualizer you need to download CAB Visualization Tool which is a dll from here

Copy this dll into your output folder (or add it as a reference in your Shell application) and then  change your app.config (shell.exe.config) by adding the following lines appropriately within the noted sections.


all you need to do after that is to start your application, magically the visualizer will appear and will show you the details of your CAB/SCSF application. neat eh?