by: Miha MarkičPosted on:

Mother of all Visual Studio 2005 RTM bugs

Sit down, this one is huge.


Apparently Microsoft doesn’t have Windows Forms Designer support for complex controls on derived forms, in other words, if you created a form with a complex control (DataGridView is perfect candidate), made this control protected or more, derived a new form then you have problems. Nasty, huge problem if this is caused by a bug in Windows Forms Designer in 2005. The control on derived form is readonly (1) for designer – no more visual editing. Even worse, if you implemented control’s events on derived form with previous Visual Studio 200x versions designer will yield an exception (2). And this “feature” affects third party controls, too. This bug is a joke compared to this “lack of feature”.


In my view, this lockdown feature is horrible. I always used visual inheritance with 3rd party and it always worked just fine. Needless to say that this impacts design of my application tremendously. Again, if this is a new problem in WFD this has to be fixed as soon as possible – Microsoft, please?


UPDATE: The situation is unclear so far. It isn’t clear so far what is wrong with designer and if this problem was introduced with Visual Studio 2005 or if it was there before in 2003 or even 2002.


UPDATE: I checked and saw that DataGridView was locked even in beta 2 this leads me to the conclusion that the problem was always there in VS 2005.


UPDATE: To be more precise, it is up to the control itself to deny its editing in designer when it is inherited.  The readonly status was therefore implemented by Microsoft (in case of DataGridView and ToolStrip) or Developer Express guys (in case of XtraGrid, XtraBars and few others).


