DevExpress PopupLookUpEditForm problem
Hi All, I am testing C# application and the developers uses the same 'DevExpress.XtraEditors.Popup.PopupLookUpEditForm' all over the place they just assign different databinding in differe...
Forum Discussion
The only additional information I've been able to collect since my last question is that the PopupLookUpEditForm object is just underneath the system process in the hierarchy. It seems that with each individual LookUpEdit control from DevExpress, the actual popup part of the control is one object shared with all the LookUpEdit controls throughout the system. The options are just repopulated based off of which control has focus. The alias given to this PopupLookUpEditForm always seems to refer to the instance of this corresponding to the first LookUpEdit control that was focused or interacted with.
Now here is a workaround that I came up with that I would NOT recommend. After recording the test, using multiple LookUpEdit controls, if you follow the statement that calls PopupLookUpEditForm's Click() method with a statement that calls PopupLookUpEditForm's Dispose() method, the PopupLookUpEditForm seems to "recreate" itself each time it is called upon from another LookUpEdit control. This allows my tests to pass, but I do not like this workaround because it already causes my application to run differently under TestComplete than it does by itself at run-time. I would assume it is bad practice to have your test validate an aspect of your application by using the application in a manner that is different from an actual user making the same actions as the test.
Has anyone been able to come up with another workaround for this that still follows best practice?
Now here is a workaround that I came up with that I would NOT recommend. After recording the test, using multiple LookUpEdit controls, if you follow the statement that calls PopupLookUpEditForm's Click() method with a statement that calls PopupLookUpEditForm's Dispose() method, the PopupLookUpEditForm seems to "recreate" itself each time it is called upon from another LookUpEdit control. This allows my tests to pass, but I do not like this workaround because it already causes my application to run differently under TestComplete than it does by itself at run-time. I would assume it is bad practice to have your test validate an aspect of your application by using the application in a manner that is different from an actual user making the same actions as the test.
Has anyone been able to come up with another workaround for this that still follows best practice?
Concerning this case, SmartBear support found a solution, here it is:
I've checked your project suite and I think I know what happens. According to the screenshot associated with the error message, there are multiple dropdown controls on the same screen of your application. As far as I know the DX controls implementation, this means that each of the controls has its own dropdown window associated with it. Therefore, the Aliases.Horizon.PopupLookUpEditForm object may refer to any of those dropdown windows, not necessarily the only one which is currently displayed on your screen. I believe the "The window is invisible and thus cannot be activated" error occurs because the recognition criteria of the Aliases.Horizon.PopupLookUpEditForm object are not unique and therefore TestComplete obtains an invisible dropdown window, not the one you need, during test playback.
This problem should be easily resolved if you add the Visible=true and/or VisibleOnScreen=true criterion to the list of properties used to identify the Aliases.Horizon.PopupLookUpEditForm object in your Name Mapping scheme (see the "Adding and Removing Identification Properties" (http://smartbear.com/viewarticle/75986/) help topic for more information). This way, the Aliases.Horizon.PopupLookUpEditForm alias will always refer to the dropdown window which is currently displayed on your screen. Does this help?
Regards,
Aleksey Kolosov
SmartBear Customer Care
