I've created a UserControl derived class which contains a TabControlExt object. I gave the tab control "protected" visibility so I could set it's properties in VStudio's visual designer. In particular, I wanted to be able to add new tabs using VStudio (as opposed to adding code and setting tab page properties manually).
This works pretty well, but VStudio insists on setting
this.m_tabControlExt.TabCount = #;
in InitializeComponents() where # is the number of tab pages. This means that every time I edit the control with VStudio's designer I have to comment out this line of code because TabPageControlExt.TabCount is read-only.
Is there a better way to get around this?
ADAdministrator Syncfusion Team August 2, 2002 07:50 AM
Seems like a bug in VS where it assumes a "set" property even when it is not implemented.
We could force this to not happen applying the DesignerSerializationVisibility.Hidden attribute in the TabCount property.
Look for this in our next release (due early next week).
RMRoy MullerAugust 2, 2002 10:38 AM
You guys are good :-)
I really appreciate the quick and accurate responses to problems that I post here. I haven't had this kind of service since working with Qnx (http://www.qnx.com). Thanks!
ADAdministrator Syncfusion Team August 5, 2002 01:38 PM
Also, please open a Support Incident if you want a workaround for the "context menus not showing on key press" issue.
ADAdministrator Syncfusion Team August 5, 2002 01:39 PM
Sorry, updated the wrong incident :)
RMRoy MullerAugust 20, 2002 10:31 AM
It looks like this fix slipped through the cracks of the 18.104.22.168 release :-(
Is this fixable in the next release?
ADAdministrator Syncfusion Team August 21, 2002 07:35 AM
We did add the DesignerSerializationVisibility.Hidden attribute to TabCount. I tried reproducing this problem in a sample and the designer didn't insert the TabCount with our current version.
Could you possibly be linking to an older version of our lib? If not, could you open a incident and attach a sample?
RMRoy MullerAugust 21, 2002 07:44 AM
It is likely that I was using the previous (22.214.171.124) version of syncfusion; see my post in the General forum, subject "Modified Syncfusion Source and Updates". I thought I was current; I'm sorry for the false alarm.