Very strange problem - inherited properties reset

[James Donnelly]

I''m experiencing a very strange problem with the DateTimePickerAdv control. I''ve derived a control (BaseDataDateTimePicker) from the DateTimePickerAdv control, in a separate project, and am using the derived control in my main project. I do this for all the controls I use (adding custom properties).

A while ago, I noticed that my BaseDataDateTimePicker controls placed on various forms would reset the "ShowDropButton" property (set to "False") every time I compile the solution. The back color would also be set to "Beige". Two other properties, "ShowCheckButton" and "IsNullDate", did not have this problem, and would maintain the non-default values set in the base control ("False" and "True" respectively).

This first happened while I was using 1.6.1.8, and it is still doing it in 2.1.0.9. I am using Visual Studio.NET 2003.

One clue is the setting of the backcolor to "Beige", which is the backcolor of the GroupBox that contains the base control. This is a key clue because I never modified this property of the base control until I noticed my base controls turning beige. Then, I went to the base control and hard set the backcolor to "white". Still, every time the solution compiles, the backcolor is reset to "beige".

This really sucks, and I have no reason to believe it''s the fault of your control as opposed to some fault of Visual Studio, but does anyone have any ideas, or experienced this before?

Help.

[James Donnelly]

I should clarify that the derived control sets the "ShowDropButton" and "ShowCheckButton" properties to "False", and the "IsNullDate" to "True".

After compilation, only the "ShowDropButton" is reset back to its default value ("True"), while the other two properties maintain their derived setting.

Further, the backcolor property reverts to that of the group box it is contained on.

[James Donnelly]

Stranger still, the .vb file clearly designates that the backcolor should be white and the ShowDropButton property should be "False".

Even when I close and reopen, the .vb file has the appropriate setting, but when viewing the form it shows the backcolor as "beige" and shows the drop button.

Another clue is that, although the .vb file text is correct, after the odd stuff happens (on compile) the property window of the form mirrors what I''m seeing (showing backcolor as "beige" and ShowDropButton as "True"), so there is a mismatch between the text in the .vb file and the properties window and what you see.

This doesn''t make any sense...

[James Donnelly]

Actually, if I modify the form in the designer, and save, then it makes the adjustment to the .vb file. I was a little quick on that in the last response.

So, if I open the form in Designer, and change the properties manually to what I want them to be (the same as designated in the base control), then save and close the form, then compile and run the application, I will see the properties revert back to whatever VB.net seems to want them to be ("beige" and showing the drop button).

Then, if I close the application down, and just open up the .vb file for the form in question in code view, it shows the properties I want, not the ones it shows on the screen!

But, if I open the form in Designer, and make a change and save it, then it alters the .vb file to show the property settings it is actually showing.

Also, the backcolor issue is definitely related to the GroupBox, as I changed the backcolor of the GroupBox to Khaki, and now the control automatically becomes "Khaki" instead of "Beige" when I compile.

[James Donnelly]

Because the 1.6.1.8 version of DateTimePickerExt did not have a ReadOnly property, I implemented a "ViewOnly" property for it in my derived control. For whatever reason, in the "Focus" event of the derived control, .NET did not like the fact that I was do a check on the value of this control. It seemed to be erroring out when checking the boolean value, which was by default set to "False" and should have worked correctly. But when I commented out the If, the End If, and the Else part of that event (a MsgBox informing the user that the control was ViewOnly), the strange behavior stopped.

Sorry for the diversion.

[Administrator]

Hi James,

Were you using a DesignMode check in your custom code to prevent it from firing in the Designer?

Regards,
Gregory Austin
Syncfusion Inc.