locked
UI Controls get slower to invoke after adding more controls to Coded UI designer class RRS feed

  • Question

  • I'm using Coded UI to find UI controls and add them to UIMap. I'm not using recordings. I write my own methods, but I have seen the problem below even with recordings.

    The problem I'm encountering is that after adding one or more controls to an existing UIMap, not only it can change my definitions (which I'm aware of and don't mind at the moment), but worse, it slows down the Invocation of controls.

    For example a control such as a button that took a fraction of a second to invoke now takes 15 seconds. 15 seconds seems to be the standard for this problem.  I have been able to resolve it in a few occassions by regenerating the control again and perhaps moving the control to a separate UIMap.  This is very annoying and I have wasted a lot of time having to deal with this.

    Has anyone run into the same problem and if you know of what's causing this and how to fix it I would appreciate it.

    I'm using VS 2015 Enterprise.


    NR



    • Edited by Highlander4 Saturday, April 1, 2017 7:01 PM
    Saturday, April 1, 2017 4:23 AM

Answers

  • Replying to myself and others:  I found this link which was very helpful: http://stackoverflow.com/questions/20367855/coded-ui-test-is-slow-waiting-for-ui-thread

    The link doesn't particularly answer my problem, but it gives me some ideas as to why this is happening. Apparently, the engine has problems with finding controls after they have been reshuffled during re-generation of the designer class when we add additional controls or has problems invoking the control in the same situation.  There is a method in the link provided which corrects my problem and that is the method that after an error, waits a second then retries again. The method was added to circumvent the fact that waiting periods were disabled, etc.

    Take a look at it, I added it to my solution and it seems to do away with all the excess timing.  I still think this is a Microsoft bug with the CUIT engine in dealing with it's own controls after regenerating. Perhaps MS can address this in the future.  In my opinion I think they have over engineered the process and need to pull back some.  It is an annoying problem that can cost an enormous amount of time to troubleshoot because there is no clear answer as to what the problem is from where we can see.  It is buried somewhere in one of the DLLs. 


    NR



    • Marked as answer by Highlander4 Saturday, April 1, 2017 9:25 PM
    • Edited by Highlander4 Monday, April 3, 2017 3:38 PM
    Saturday, April 1, 2017 9:23 PM

All replies

  • Replying to myself and others:  I found this link which was very helpful: http://stackoverflow.com/questions/20367855/coded-ui-test-is-slow-waiting-for-ui-thread

    The link doesn't particularly answer my problem, but it gives me some ideas as to why this is happening. Apparently, the engine has problems with finding controls after they have been reshuffled during re-generation of the designer class when we add additional controls or has problems invoking the control in the same situation.  There is a method in the link provided which corrects my problem and that is the method that after an error, waits a second then retries again. The method was added to circumvent the fact that waiting periods were disabled, etc.

    Take a look at it, I added it to my solution and it seems to do away with all the excess timing.  I still think this is a Microsoft bug with the CUIT engine in dealing with it's own controls after regenerating. Perhaps MS can address this in the future.  In my opinion I think they have over engineered the process and need to pull back some.  It is an annoying problem that can cost an enormous amount of time to troubleshoot because there is no clear answer as to what the problem is from where we can see.  It is buried somewhere in one of the DLLs. 


    NR



    • Marked as answer by Highlander4 Saturday, April 1, 2017 9:25 PM
    • Edited by Highlander4 Monday, April 3, 2017 3:38 PM
    Saturday, April 1, 2017 9:23 PM
  • Hi friend,

    Thanks for sharing the answer with us.

    Best regards,

    Fletch


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, April 3, 2017 1:36 AM