UPDATE: I checked the Prouduct Feedback Center and of course, I am not first person to notice this problem. This is one of the MS’ response on the subject:
“Thanks for your problem report. I understand your frustration around this issue, but we disabled this scenario intentionally. We chose to not make the engineering effort it would have required to enable this scenario for Whidbey. This decision was not make lightly and we understand customers would like this functionality, but the existing visual inheritance architecture in combination with collection based controls makes it extremely costly to address. We hope to enable this in future versions. Until then, you’ll have to use code to achieve this. Thanks again for your support of Windows Forms and ToolStrips.” See the entiries here, here and here.
Now, my only hope is reduced to the fact that this problem might have been around since previous Visual Studio versions (and for sure it has been around since 2005 beta 2) which means, that, when carefuly using designer you shouldn’t have problems (assuming  as I worked with Developer Express controls normally until they disabled editing in the last version.


Funny – I would be happy to know that this bug has been around for a while.

30 thoughts on “Mother of all Visual Studio 2005 RTM bugs”

  1. Hi –

    [I tried leaving a comment on Sahil’s blog to this affect but I’m getting an error from the comment link.]

    Yeah, as the Product Feedback reply says this is actually by-design but it doesn’t do a really good job of describing the reasoning behind it. It’s more than just “we didn’t want to spend the money” than it is about scenarios where Visual Inheritance has broken down in the past and gotten lots of users into trouble. I’m going to get someone to write up the real details here, but in general VI doesn’t handle collections well, and DGV and ToolStrips are all about collections. In short, the issue is that the designer can’t always do the right thing if a collection gets modified in the derived from. Generally, if the collection contains value types, it’s a real problem because you can’t use reference values (e.g. ==) to identify which ones came from the original form, and which came from the derived one when it comes time to spit the code again. What’s more is that the designer can’t generate “remove’s” so if you delete items in the derived form, there’s no way to apply that delta, and generally it’s just sometehing that can get ugly fast.

    So (if I recall correctly), we locked down derived collections in general and the DGV/Toolstrip stuff specifically for these reasons.

    The original scenarios for VI were really pretth basic – we wanted people to be able to create templated base forms and then kind of add other controls and things in the derived form (not control collections work a little better since those things are sited and designer has a lot of ways to figure out which came from where). People found a bunch of other interesting ways to use VI that it wasn’t really intended for and it’s gotten a lot of them in trouble, and we’ve spent a lot of time supporting it and/or trying to fix some of those things, and it’s never quite right – you get in to mutually exclusive situations where fixing this or that breaks another scenario and you can’t have it both ways.

    A funny side story here is that way back when, Anders Hjeilsberg (Inventor of C# and generally someone who it’s a good idea to listen to) told us that we shouldn’t do VI to begin with because it would never handle everything right…sigh…

    Anyway, sorry this is a shocker but I can say that it’s not a bug that slipped through.

    Thanks,

    Shawn
    Development Manager
    Windows Forms Team

  2. Hi Shawn,

    I changed the status of that post to unpublished :), maybe thats why you were getting the error.

    Anyway, collections containing value types being a problem is totally something I can relate with.

    Thanks for the explanation though. I did notice that Visual Inheritance which was being pumped a lot in 2002 was barely mentioned afterwards. In fact, in 2005 it was rarely ever spoken about.

    Would it be safe as a guidance to say “Stay away from VI”? or thats too much of a blanket statement?

    SM

  3. Hi Shawn,

    First, let me thank you for the description of the issue. I’ve suspected that this is the only problem and nothing new was introduced since Visual Studio 2002 to this problem.
    Let me summarize my point of view on the issue:
    1. I lived with VI since the beginning of VS.
    2. I’ve learned how to properly use it and rarely had a problem which I had to correct in code. What VI does with collections is enough for me. I don’t expect removal from it or any other complex manipulation. Let me show you my basic scenario (simplified, controls from 3rd party): I create a base form, drop a toolbar (with standard items) and a grid on the form – here I put standard functionality. I fill their collections (or add items) using VI on derived forms. Removing items from collection is not an issue for me nor I do expect from VI to do it. I am/was fully aware of the limitations and could live with them.
    3. I can understand your point with supporting people, but hey, Visual Studio is (an excellent) tool – if you don’t know how to use the tool then nobody can protect you. IMO it is wrong protecting not-enough-skilled programmers while constraining professionals. Would you remove lock keyword knowing that many people don’t know how to use it and it often breaks their programs?
    4. What is even worse, that at least one 3rd party decided to follow your direction (haven’t looked at the others) and I hope they’ll reconsider it asap.
    5. Yes, I learned from the feedback center that this is not a bug (ok, it is a “feature” :-)).
    ******
    6. IMO, It would be better to document the VI limitations and let users decide to use it or not and/or add a checkbox to Options saying “Enable VI for collection – at your risk”.
    ******

    Miha

    PS. Anders was wrong – VI works just fine, at least for me 😉

  5. Hi, guys.

    Let’s say you have an application with some 200+ forms, 400.000+ lines of code. ALL forms use one kind of VI or another. There are data entry forms, dialogs, report forms and all that fits in enteprise app.

    So what is (useful) alternative to using VI in an app like this? I can’t even imagine working without it.

  6. David, what kind of components are you using? If you are using MS’ stuff you’ll have problems. If you are using 3rd party then it entirely depends on the 3rd party whether they’ll lock the editing in derived forms (following MS) or not.

  7. Hi,

    I have been using VI since the beginning of VS and I’m doing the same as Miha does. I create a base form, drop the controls, add the basic functionality and then I add the items/collections on the derived forms or sometimes I add some common items in the base forms and share them in the derived ones. I know that VI has some limitations, but I never had any serious problem with them.

    I agree with Miha, why just don’t give to the users the option to enable or not the VI?

  8. After playing with ildasm\ilasm trip I found the small count of places which can be easy modified, so new System.Design.dll allow work with inherited MenuStrips etc.
    Can anybody help :
    – is this legal to use System.Design.dll ?
    – is this legal to publish modified System.Design.dll ?

  9. Hi Cheburashka,

    I am no licensing expert though I would say no to both your questions. Plus who knows what new problems would such a custom-hotfix bring. However, your approach is certainly an interesting one.

  10. New problems which raised is same as before – wrong items ordering etc… but this is problems of windows.forms architecture, which is much good over mfc but very bad in comparing to Delphi CL architecture 🙁

  12. I is, a very nice feature, but i can imagine even better scenario. As far as I can see this is not implemented on tab control and it would be very nice if Microsoft decides to do so because that means that you would not be able to put controls on anythhing on inherited forms but on panel, form itself or existing tabpages. It would be very nice to know if tabpages collection is accesible on inherited forms in runtime on purpose or this is just, a bug which will be corrected by Microsoft in future versions of visual studio in which case I can just sit down and cry

  13. Tom, you has only few ways:
    1. rollback to beta version of .net2
    2. install system.design.dll from beta version of .net2
    3. fix system.design.dll by hand to unlock inherited collections support
    4. find already fixed system.design.dll
    5. sit down and cry

  16. THANKS for having this post here…

    THANKS in caps…

    I see that it is not only the collections that chopped off of VI, EVERYTHING in the base class is locked in the designer if you inherit from a user control, or form… Cannot set any properties in the designer, even “Visible” property.

    SO, am I supposed to implement VISUAL inheritance in the CODE, not VISUALLY?

    Ironic, isn’t it ?

  19. Has anyone suceeded in inheriting a generic type form??? the designer will allways complaint about “The base class ‘MainApp.Forms.frmMasterObjCol’ could not be loaded”, abstract or generic type forms never appear listed when chosing the form to visually inherit from.

    like:

    public partial class Form1 : frmMasterObjCol{…

    where the master form definition is:

    public partial class frmMasterObjCol : Form where T : BaseObj{…

    using an abstract master form yields the same result.

    anyone has a solution for this?

  20. I think that you are out of the luck. Apparently all forms in inheritance chain have to be createble by designer and designer can’t create both abstract (makes sense) and generic forms. The later problem is not addressed at all by Windows Forms designer (generics support) and we can only hope that someday it will be.

  21. I program to the interface with generic type contraints, but it would be very nice to have some abstract/generic type designer inherance capabilities.

    Can’t I just try to derive the designer class and check for generic types or abstract classes before the instance is created and create it a different way? Myabe the designerobj is just trying to create an instance of the abstract class. (just especulating!)

    I guess I’l try that when I have a break.

  22. I don’t understand why every single property of the control that uses a collection is locked from the visual designer. I can’t visually move or resize my DataGridView because it has a collection property? That is rediculous!

    Okay, so Microsoft didn’t have the resources to implement this in the first non-beta release of VS2005, but they still have no plans on implementing it in the future? That is just crappy.

  23. Hi Hippy,

    Well, not every control that has a collection is locked. Normally, only the collection is locked when it contains at least one item if I remember properly. As per more complex controls such as DataGridView – the controls itself decides the locking behaviour (in the code it says – hey, I want to be disabled when on derived form/usercontrol).
    Ridicolous? Yes.
    What can I say other than go with a 3rd party that support VI (hint: Developer Express).

  25. Hi Akbar,

    Interesting solution which (probably) cures issue with MS’ complex controls being disabled. However, there are other limitations out there and there isn’t a simple solution. Thanks for sharing though.

  26. Hi Markic!

    Yes I know that, but it is the way to out. if some one face these limitation then he/she probably need to write his/her custome designer. By the way there is another solution which I have done personally. Is by changing the MSIL of these custome designers. but it is not legal I think so. If some one want to know how/where to make changes then let me know at akbarbuneri[at]gmail.com and I will tell you the secrate.

  27. If you change the designer of your inherited control to ControlDesigner (shove [Designer(“System.Windows.Forms.Design.ControlDesigner”)] above your class) then you should still be able to do basic things like move and resize the control.

    We don’t do any design-time setting up of datasources, so all we need to be able to do is place our controls. This method works a treat for us.

  28. Hi guys…
    I read it all and now I wanted to know how are you fixing it! 🙂

    I’m developing Base Forms for my custom Framework and some og them need to have grids.

    What I’m doing is assign all the properties needed on the derived form by code.
    When it comes to add columns to the DevExpress XtraGrid it becomes a bit nasty, specially thinking on my own scenario that this is a FW and I’m trying isolate these issues from the users…

    Any ideas?

    Thanks,
    Alex

  29. I am doing it by using DX grid (and other DX components) and visual inheritance. One has to be careful to avoid the pitfals, though, such as removing collection items.

Leave a Reply