Uniface on GitHub
Product (releases and patches)
Reported Issues (old)
Fixes and Updates
Hello, 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
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?
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.
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 => acceptif =10 => quitif any other value => an exit statement is forcing $status value...
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.
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.
To check why the instance B is "destoyed", place some code in all relevant triggers of component BThese 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
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
Do you have OPERATION CLEANUP in component B?
Even if UnifAce do not show anything else, CLEANUP should always be triggerd:
OPERATION INITdebug ; Should be called onceENDOPERATION CLEANUPdebug ; should be trigger if the instance will vanishedEND
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 BAll 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
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.
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
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...
© 2020 Uniface Privacy & Cookies | Privacy Statement | Legal