We have a service that creates one container form A and a contained form B, then activate an operation of A to put the instance of B in the container field.

There is a lot more around (calling other services, which create other forms, displayed in various containers).

And sometime (not always, not reproductible every time) the contained form B closes itself at the end of the process.

I tried comparing trace when form B stay opened and when it close, but except the fact that it closes, I can't find any relevant difference.

And when it closes, the instance's reference still exists in the A container.

My question is : What can cause the stop in the contained form.
If you have any hint, thanks for your help

Thanks in advance


    CommentAdd your comment...

    3 answers


      Hi Yves,

      Now your appl scenario is a little more clear... a little... (smile)

      In your first message I read "when it closes, the instance's reference still exists in the A container".
      A related question could be: when B closes, the instance reference still exists also in $instances("B", "")?

      In other words: when B crashes the Uniface runtime is still aware of that instance or is cleaning its reference?


      1. yves de M.

        Hi Gianni,
        No, the $instances is cleared. When I debug, I see the B.exec step out of the edit statement and the instance is really cleared.
        I said that because I know that when a handle is not referenced anymore, the instance is deleted ans cleared. But it's not the case here.


      2. Gianni Sandigliano

        Hi Yves,

        If during your debug you "see the B.exec step out of the edit statement", it become obvious you do not see anymore any reference to your B instance, because it do not crash, it politely exit and it is cleared from runtime!

        Now in my mind your issue is becoming: why your B instance is stepping out from the edit statement if you do NOT want to?
        This lead to the question: what has happened in your application just BEFORE B is exiting?

        mmmhhhmmm...just couple hints:
        - are you using somehow macro "^QUIT" or macro "^ACCEPT"?
        - is your code doing an exit statement?
        In both cases you probably are supposing to exit from another component while it is somehow applied to your B component. Is your form focus as you've expected?

        As an hint you could try to analyze $status value just after your B instance is stepping out of edit statement:
        if =9   => accept
        if =10   => quit
        if any other value => an exit statement is forcing $status value...


      3. yves de M.

        Hi Gianni,

        Thanks for advice. but sadly, after the edit, $status = 0.
        We don't use  ^macro . And in this particular case, we are just at the beginning of displaying a formular for input from the user. It's not a popup, but a "real window", in a specific transaction branch. All the displayed form are useful, So I don't find a form that could be closed with the bad focus.
        And the _quit trigger is not started (I put a breakpoint and it never stops there)
        And the cleanup is done after the end of the _execute, so it's not a place to look neither...

        I really don't know what to look for.


      4. Gianni Sandigliano


        I am running out of ideas, but still I am not convinced...if I would be in your shoes I'll dig into what's going on in your application BEFORE that unexpected end of B edit session.


      5. Ingo Stiller

        Hi Yves

        1. Your components/instances are "non-modal" as they are contained
          So the "EDIT" statement will always only signal UnifAce to start interactive but leaves immediatley with $status=0. This is the normal behaviour
          BTW: Will the component B ever shown and the vanish?
        2. The tab-container is the framework for the inner, contained instances.
          For each inner instance, the widget holds the name of this instance. When destroying an instance, the tab-widget still holds the instance name, but shows a blank surface.
          Also normal

        To check why the instance B is "destoyed", place some code in all relevant triggers of component B

        If you in UnifAce 9 place something like

        putmess "In trigger <$triggerAbbr>"

        into each of this trigger.
        If it is possible do this also for each other component involved.
        With out code in this triggers, UnifAce will not show you what it's doing

        Now repeat your tests.

        Maybe this will show you a clue, what's happen


      6. Ingo Stiller


        putmess "In trigger <$componentname>(%%$instancename%%%) <$triggerAbbr>"

        would be a better hint (smile)

      7. yves de M.

        Thanks Ingo,
        Too bad I already tried theses options and don't find anything relevant.

        We use the same component and structure in different parts of our ERP. But in one particular case it stops.

        I did send the question last week to uniface lab, with traces and logs, but I haven't got answer till yet.

        Anyway, thanks for your help and advices


      8. Ingo Stiller

        Hi Yves

        Do you have OPERATION CLEANUP in component B?

        Even if UnifAce do not show anything else, CLEANUP should always be triggerd:

        debug ; Should be called once

        debug ; should be trigger if the instance will vanished

        Did you a NEWINSTANCE "COMP_B",v_INST  or just ACTIVATE "COMP_B"?
        And is there any EXIT in component B?
        Not even in any global proc called by component B
        All OPERATIONS should end with RETURN and not EXIT

        If it is possible, place as many as possible lines like this

        putmess "%%$instancename%%%: Instance of COMP_B : '%%instances("COMP_B","")%%%' "

        into your surrounding code.

        Then you got a clue, when the instance in question is deleted

        If this all not work, then you should isolate the calls to COMP_B step by step until the instance don not disappear

        We do have things like this in older UnifAce versions.
        And as was a long, very long way to find the line in code which does destroy a instance.
        And then there will be potentially no workaround grumbel 


      9. yves de M.


        I did a trace with $proc_tracing and sql descriptin (Where & order by clause)
        So I have a more than 290000 lines log. Which I sent to Uniface. But they don't find anything neither.

        Yes, it's a newinstance and there is no exit called...
        And it's not a popup, so there is no reason to have an automatic close...
        And the same component, with the same service calls and nearly the same data to display works perfect in the same program.

        As you say, it a grumle situation.


      CommentAdd your comment...

      Hello Gianni

      We use a very strong MVC model. And in fact, these components don't manage any data.

      We have a high level controller H. It opens the main window and context frames. H creates the instances for A and B, and gives the instance of B to A for the display. Then it calls an other controller C, depending the context. And this controller makes the link between the data service and the display of these data.
      and C gives to H a list of buttons and a callback instance (itself). And H transfers theses info to B

      B is a generic display for some buttons. It displays the buttons according the list received from H, and keep the callback instance of C.
      When a button in B is clicked, it calls the callback instance and provides the information of the specific button. And then C knows what to do in response to the button clicked.

      The same pattern is used all along in our application. But in one case, the B component is created, the C controller does all the needed initialization, and when it gives the hand to the user, B closes itself and the buttons disappears. And it's not the situation with the most data or subscreen

      I don't know where or what to look for.

      Thanks for your adivices


        CommentAdd your comment...

        Hi Yves,

        your description is very high level. Try to be more focused in your A and B components and describe them more in details.

        Just few hints:
        - Is the application model structure used from A and B aligned with your test DBMS?
        - Could it be you are creating too many component instances?
        - Are those A and B components managing an editing session?
        - During execution you never see your B component? ...I mean: when it is crashing it is doing it before you see it first time?
        - Are those A and B components managing a lot of data?
        - If you build a simple A1+B1 form set without all the rest of your application you can see them working?

        Let us know...


          CommentAdd your comment...