brutal random end of a contained composant

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...

Gianni

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

Yves

Hi Yves,

Now your appl scenario is a little more clear... a little... 🙂

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?

Gianni

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.

Yves

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"?
   OR
- 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...

Gianni

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.

Yves

Yves,

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.

Gianni

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
These are: INIT,CLEANUP,QUIT.ACCEPT,FRLF,FRGF,ASYS

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

Ingo

PS:

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

would be a better hint 🙂

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

Yves

Hi Yves

Do you have OPERATION CLEANUP in component B?

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

OPERATION INIT
debug ; Should be called once
END

OPERATION CLEANUP
debug ; should be trigger if the instance will vanished
END

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

BTW:
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 

Ingo

Hi,

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.

Yves