Recent changes to bugs

WaitTask thread doesn't stop after timeout

2008-01-21T07:57:42Z

In case if Waiter.doWait(timeout, wc) exits with timeout exception, thread that performs checks doesn't stop and continues performing checks.

Here is example of such behavior:
--------------------------------
public class WaiterCheck {
public static void main(String[] args) throws Exception{
try {
WCActiveBase base = new WCActiveBase() {
public boolean check() throws Exception {
System.out.println("checking");
Thread.sleep(500);
return false;
}
};
Waiter.doWait(2 * 1000, base);
} catch (Exception e) {
System.out.println("waiter timed out");
}
System.out.println("finish");
}
}
--------------------------------

Suggested solution is to put failure() invocation in TimeoutException handling in WaitCallback.waitUntil

JLabelFinder::setText, setCaseIndependent don't work

2007-12-07T17:58:15Z

Hi, just've found it:
JLabelFinder has two wrong methods:

/**
* Set the finder into a case independent mode.
* @param ignoreCase true if case should be ignored.
*/
public void setCaseIndependent(final boolean ignoreCase) {
super.setCaseIndependent(ignoreCase);
m_caseIndependent = ignoreCase;
createPatternMatcher(m_text, m_caseIndependent);
}

/**
* Set the label text to be matched.
* @param text Text to be matched.
*/
public final void setText(final String text) {
m_text = text;
createPatternMatcher(m_text, m_caseIndependent);
}

Everywhere should be NOT createPatternMatcher but recreatePatternMatcher
Because createPatternMatcher has a check for m_patternMatcher == null - that's why after constuctor calicn call of setText and setCaseIndependent are useless.

NullPointerException in JComboBoxMouseED::prepareComponent

2007-07-19T14:17:26Z

Hi Pavel.
As designed, JFCTestCase may be used without TestHelper, so getHelper method may return NULL sometimes :)
JComboBoxMouseEventData::prepareComponent calls methods of helper without verification on null. I guess it is not correct.

It would be better
- if default JFCTestCase constructor has mandatory TestHelper parameter
or
- such calls as:
...
if (comp != null) {
MouseEventData data = new MouseEventData(testCase, comp);
testCase.getHelper().enterClickAndLeave(data);

should be changed with "comp.clickButton()" and so on...

Really it is not a problem, just a correction in design.

AbstractWindowFinder::findAll should allow negative "wait"

2007-04-25T08:14:38Z

AbstractWindowFinder::findAll should allow negative "wait" timeouts to let search _only_ one time.
"0" value doesn't provide such guarantee in case of time synchronization (time goes back), and Integer.MIN_VALUE - provides... (I notice that find methods use absolute timers)

=====================
public List findAll(final Container[] owners) {
List retSet = new ArrayList();
int wait = Math.max(
0,
getWait());
...
====================
should be changed with
====================
public List findAll(final Container[] owners) {
List retSet = new ArrayList();
int wait = getWait();
...
====================

Wrong work of MouseEventData::insureVisibleLocation

2007-04-25T08:02:35Z

Function insureVisibleLocation doesn't scroll correctly when manipulated component is under hierarhy:
JViewport - SomeOtherComp(Jpanel) - ManipulatedComp.
Reason: wrong calculating of relative coordinates:

===================================================
public void insureVisibleLocation(final Point p) {
// Need to get the parent viewport.
Component parent = m_comp.getParent();
while (parent != null
&& !(parent instanceof JViewport)) {
parent = parent.getParent();
}
if (parent != null && parent instanceof JViewport) {
JViewport port = (JViewport) parent;

Rectangle r = port.getViewRect();
r.x = p.x - (r.width / 2);
r.y = p.y - (r.height / 2);

port.scrollRectToVisible(r);
}
}
===================================================
should be changed with
===================================================
public void insureVisibleLocation(final Point p) {
// Need to get the parent viewport.
Component parent = m_comp.getParent();
Point real_p = (Point)p.clone();

while (parent != null
&& !(parent instanceof JViewport)) {
real_p.translate(parent.getX(), parent.getY());
parent = parent.getParent();
}
if (parent != null && parent instanceof JViewport) {
JViewport port = (JViewport) parent;
real_p.translate(port.getX(), port.getY());

Rectangle r = port.getViewRect();
r.x = real_p.x - (r.width / 2);
r.y = real_p.y - (r.height / 2);

port.scrollRectToVisible(r);
}
}
===================================================

Tests extending JFCTestCase never fail

2006-12-05T15:29:49Z

In version 2.10 it appears to be impossible to get any test extending JFCTestCase to fail.

The following code snippet that lead to a failure using JFCUnit 2.08 does not fail when using JFCUnit 2.10:

public class JFCTestCaseTest extends JFCTestCase {
public void testFail() {
fail();
}
}

In JFCTestCase exceptions are caught and setError(Throwable) is called. In Version 2.08 there was the following code at the end of the runCode(Runnable) method:

if (hasError()) {
throw getError();
}

In Version 2.10 some equivalent code appears to be missing. hasError() is never called.