ComboBoxAdv Type

[Ben]

I was just hoping for some clarification. If I access the type of ComboBoxAdv using the GetType method it returns a System.Windows.Forms.Textbox, which doesn''t make sense to me, I really want the Syncfusion...ComboBoxAdv which is reflected in the Parent property. I''m accessing the control based upon ActiveControl. This is occuring in 2.0.4.0. I''d like to work with 2.0.5.0 but the evaluation version has not been updated still it appears and before purchasing the upgrade from 1.6.1.8 trying to see how much code rework will be required.

Thanks
Ben

[Administrator]

Hi Ben,

I have tested for this issue in our latest release, v2.0.5.0 and the GetType method correctly returns the ComboBoxAdv''s type as Syncfusion.Windows.Forms.Tools.ComboBoxAdv. I have attached the test sample here. Please test this in v2.0.5.0 and let me know if this meets your requirements.

Regards,
Guru Patwal

[Ben]

I don''t see an attachment

[Administrator]

Hi Ben, Sorry, the attachment did not go through correctly in my previous response. I have reattached the sample here. We appreciate your cooperation, and thanks for choosing Syncfusion products. Regards, Guru Patwal Syncfusion, Inc.

[Ben]

Guru, I made a change to the file you attached and called GetType using ActiveControl on the form when the Enter event fires for ComboBoxAdv and it sort of works correctly. I was unable to test using 2.0.5.0 so I might just be wasting your time, I''ll gladly test again if 2.0.5.0 is available as the evaluation. I tested using 2.0.4.0 and the enter event fires 2 times, the first time returning ComboBoxAdv as the type, and then a second time as TextBox. It appeared that when the enter event fires for ComboBoxAdv control it views the control as 2 controls a ComboBoxAdv with a subcontrol/embedded control of a Windows TextBox. I''ll attach the modified sample, it may require the references to be changed. comboboxadv_type_5774.zip

[Administrator]

Hi Ben,

Thanks for the modified sample application. I have tested this in v2.0.5.0, and could observe that when a ComboBoxAdv has focus and ActiveControl.GetType is used to get its Type, it returns 2 values : "Syncfusion.Windows.Forms.Tools.ComboBoxAdv" and "System.Windows.Forms.TextBox". This could be because the ComboBoxAdv internally uses a TextBox, but since ComboBoxAdv is projected as one single control, ideally the GetType should return "Syncfusion.Windows.Forms.Tools.ComboBoxAdv" only. I have consulted the development team in this regard, and will update you with more information as soon as they get back to me. We appreciate your patience, and thanks for considering Syncfusion products.

Regards,
Guru Patwal
Syncfusion, Inc.

[Administrator]

Hi Ben,

I have consulted the development team on this issue, and would like to inform you the following :

We have to keep the ComboBoxAdv as a Control derived class rather than a ContainerControl derived (like NumericUpDown which internally uses a embedded TextBox) to workaround another bug in the .Net framework. So, if you could elaborate on your requirements we could suggest you a suitable workaround. Thanks for considering Syncfusion products.

Regards,
Guru Patwal
Syncfusion, Inc.

[Ben]

Currently we have an application that displays some field specific information which is provided through provider/extender properties. The property is determined based upon the control type and then the value for that control is extracted and used for display purposes.

Thanks
Ben

[Administrator]

Hi Ben,

Thanks for the above information. I will discuss this with the development team and update you on this as soon as possible. We appreciate your patience and cooperation.

Regards,
Guru Patwal
Syncfusion, Inc.

[Administrator]

Ben,

You mention that the extended-property value is determined based on the control-type, so can you not include the ComboBoxAdv as one of the valid control-types? It would then not matter whether or not the ComboBoxAdv is Control or ContainerControl derived.

Or is the issue that you are excluding all ContainerControl derived controls in your logic and that conflicts with the ComboBoxAdv implementation?

-Praveen

[Administrator]

>Or is the issue that you are excluding all ContainerControl derived controls in your logic and that conflicts with the ComboBoxAdv implementation?
>

That''s correct, current implementation excludes ContainerControls. Right now current implementation is a switch/case statement on ActiveControl.GetType. And it assumes that all the control''s are of derived from control.

[Administrator]

Hi,

I made a mistake in my previous update, where I imply that ComboBoxAdv is deriving from ContainerControl. But that''s not true, it derives from Control.

So, you obviously have a different issue here. Nothing to do with "excluding ContainerControls". Is that right? Please let me know if I missed something.

Regards,
Praveen