The readers of this blog had provided great feedback. We would like to consolidate our customer reach. As part of that effort, I will be closing this blog. I kindly request you to follow our team blog at http://blogs.msdn.com/classdesigner. Please continue providing us your inputs so that we can build great products for you. Once again thanks for sharing your thoughts here.

Our team will be holding MSDN online chats on Feb 1st. You can chat with the team that builds Class Designer.

If the above link doesn't work then go to http://msdn.microsoft.com/chats/ and enter chat room for "Visual Studio - Class Designer"

Thanks in Advance.

Thanks for all the mails sent by the readers enquiring about the long silence. I took a long vacationJ. I started to learn to ski this season. But unfortunately this winter season seems to be a disappointment for ski enthusiasts.

I will continue to keep you posted on how the Class Diagram is shaping and keep requesting you for feedback on issues we face.

When I started this blog some readers were saying that C++ is a dying language. Here is a related post http://www.microsoft-watch.com/article2/0,1995,1684756,00.asp

Last week we had an intra team challenge. Our manager offered to put on the apron and grill some bbq if we hit some phenomenal bug fixing goal he set. We strapped ourselves to the seats in our offices and took up the gauntlet. Glad to inform you that we succeeded and I hope he makes something good and make us feel that it was worth the sleepless ride last week.

Here is a question I received from Bryan Rieger… click here

Bind Dependency?

            Click here and this page gives a good explanation of bind dependency.

Here is an example we will use…

            generic<typename T>

            public ref class Collection{};

            public ref class Class1

            {

                        Collection<float> myFloatCollection;   

            };

Answering Bryan’s questions…

Would the Collection<T> be modeled as a parameterized class?

            Yes. To view the parameterized class... click here

If it is modeled as a parameterized class, will you be supporting bind dependency?

            Yes. In the Class Designer shown in the link, you right click on field FloatCollection and select “Show as Association”. To view the UML equivalent bind dependency created… click here

Here is my own follow up question…

If we model templates and generics as parameterized classes how do we differentiate them in the model?

            I created a template class called Container. I have juxtaposed the Collection generic class and the template Container class on the designer. They both show as parameterized classes but check out the title right after the class name… click here

Say I have the following code in

Employee.h

namespace Company

{

     class Employee {};

}

Manager.h

namespace Company

{

     class Manager {};

}

When the user drags an inheritance line between Manager and Employee, we will generate the following code in Manager.h…

Manager.h

namespace Company

{    

     class Manager : Company::Employee {};

}

Your feedback on the following issues will be appreciated.

1. Note that we didn’t generate the “#include Employee.h” in Manager.h file. Would it be reasonable to assume that the user will have to deal with inserting proper include statements in the Manager.h file?

The following are some of the reasons that deter us from doing it ourselves

·        Redundant #includes may introduce clutter, may cause compilation errors

·        It will be difficult to find the correct path to Employee.h

·        What if the user #includes everything in a precompiled header

·        What if the #included header requires other #includes before it?  Many headers do not embed #includes for dependent headers, instead relying on the .cpp to #include the dependent headers separately. We cannot figure out what is ‘right’ without a proper dependency graph.

·        Yes what we generated won’t compile but at least we just did what the user requested. It is in a better state, than actually generating something more than what the user requested and that causing more compilation errors.

2. Would you prefer that we generate “Company::Employee” or just “Employee” as the base name? If we do the short name the generated code will be…

namespace Company

{

     class Manager : Employee {};

}

Finally I have managed to link to some pictures.

A complete picture with C++ Class Designer flanked by other tools that complement it - http://www.winisp.net/rakeshnamineni/images/Everything.jpg

The Class Designer - http://www.winisp.net/rakeshnamineni/images/Designer.jpg

The Class Details window –

http://www.winisp.net/rakeshnamineni/images/ClassDetailsWindow.jpg

The Toolbox - http://www.winisp.net/rakeshnamineni/images/Toolbox.jpg

The Class View - http://www.winisp.net/rakeshnamineni/images/ClassView.jpg

The Property Page - http://www.winisp.net/rakeshnamineni/images/PropertyPage.jpg (Note that I had posted that all of this would be ReadOnly)

While trying to scope the support for Templates and Generics in Class Designer, I wanted to know the difference between them. I came across this posting by Brandon Bray, who is a Program Manager in C++. Hope you find it useful as well.

Type overloading of generics is allowed in C# and VB.

For example in C# overloading of the generic type is possible.

public class Bar <T> {}

public class Bar <R, S> {}

I recently heard from Brandon that C++ will not be able to support this for Whidbey.

I have to agree that in the recent weeks as more and more people have started using C++ CD, we have observed a spike in our incoming bug rate. I had a discussion with my Program Manager over lunch yesterday about how we should manage our C++ CD deliverable.

We had a couple of options

Keep the breadth of the features offered by C++ CD, but raise our triage bar. This means that a lot of bugs wouldn’t qualify to get fixed.

                              OR

Cut some features and try to keep the quality of the delivered tool high. This culminates in features delivered, even if lesser than promised set, being solid.

We are leaning towards option 2. We would like to cut some implemented/semi-working features. We would like to concentrate on features that offer “good” value for C++ developers and make them robust.

We have gotten feedback that C++ developers wouldn’t prefer to use the “Class Details Window”. It is a grid based tool window. The developers would rather type the method signature in code editor.

This feedback is making us reevaluate our promise on the abilities of Class Details Window and the Properties pages. We are thinking of making Class Details Window and the Properties pages read only.

So if we do this, then C++ Class Designer would offer

1.      Create types (managed and unmanaged)

2.      Create and modify Inheritance relationship between types

3.      Visualize Associations to other types

4.      Visualize Implemented Interfaces (as lollipops on the shape)

5.      Visualize a types’ members and the members’ constituents

6.      Visualize the characteristics (virtual, abstract, sealed etc) of a types’ Members

7.      In managed projects browse and view details about types from referenced assemblies.

8.      The designer will give you the ability to jump from the designer to code and from code back to the designer.

9.      Visualize Attributes and XML Comments

We cut L

1.      Ability to create/modify Members of a type

2.      Ability to create/modify Associations to a type

3.      Ability to generate stubs for inherited Interfaces or Abstract Types

4.      Ability to override members of a base type from the designer

5.      Ability to create/modify Attributes and XML comments.

I would appreciate feedback on our approach. Thanks.