Class property?
In TC i dont have that property (as u can see on screen)
Developer said that all properties are same for both fields (visible / invisible). Well i think in PowerBuilder they do not have class property too.
Yes i am able to do whatever i want with these fields manually in application.
If i put object spy coursor on object it dosent see it but i can see it in object browser - diffrence is visible property.
1. Yea but i need to click for example dropdown field to choose smth with key("down") and i cant do that atm.
2. I asked developer if its posibble he have that bug.
What developer told me before was that in these 20% types of "countries" he replace some fields on "open event" in powerbuilder but in logic way it shouldn't affect in this case - cause he replace a field that i dont want to click ( i skip that one anyway).
2. Dev answer:
"What Pb is doing is unfortunately not known to me.
We replace actual dataobject insinde Datawindow to another almost the same. We dont create publicly a new datawindow"
As I say, I've never tested a PowerBuilder application, so these were just suggestions.
But this:
"What Pb is doing is unfortunately not known to me. We replace actual dataobject insinde Datawindow to another almost the same. We dont create publicly a new datawindow"
... especially the part in bold/italic does sound suspiciously like they have created a second instance of something? It might explain your ControlIndex of 2. But then, a cluster of radio buttons could also report a control index this way. I don't know how PowerBuilder radio buttons are presented.
So I guess my suggestion is still a possibility. But it also sounds like your dev team don't really understand the controls they're working with. Which would concern me! ("What Pb is doing is unfortunately not known to me." !!!)
If they are creating duplicate instances, I would normally expect these to be visible to me in the object model. But as they also mentioned they don't create it publicly, so maybe not. Someone who knows PowerBuilder would know better than I do. Normally, I would expect that to be the dev team, but in this case, maybe not ....
You know, actually def care about bugs that can be simulated manually - thats the problem.
If I cant click a object with testcomplete but i can do it manually they don't care.
I have same feelings that "We replace actual dataobject insinde Datawindow to another almost the same" may be a second instance that is not properly recognized by testcomplete.
And about control index - looks like they are just sorted diffrent (shouldnt matter for TC if i click object by fullname):
In these 80% radiobuttion A - has index 1 and B has index 2.
In these 20% radiobutton A - has index 2 and B has index 1.
Question is: why just some fields are invisible for TestComplete if they replace a whole dataobject?
Problem is with radiobuttions/combobox, normal text fields are fine.
If noone here will have some knowledge about this case in PB and TC then ill ask dev to make a version just for me without that dataobject repleace.
Radiobutton #1 (which is visible) has Width property == 113
Radiobutton #2 (which is invisible) has Width property == 107
Why so?
I gave same question before to dev - "if u have that property diffrent please check if any other properties are diffrent"
He said that the only diffrence is:
a) width - dosent matter for TC for sure.
b) sorting objects - (prolly matter for control index in TC) - I think it dosent matter if i click objects in my tests by fullname not by index.
Couple of things:
1) It sounds like you actually, in that 20% of cases, have two components on the form... one visible, one not... the invisible one is, for some reason, overlapping your visible one so that, when you use ObjectSpy, it only sees the invisible one. Something to check. In TestComplete, go to the object browser and go to your form when you are in one of those 20% situations and check the list of objects. If you see two sets of radiobutton groups, one visible, one invisible, right there is the proof because...
2) Even though it's not a problem for the end user, this is, in my opinion, bad code. You have memory being taken up by something that is not being used. Who knows what effect will happen later on down the road? And if they are doing this regularly, that means that the memory usage of the application is higher than it should be. The memory is not optimized... which is, therefore, a bug, especially if it is something that was introduced by development.
3) AND if they do have two different radio groups for, effectively, the SAME FUNCTION (selecting gender in your example)... um... what is with that? That's bad coding practice no matter who you ask. You never make NEW code (in this case a component on a form) when there is code that can be reused for the same purpose. So... again, no "bug" with regards to the end user, but now you've introduced a problem where if they need to change the logic behind the radio button, they could, potentially, change it for one component but "forget" to change it for the other, introducing a NEW bug of inconsistent functionality... all because they didn't create the UI properly. Sure, the end user may not experience a problem, but if you can prevent problems down the road, so much the better.
These are arguments that you can take to your developers as impetus to fix the problem. Additionally, you are, as a tester/QA person, a "customer" to the developers. You can't use the application as it is. Therefore, you have a bug that they need to fix.
