The outer form (and all the way back up the chain) has to be non modal. This means some major rethink with process flow and feedback if you are expecting it to return data to a further form.  You can mess about with form loses focus triggers but we've had only limited success with this. 

Iain Sharp said The outer form (and all the way back up the chain) has to be non modal. This means some major rethink with process flow and feedback if you are expecting it to return data to a further form.  You can mess about with form loses focus triggers but we've had only limited success with this. 

I did run into the same trouble Just to make the containing form a 'modal-like'-form is a challenge, it's like a ping-pong-play with FRGF and FRLF. I finally made it Not really good solution and some escapes from the modal-like form are possible, but the look and feel is like a modal form. Now I have to test it under real conditions. And the return of parameteres is a nice thing to round off. BUT: Maybe UnifAce will surprise us with a solution ... The whole thing keeps exciting ...   Ingo

Sorry Ingo, very unlikely. We're caught between what MS does and doesn't enable. For us to mix and match modality is going to lead to us having to code around that and also make sure things like the structure editor and the focus manager are still playing together nicely.  By the time we've sorted our way through that, wrapped tests around the old and new functionality to ensure we're not breaking anything, it would be a significant investment. This is isn't in our plans. 

Hi all, We decided to move the tabex functionality to the first form of the application and turn it to non-modal. The problem now, is that the "EDIT" statement do not work and the form exits to the startup shell.   i would appreciate your help. Sergio.

fearandir said Hi all, We decided to move the tabex functionality to the first form of the application and turn it to non-modal. The problem now, is that the "EDIT" statement do not work and the form exits to the startup shell.   i would appreciate your help. Sergio.

  The EDIT statement in a non-modal forms "falls through". It just say the UnifAce engine that now on, the surface is avaible for user input. If you using a form for modal and non-modal envirnoments, it's best practise to do something like the following in EXEC trigger: call LP_INIT ; local init routines IF(!$formodality)   edit/nomodal   RETURN(0) ENDIF edit/modal IF($status==10)   ;QUIT ELSEIF($status==9)   ;Accept  ELSE   ;Error ENDIF EXIT(xyz) END; EXEC-Trigger Important: Don't delete the (chain of) instance explicit or implicit  (DELETEINSTANCE or ACTIVAE <component>) Don't end the trigger by EXIT in a non-modal environment (implicit delete!) Hint: To check if an instance will somewhere deleted, create an "include", say INCL_STD_OPER (standard operation) Place this include in USYSFRM in the OPER-Trigger The include should a least contain two operations OPERATION INIT and OPERATION CLEANUP Now place some messages into this Operations IF($$DEBUG_INSTANCES)   putmess "%%$componentname()%%% [%%$instancename()%%%] INIT()" ENDIF resp. IF($$DEBUG_INSTANCES)   putmess "%%$componentname()%%% [%%$instancename()%%%] CLEANUP()" ENDIF In the startup shell you can place a assignment to $$DEBUG_INSTANCE From now on, you get a message line for every creation and deletion of an instance Ingo

When you come out of the last modal form in an application the application will shut down.  Since you have made the form started by the application startup shell non modal, there is no modal form and the application shuts down.  You can call a non modal form from a modal form, but not the other way around.  So you need a modal form to be called from the application startup shell, and then it needs to call a non-modal form which has the tab-widget/container widget painted on it, which in turn calls non-modal contained forms.  You then have code in the modal 'base' form 'form gets focus' trigger, which says something like :-