Whats the application written in? It may need to be compiled with debug info on to allow you access to native properties such as those in my link.
Thats certainly the case with the Delphi grids I work with, Without debug info, they would be pretty much impossible to test.
And mine is the same. Data driven by the user. They specify the column/row name/number (some are named, some not, just make life more interesting). I need to deduce what they're trying to do from that by working out whats on screen, and whats actually available via the underlying dataset. Takes a bit of working out in some cases. They're not the simplest of controls to interact with. Especially if you try and do it in such a generic way ...
This particular version of the sftTreeControl32ocx is written in C++. The debug compile could be helpful but as I mentioned earlier getting the developing team to take the time to do this would be low on their to do list if it made it at all.
Its the "generic way" that is the problem. I could easily just say there is a rowheader and it is x width and it works fine, but that would work only for this instance of this grid, I need it to work for all instances of this grid.
I guess my next step is to log an official ticket with smartbear and see if they can assist.
Thanks!
If it's C++ you may need some compile options if you want full access to the control.
https://support.smartbear.com/viewarticle/69672/
Thats certainly the case with the Delphi grids I have to use. Without debug info, it would be impossible to write a generic handler as so much of the data and native methods are required to do it that way.
I do now have a generic handler, which handles about four different types of Delphi grid. But they're complex. And they need the debug info. No way round it.
