Forum Discussion

hema_eltoukhy's avatar
hema_eltoukhy
Occasional Contributor
13 years ago

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 different windows now;



1. how I can make testcomplete recognise each LookUpEdit as different component


2. or how I can work with the same component but make testcomplete recognise it




Please help



Regards,



Abraham

7 Replies

Sort By
  • YMinaev's avatar
    YMinaev
    Staff
    13 years ago
    Hi,



    1. If the parent object of your control changes (different windows), TC will recognize it as different controls anyway because objects located on different hierarchy levels are addressed individually. TC is not aware whether this is technically the same object or not. It works with the object tree hierarchy and recognizes controls using paths to them in the tree.



    2. Again, TC will work this way if you have a single object of such type, and this object is always located at the same place in the tree.



    So, the way you can work with your control in this case depends mostly on your application's structure, not on the way TC recognizes it.
  • j_smith's avatar
    j_smith
    Occasional Contributor
    12 years ago
    Hello,



    I'm having a similar problem.  It seems that the PopupLookUpEditForm refers to the first LookUpEdit control that my test clicks on, even after I move to another page with another, different LookUpEdit control.  When my test clicks on the second LookUpEdit and tries to make the selection I made when recording, it tells me that the PopupLookUpEditForm object is invisible (because it's on the previous page?).  But when watching the test run, the PopupLookUpEditForm of the second LookUpEdit control is definitely visible.  When the test fails, I'm staring at the mouse that seems to be "contemplating" whether it should indeed make the selection from this LookUpEdit control or not, with the options to select from in plain sight.



    Does this provide enough detail to warrant a suggestion?
  • hema_eltoukhy's avatar
    hema_eltoukhy
    Occasional Contributor
    12 years ago
    Hi Jake,



    Seek help from the application developers, they should be able to help you



    Br

    Abraham 
  • j_smith's avatar
    j_smith
    Occasional Contributor
    12 years ago
    Unfortunately, I am one of the developers.  We are giving TestComplete a go and ran into this issue.  I was hoping there was a reasonable workaround for this...
  • j_smith's avatar
    j_smith
    Occasional Contributor
    12 years ago
    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?
    • olivier1's avatar
      olivier1
      New Contributor
      8 years ago

      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