In waitForComponentShowing, if the ComponentReference was constructed without a Resolver, ComponentTester throws an exception, but it gets caught in assertComponentShowing and simply times out.
Is this expected behavior?
I'm finding I'm still having to go back to using ComponentReferences when hand-coding tests because for some reason I'm not able to get high enough in the Swing context to find drop-down menus that are not rooted in the current JPanel. ComponentReference must be doing something special I don't understand.
Thanks for any info.
Thanks
-Nick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you're looking for the active popup, you might want to use abbot.util.AWT.findActivePopupMenu(). Note that popups (including those triggered by a JMenu) are actually connected to the hierarchy as either a child window of the parent frame or as a JPanel sibling of the content pane, so you will not find popups as descendents of the "invoker" component.
What "find" command are you using to find the drop-down menu?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, it's a custom component so findActivePopupMenu doesn't work for us. I was able to get something in each of two conditions:
1) When I use the ComponentReference.getComponent(), catching a MultipleComponentsFoundException and iterating through the components in the MCFE to find my component
2) When I use getHeirarchy().getRoots(), iterate through the Collection it returns and doing a find on those instead of the default behavior in the ComponentTextFixture
Both seem a bit kludgey, but I understand why.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are two ComponentFinder.find methods. One takes an explicit root. The other one searches the entire hierarchy, whose roots are represented by getHierarchy().getRoots().
so getFinder().find(new Matcher() { ... }) does what you describe in #2. If for some reason it does not, I'd like to know the details.
I will try to make a TestCase that evidences that doing #2 doesn't give you consistent results as per #1. (note, I'm not sure that's true, I just believe I've encountered it). I'd like to move away from #1 for obvious reasons.
Thanks,
-Nick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this a bug?
In waitForComponentShowing, if the ComponentReference was constructed without a Resolver, ComponentTester throws an exception, but it gets caught in assertComponentShowing and simply times out.
Is this expected behavior?
I'm finding I'm still having to go back to using ComponentReferences when hand-coding tests because for some reason I'm not able to get high enough in the Swing context to find drop-down menus that are not rooted in the current JPanel. ComponentReference must be doing something special I don't understand.
Thanks for any info.
Thanks
-Nick
What do you mean by a drop-down menu?
If you're looking for the active popup, you might want to use abbot.util.AWT.findActivePopupMenu(). Note that popups (including those triggered by a JMenu) are actually connected to the hierarchy as either a child window of the parent frame or as a JPanel sibling of the content pane, so you will not find popups as descendents of the "invoker" component.
What "find" command are you using to find the drop-down menu?
I'm sorry, it's a custom component so findActivePopupMenu doesn't work for us. I was able to get something in each of two conditions:
1) When I use the ComponentReference.getComponent(), catching a MultipleComponentsFoundException and iterating through the components in the MCFE to find my component
2) When I use getHeirarchy().getRoots(), iterate through the Collection it returns and doing a find on those instead of the default behavior in the ComponentTextFixture
Both seem a bit kludgey, but I understand why.
There are two ComponentFinder.find methods. One takes an explicit root. The other one searches the entire hierarchy, whose roots are represented by getHierarchy().getRoots().
so getFinder().find(new Matcher() { ... }) does what you describe in #2. If for some reason it does not, I'd like to know the details.
See the javadoc for abbot.finder.ComponentFinder, http://abbot.sf.net/doc/api/abbot/finder/ComponentFinder.html.
I will try to make a TestCase that evidences that doing #2 doesn't give you consistent results as per #1. (note, I'm not sure that's true, I just believe I've encountered it). I'd like to move away from #1 for obvious reasons.
Thanks,
-Nick