| Custom ComboBox not readable [message #849923] |
Thu, 19 April 2012 15:25  |
Sup SC
Messages: 15
Registered: February 2012 |
Junior Member |
|
|
As I had problems reading the text of a ComboBox in the current version of our application, I asked a developer to implement 'getTestableText()' ang 'getText()' on the component 'net.company.lib.gui.basic.ComboBoxDynamic', which has been done according to the description out of the ReleaseNotes: "public String getTestableText()".
Unfortunately I still get no result, other fields, tables and menus are no problem, just the ComboBoxes won't play with me.
When remote debugging the code none of the breakpoints on the four methods (see below) is working (while they are working on the constructor, so remote debugging should be generally OK) when Jubula trys to read the ComboBoxes (of either of below listed type).
Below are the relevant methods of the ComboBoxDynamic, which is based on another custom ComboBox (which is based on the JComboBox). Also below is the element hierarchy Jubula recognizes.
Does anyone see a cause why I always get an empty string? Or is there any further documentation how to implement this Adapter Jubula provides?
Thank you very much.
// ComboBoxDynamic
@Override
public String getTestableText() {
return getSelectedItem() == null ? "<empty>" : "<filled>" + getSelectedItem().getListString();
}
@Override
public String getText() {
return getSelectedItem() == null ? "<empty>" : "<filled>" + getSelectedItem().getListString();
}
// ComboBox
/**
* Gets the string representation of the selected item.
*
* @return The string representation of the selected item. An empty string if no item was selected.
*/
public String getTestableText() {
return getSelectedItem() == null ? "<empty>" : "<filled>" + getSelectedItem().toString();
}
public String getTestableText() {
return getSelectedItem() == null ? "<empty>" : "<filled>" + getSelectedItem().getListString();
}
<!-- code hierarchy of exported test -->
<componentClassName>net.company.lib.gui.basic.ComboBoxDynamic</componentClassName>
<supportedClassName>javax.swing.JComboBox</supportedClassName>
<hierarchyName>frame1</hierarchyName>
<hierarchyName>javax.swing.JRootPane_1</hierarchyName>
<hierarchyName>null.layeredPane</hierarchyName>
<hierarchyName>null.contentPane</hierarchyName>
<hierarchyName>net.company.lib.gui.basic.SplitPane_1</hierarchyName>
<hierarchyName>net.company.lib.gui.basic.ScrollPane_2</hierarchyName>
<hierarchyName>javax.swing.JViewport_1</hierarchyName>
<hierarchyName>net.company.lib.gui.mdi.Desktop_1</hierarchyName>
<hierarchyName>net.company.contract.gui.ContractFieldUI_1</hierarchyName>
<hierarchyName>javax.swing.JRootPane_1</hierarchyName>
<hierarchyName>null.layeredPane</hierarchyName>
<hierarchyName>net.company.lib.gui.basic.Panel_1</hierarchyName>
<hierarchyName>net.company.lib.gui.basic.Panel_1</hierarchyName>
<hierarchyName>net.company.contract.gui.ContractFieldPanel_1</hierarchyName>
<hierarchyName>net.company.lib.gui.basic.ComboBoxDynamic_2</hierarchyName>
<alternativeDisplayName>Combo Box</alternativeDisplayName>
|
|
|
|
| Re: Custom ComboBox not readable [message #853139 is a reply to message #850577] |
Sun, 22 April 2012 19:08  |
Sup SC
Messages: 15
Registered: February 2012 |
Junior Member |
|
|
Zeb Ford-Reitz wrote on Fri, 20 April 2012 08:34It looks like getText() is implemented twice in ComboBox, but I'll assume that's a copy and paste problem.
Yep
Zeb Ford-Reitz wrote on Fri, 20 April 2012 08:34The JComboBox (or in this case ComboBoxDynamic) is first queried for its editor or editor component (getEditor(), if that's null then fall back to getEditorComponent()). Check whether ComboBoxDynamic returns the values you would expect for those methods.
After getting the corresponding component (editor or editor component), Jubula then queries *that* component for the rendered text, so it is *that* component that needs to implement getText() and / or getTestableText().
If these suggestions don't help solve the problem, you could try adding the Jubula Swing RC bundle (org.eclipse.jubula.rc.swing) and sources to your remote debugging classpath and setting a breakpoint at org.eclipse.jubula.rc.swing.swing.implclasses.JComboBoxHelper#getText().
Unfortunately, there does not seem to be a special editor or editor component set for this custom ComboBox.
The editor component returned by (the from getText() later called method) 'org.eclipse.jubula.rc.swing.swing.implclasses.JComboBoxHelper.getComboBoxEditorComponent()' is a 'javax.swing.plaf.basic.BasicComboBoxEditor$BorderlessTextField', so the chances do not seem too good to be able to add methods there  The custom ComboBox does not fill these TextField, but uses other methods to reach its content.
Playing around it looks like something like
// please keep in mind I am no Java developer
public void setTextForJubula(){
BasicComboBoxEditor bcbe = (BasicComboBoxEditor) getEditor();
String val = getSelectedItem() == null ? "<foo setTextForJubula ComboBox>" : "<bar setTextForJubula ComboBox>" + getSelectedItem().toString();
bcbe.setItem(val);
}
would do the trick when called on any changing of the custom ComboBox, at least a basic test with the AUT now gave back some values.
Thanks for your help so far.
Now I have seen, that in 'org.eclipse.jubula.rc.swing.swing.implclasses.AbstractSwingImplClass.resolveRenderedText' there is first tried to get the text of a component by calling the methods of the standard Java component, e.g. "((JTextComponent)renderer).getText()" and only after that the by the AUT providable ITextRendererAdapter, getTestableText() and getText() are used as fallbacks.
This seems to be the cause for our case that we get an empty String instead of the value I search. As the returned editor component BorderlessTextField is an 'instanceof JTextComponent' the method returns the (in our case unset and empty) value of this field and never even trys to call getTestableText().
(<del>Is there a particular reason to call the custom implementable methods only if the others fail?</del><ins>Well if it's executed on the editor component it would not make much difference here, if rethinking this case...</ins>)
Wouldn't it be even nicer to try to call the custom functions before the standard methods on the editor component are tried, and only try the standard methods if none of these custom methods (ITextRendererAdapter, getTestableText() and getText()) is provided by the AUT? (This would e.g. give ComboBoxes with objects a chance to give back a text, if I do understand the problem correctly here.)
[Updated on: Mon, 23 April 2012 10:16] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03494 seconds
] 
Search
Help
Register
Login
Home
