Created attachment 70749 [details]
Testcase Project

I did not analyze source code of this midlet but based on flow and application behavior it is correct behavior. Triangle
next to command symbolizes "previous screen" (not previous screen in Flow Designer but real previous screen shown befor)
In this case previous screen is Alert that is why flow is in loop. To fix it just attach transition from
backCommandMessage to formMain component instead of "previous screen"

In some very simple cases as in this testcase, of course, the situation can be avoided as suggested by not using the
provided functionality.

However, I can't imagine any logic that would support the correctness of this situation from a user perspective.

The issue is that the Midlet Designer generates framework code for a rather simple screen history mechanism that fails
in 50% of all my cases.

It is quite typical that a dialog gets opened from an external event. In this case it is very important that history is
reliable and lets the user return to the previous screen. A dialog that is opened from an external event does not know
where to return to in most cases. This is only a special feature of this simple testcase and the suggested workaround
cannot be generally applied. It would be preferable to get this framework code to the next level so that it works
reliably, otherwise it would be better not to have this code because it takes up space in the phone without solid benefits.

The code gets called from the Action "Switch to Displayable" as entered graphically in the Action Dialog.
I am thinking that the problem could be solved if a boolean parameter "Record in History" could be added for this
action. If false then the Displayable e.g. an Alert would not be added to __previousDisplayables and the problem would
hopefully disappear. Just a thought.

Midlet Designer depends on this code very much as it generates a lot of user code that uses it.


The generated framework code is:

    private java.util.Hashtable __previousDisplayables = new java.util.Hashtable();

    //<editor-fold defaultstate="collapsed" desc=" Generated Method: switchDisplayable ">                              
               
    /**
     * Switches a current displayable in a display. The <code>display</code> instance is taken from
<code>getDisplay</code> method. This method is used by all actions in the design for switching displayable.
     * @param alert the Alert which is temporarily set to the display; if <code>null</code>, then
<code>nextDisplayable</code> is set immediately
     * @param nextDisplayable the Displayable to be set
     */
    public void switchDisplayable(Alert alert, Displayable nextDisplayable) {                                            
        // write pre-switch user code here

        Display display = getDisplay();                                               
        Displayable __currentDisplayable = display.getCurrent();
        if (__currentDisplayable != null  &&  nextDisplayable != null) {
            __previousDisplayables.put(nextDisplayable, __currentDisplayable);
        }
        if (alert == null) {
            display.setCurrent(nextDisplayable);
        } else {
            display.setCurrent(alert, nextDisplayable);
        }                                             
        // write post-switch user code here
    }                                   
    //</editor-fold>                                 


    
	 //<editor-fold defaultstate="collapsed" desc=" Generated Methods ">                       
    /**
     * Switches a display to previous displayable of the current displayable.
     * The <code>display</code> instance is obtain from the <code>getDisplay</code> method.
     */
    private void switchToPreviousDisplayable() {
        Displayable __currentDisplayable = getDisplay().getCurrent();
        if (__currentDisplayable != null) {
            Displayable __nextDisplayable = (Displayable) __previousDisplayables.get(__currentDisplayable);
            if (__nextDisplayable != null) {
                switchDisplayable(null, __nextDisplayable);
            }
        }
    }
    //</editor-fold>                     

Thanks for detailed description of this problem. I may reconsider this particular functionality and do some changes as
suggested. Unfortunately it is not possible to do it in 6.7 because we already reached "feature freeze" state of
development. I'm moving this issue to the FEATURES. It should be part of next release (most likely 7.0).