Bugs and Issues

Long delay before "Open File" window appears

For a few users on Microsoft platforms, several long-standing problems with Java sometimes caused inordinate delays in the appearance of Open/Save File windows, or when changing directories in these windows. From version 1.3, Statestep uses the native OS filechooser when running on a Microsoft OS. This should fix this problem - but if you still experience delays, please report it.

Normally it is possible to select a function from a drop-down menu by pressing the mouse button while the cursor is on the menu heading, dragging the cursor down the menu, and then releasing the mouse button when the cursor is over the desired item. On some recent versions of Java running on some operating systems, this doesn't work for items in the menu that go beyond the bounds of the window:

Drop-down menu

Two workarounds: (1) Instead of keeping the mouse button pressed, click (i.e., press and immediately release the mouse button) on the menu heading to open the drop-down menu, then click again on the item you want. Or (2) make the window bigger so that the drop-down menu stays within the bounds of the window.

Memory problems in some versions of Java

Memory retention bugs (memory leaks) in some versions of Java can lead to Statestep running out of memory. These vary by version and platform but the effect is the same: after using Statestep for an extended period of time, especially after opening and closing many windows, you may find that it starts to slow down and become less responsive. If this happens, save your model, exit and restart Statestep.

Most users should never encounter this problem. If it does occur, first try updating to the latest version of the Java Runtime Environment for your operating system. If that doesn't fix the problem, please report it to the address below. Statestep already implements workarounds for two known bugs of this kind.

Display glitches with some versions of Java

Depending on the version of Java you have and your operating system, there may be occasional formatting errors in the display of windows containing hyperlinks, for example, the Help browser. Also, dialog boxes, that is, windows requiring some kind of confirmation or selection before proceeding, may fail to display properly: If only the window title bar at the top of a dialog box appears then just click its 'close window' icon (often an 'X'). Note: until you close the (mostly invisible) dialog, Statestep may appear to hang, since the other windows will be unresponsive.

These problems affect only some versions of Java and even then seem to occur very rarely.

Explanations omit variable definitions

Occasionally, to be logically complete, an explanation should include one or more variable definitions in addition to a list of constraints. For example, if asked to explain why the value b1 is not possible for variable B, the explanation provided by the program might be something like

In this case, the program is assuming you remember that

– that is, that these are the only three values defined for variable A.

This is one of those things that isn't a problem if you're aware of it. However, without definitions, an explanation is not strictly complete and this may sometimes be confusing.

Checking of non-deterministic models

A non-deterministic model is one where the rules allow for a choice of outcomes in the same case. If you don't create models of this kind, you can ignore what follows. You can also ignore it if the non-determinism arises through a choice of rules rather than a choice of outcomes within the same rule.

Statestep currently treats non-determinism in the most generous (forgiving) way: If a choice of outcomes within a rule means an error is not inevitable then it is not reported. This convention has the advantage of producing no spurious errors for incomplete rules (which are implicitly non-deterministic). Also, it is not generally much of a limitation: Even in non-deterministic models, most rules are likely to be deterministic.

However, it gives rise to a less obvious issue. Suppose a rule – call it rule R – in a finite state machine model permits a transition from state A to either state B or state C. Imagine the constraints make B impossible and so it should not be reachable. Because C is an alternative, it is possible to avoid entering B and so no violation is reported for rule R.

Now, imagine also that another rule for the same event, rule S, allows a transition from A to either B or D. In this case the program reports only an overlap between rules R and S: there is no conflict because, provided the choice of next state is B, both rules can agree.

This means that there is a problem with both of the possible choices of next state in rule R. However, because the checks for violations and conflicts are independent and because of the convention of ignoring avoidable errors, no error is reported. This is a subtle issue, but ultimately no more of a problem than the non-reporting of non-deterministic errors: even if the checks were combined, you would still have to be just as careful when modeling non-deterministic rules.

Questions, comments?