Forum Discussion

akhilpotla's avatar
akhilpotla
New Contributor
4 days ago

Issue: BricsCAD 26 – WPFObject recognition missing, only UIA works (performance concerns)

Environment

TestComplete version: 15.80 (x64)

BricsCAD version: 26 (x64)

BricsCAD 24 in same environment shows different behavior

Object Spy + Object Browser used for investigation

Inspect.exe (Windows SDK) used for verification

Problem

In BricsCAD 26, TestComplete recognizes the UI only up to:

Window("#32770","MGDPALETTE")

→ WindowsForms10.Window

→ HwndWrapper[DefaultDomain;;GUID]

After HwndWrapper, TestComplete does not expose individual WPF controls.

Object Spy shows only:

Window(...)

No:

WPFObject(...)

In contrast:

BricsCAD 24 exposes full WPFObject hierarchy.

Same TestComplete project and configuration.

Observations

Inspect.exe can see all inner controls via UI Automation.

Enabling UI Automation in TestComplete (* accepted windows) allows access to inner controls as UIAObject.

Therefore accessibility tree exists and UI is exposed correctly.

Current workaround

Using UIAObject chain:

...HwndWrapper(...).UIAObject(...).UIAObject(...)

This works but is very slow:

Object Spy takes long to load.

Object Browser expansion is slow.

Deep UIA chains cause high execution delay.

Attempts already done

Verified TestComplete and BricsCAD are both 64-bit.

Enabled UI Automation support.

Added:

HwndWrapper*

WindowsForms10.*

in UI Automation accepted windows.

WPF settings checked.

Launch order tested (TC before app).

WPFObject still unavailable.

.ClrVersion and managed objects not exposed.

Suspected cause

BricsCAD 26 uses .NET 8/CoreCLR hosting.

TestComplete appears unable to attach CLR/WPF support in this application, so WPFObject recognition never activates and only UIA is possible.

Main questions

Is WPFObject recognition unsupported when WPF is hosted via .NET 8/CoreCLR in this manner?

Is there a known limitation with HwndWrapper + CoreCLR hosting preventing WPF injection?

Any recommended way to improve UIA performance for large trees (CAD applications)?

Best practice for stable mapping when only UIAObject is available?

Goal

Prefer WPFObject recognition (faster, cleaner).

If impossible, optimize UIA performance and recommended architecture.

5 Replies

  • keona65's avatar
    keona65
    New Member
    1 day ago

     in many cases, WPFObject recognition does not work with CoreCLR-hosted WPF apps.

    • akhilpotla's avatar
      akhilpotla
      New Contributor
      1 day ago

      Are there any supported solutions or configuration changes to enable reliable WPFObject recognition with CoreCLR-hosted WPF applications?

      If not, are there documented workarounds or alternative object identification approaches recommended for such cases?

      • Hassan_Ballan's avatar
        Hassan_Ballan
        Icon for Champion Level 3 rankChampion Level 3
        1 day ago

        Since the same TestComplete project exposes WPFObject correctly in BricsCAD 24 but not in 26, the first thing I would verify is whether BricsCAD 26 is now hosted on CoreCLR (.NET 8) instead of .NET Framework.

        If it is running on CoreCLR, I would open a SmartBear support ticket and explicitly confirm whether WPFObject recognition is supported for CoreCLR-hosted WPF applications in your TestComplete version. If CoreCLR hosting is not supported by the WPF plugin, there isn’t a configuration change that will enable WPFObject.

        That gives you a clear decision path:

        • If CoreCLR is supported → continue troubleshooting WPF configuration (plugins, bitness, load order, etc.).
        • If CoreCLR is not supported → accept that WPFObject won’t attach and focus on optimizing UIA usage instead.

         

        If you must stay with UIA, one practical improvement is to avoid deep
        UIAObject(...).UIAObject(...).UIAObject(...) chains and instead use FindChild() (with a depth limit) against stable properties like AutomationId, Name, or ControlType. In large UIA trees (common in CAD applications), this is typically faster and more maintainable than expanding full hierarchies in Name Mapping.

        This approach avoids speculation and gives you a concrete next step depending on what SmartBear confirms.

        🤖 AI-assisted response
        👍 Found it helpful? Click Like
        ✅ Issue resolved? Click Mark as Solution

         

  • rraghvani's avatar
    rraghvani
    Icon for Champion Level 3 rankChampion Level 3
    4 days ago

    There has been a number of times, where Object Spy tool has failed or taken a long time to identify a control, and if it has identified the control, it's incorrect. I've seen this in XPath and Classic approach for web applications.

    Refer to Supported Technologies and Applications

    Unfortunately, there's no workaround. The only option is to open a Support Ticket.