Is the return logic of App.close(int Wait) correct?

Asked by Ben Carson

I am building a SikuliX automation script in Java and confused about the expected results of the .close() method. Inside of Sikuli's App class, the close method is as follows:

  /**
   * tries to close the app defined by this App instance, waits max given seconds for the app to no longer be running
   *
   * @return this or null on failure
   */
  public boolean close(int waitTime) {
    if (!isRunning()) {
      log("App.close: not running: %s", this);
      return false;
    }
    if (_osUtil.close(this)) {
      int timeTowait = maxWait;
      if (waitTime > 0) {
        timeTowait = waitTime;
      }
      while (isRunning(0) && timeTowait > 0) {
        timeTowait--;
      }
    }
    if (!isValid()) {
      log("App.close: %s", this);
    } else {
      log("App.close: did not work: %s", this);
      return true;
    }
    return false;
  }

The part in question for me is the return. My understanding is that, since it returns a boolean, it would be true if the close was a success, and false if the close failed. However, this code does the opposite. Based on my flawed(?) understanding of this logic, I initially wrote my code like so,

if (myApp.close()) {
    System.out.println("closed.");
    isAppClosed = true;
} else {
    System.out.println("NOT closed!");
    isAppClosed = false;
}

This is having the opposite result of what I want, as the application is successfully closing, BUT the test is failing because "NOT closed" is being printed.

Have I found a bug, or am I missing something?

Thanks.

I cross-posted on Stackoverflow here: https://stackoverflow.com/q/54201161/185967

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
RaiMan
Solved:
Last query:
Last reply:
Revision history for this message
Ben Carson (catsandcode) said :
#1

If this isn't the intended behavior, I'm more than happy to create a PR to correct it. I am just new to Sikuli and didn't want to make change requests willy-nilly without fully understanding the problem.

Revision history for this message
Best RaiMan (raimund-hocke) said :
#2

Ok, right, thanks.

Fixed in the build from today (#186)

Revision history for this message
Ben Carson (catsandcode) said :
#3

Thanks RaiMan, that solved my question.