C1 Community

mwinsor:

C1_GregL:

When inheriting C1Command, ALL c1command related members (C1CommandHolder, C1CommandLink, C1CommandMenu and C1Command, etc) must be declared public in the base control. This can be done by setting the modifiers properties to public for each C1Command control.

Regards

Greg

I did this and so far so good.  The latest and greatest version that I could get (2.0.20081.19402) seems to be behaving itself.  The only downside to this is that all my controls now show up in my Misc. category of my property pane :)  This isn't a big deal really, I'd rather that than the errors I was getting before.

 So after further experimentation, I got the dreaded System.ComponentModel.Component not marked as Serializable error again.  Here's the scenario:

1. I have a user control with a C1 toolbar and the command holder.
2. I inherit this user control to create a new user control, the C1 toolbar is marked as public as is the command holder.
3. I create a form from a base form that has a C1 toolbar.
4. I plant a new instance of the control (step 2) on the detail form (step 3) and I get the error.

With the form that inherits the base form with the C1 toolbar in step 2, it's fine, the inheritance works beautifully.  For all direct inheritance to other controls and forms, it's fine as well.  But if I plant a control that's inheriting C1 controls, it breaks.

With the 200603 version this was not an issue, everything worked as I expected (there were minor issues with inheritance and collections, but nothing fatal).  I'd hate to have to roll back to that version. 

This is a do or die thing for my company, we need this level of functionality for our applications.  Is there any suggested workaround?  I require that this be workable from the designer as we have complicated design time functionality built into the control that would be a hassle to create code for, especially with large numbers of these forms and controls.

I still have the same issue and desperately looking for some resolution as this is becoming business critical. Please can we have this fix in the recent version so we do not have to go back to old version to use it. We are still using older version as mentioned in my earlier post. 

CampOne:

I still have the same issue and desperately looking for some resolution as this is becoming business critical. Please can we have this fix in the recent version so we do not have to go back to old version to use it. We are still using older version as mentioned in my earlier post. 

The support here isn't exactly stellar.

Anyway, I figured out how to fix the issue and here's how you do it:
1.  Mark your component one control(s) with collections (or all of them) as private and remove the WithEvents.
     e.g. Private WithEvents myC1Holder as C1CommandHolder
2.  Create a property (protected or public and readonly unless you need to swap the component out at design time) that will allow access to this control.
     e.g. protected readonly property CommandHolder as C1CommandHolder
               return myC1Holder
            end property
3.  Then, above the control declaration in step 1 place the following code:
     <System.Runtime.CompilerServices.AccessedThroughProperty("CommandHolder")> _

You may have to do a bunch of manual clean up after to change the name of the control in the inherited form (i.e. myC1Holder.Add() would now be CommandHolder.Add()).  Also there are drawbacks to using this method.  For example, you cannot declare your controls using WithEvents anymore (I'm not sure on why this is, if someone could provide a solution/explanation, that'd be swell).  Plus in some instances, like with the System.Windows.Forms.TabControl I noticed that this method killed the interactivity with the designer, and switching between tabs in design mode was impossible (this could be unrelated, I didn't have time to really test it and I put it back to use the standard inheritance since it was working all this time anyway).  To get around the WithEvents problem, you can manually add events to your constructor via AddHandler.  It's a pain, but it works (and you should also probably should remove those events with RemoveHandler in the Dispose method just to be safe).

 A lot of recommendations I've seen have leaned towards not using visual inheritance at all, and I can certainly understand why.  I wish they (Microsoft) had warned us of that at the beginning or better yet, disabled it instead of perpetuating what is essentially a broken system.