Syncfusion windows.

[Arash Yazdanian]

Hello All,

We are using a testing software called TestComplete to test our .NET application. TestComplete is having problems recognizing just the syncfusion windows in its object browser. Is there a way to set Native Names for syncfusion windows?

Thanks in Advance,

Arash

[Prakash S]

Hi Arash,

Most, if not all, Essential Suite controls are instances of the Windows Forms Control type and subscribe to all the standard .NET conventions governing Class Libraries. Just to be sure that the problem is not exclusive to the Essential Suite components, please try creating a sample Windows Forms DLL that implements a custom control, add this control to your app and see whether the TestComplete software recognizes the component.

Also, please elaborate as to what you mean by 'native name'? If you are referring to the Win32 window text, then invoking the ::SetWindowText() API on the window handle of the Essential Suite control is a straight-forward PInvoke procedure.

Prakash
Syncfusion

[Arash Yazdanian]

Prakash,

It appears that we are only experiencing problems with Syncfusion controls - our own custom controls behave correctly.

"Native Name" is how TestComplete identifies different windows. It appears to be related to the "Name" property of a control.

Ideally we need to be able to uniquely identify toolbars, menus and docking panels. Currently these controls have no "Native Name" and so TestComplete generates a name, e.g. "Object_2", for them. The problem with this is that if a control is hidden when the application starts the numbering of all the other visible controls is different.

I tried your suggestion, however, it is hard to get access to the all of the windows which syncfusion creates internally. I did manage to get access to the toolbar control and the following line of code does fix our problem.

mainFrameBarManager.GetBarControl(barMainMenu).Name = "Test";

However, I was unable to do the same for any of the other controls. It would be nice if some kind of naming could be incorporated into syncfusion.

Thanks.

Arash

[Prakash S]

Hi Arash,

My apologies for this delay in responding to your update. If TestComplete is just expecting all controls, whether they are exposed or not, to have unique values for the Control.Name property, then it is understandable as to why it gets bogged on some of the Syncfusion controls. The Essential Tools framework components such as DockingWindows and XPMenus create several controls internally for hosting the application's client controls and these host controls do not have a 'Name' value assigned. We have logged this as a QA report and starting with the forthcoming 2.0 release, will provide the Name value for all the internal controls as well. I assume this should take care of your problem.

Thank you for bringing this to our attention. Please do let us know if any other issues need to be addressed for TestComplete.

Prakash
Syncfusion

[TimMikr]

> Hi Arash,
>
> My apologies for this delay in responding to your update. If TestComplete is just expecting all controls, whether they are exposed or not, to have unique values for the Control.Name property, then it is understandable as to why it gets bogged on some of the Syncfusion controls. The Essential Tools framework components such as DockingWindows and XPMenus create several controls internally for hosting the application's client controls and these host controls do not have a 'Name' value assigned. We have logged this as a QA report and starting with the forthcoming 2.0 release, will provide the Name value for all the internal controls as well. I assume this should take care of your problem.
>
> Thank you for bringing this to our attention. Please do let us know if any other issues need to be addressed for TestComplete.
>
> Prakash
> Syncfusion
Did you know where I can find full version of testcomplete 2 or 3? Or can you mail to me a rar password of it???

[Administrator]

>Hi Arash,
>
>My apologies for this delay in responding to your update. If TestComplete is just expecting all controls, whether they are exposed or not, to have unique values for the Control.Name property, then it is understandable as to why it gets bogged on some of the Syncfusion controls. The Essential Tools framework components such as DockingWindows and XPMenus create several controls internally for hosting the application''s client controls and these host controls do not have a ''Name'' value assigned. We have logged this as a QA report and starting with the forthcoming 2.0 release, will provide the Name value for all the internal controls as well. I assume this should take care of your problem.
>
>Thank you for bringing this to our attention. Please do let us know if any other issues need to be addressed for TestComplete.
>
>Prakash
>Syncfusion

[Administrator]

>Hi Arash,
>
>My apologies for this delay in responding to your update. If TestComplete is just expecting all controls, whether they are exposed or not, to have unique values for the Control.Name property, then it is understandable as to why it gets bogged on some of the Syncfusion controls. The Essential Tools framework components such as DockingWindows and XPMenus create several controls internally for hosting the application''s client controls and these host controls do not have a ''Name'' value assigned. We have logged this as a QA report and starting with the forthcoming 2.0 release, will provide the Name value for all the internal controls as well. I assume this should take care of your problem.
>
>Thank you for bringing this to our attention. Please do let us know if any other issues need to be addressed for TestComplete.
>
>Prakash
>Syncfusion