Hi,

perhaps it is enough to make the component visible; so a:

 "SHOW"  in front of the
"EXIT" may help.

Success, Uli

Hi Uli,

no, this does not help at all. In fact, our form is visible all the time (there are data and log on the form and user can start/stop the timer, change parameters etc.). If the timer is running, there is a counter and if it reaches 0, the form is exited.

Nothing helps, we did not change anything on that form for years, in U8.4 it workes fine, after migration to U9.3, exit just does not exits the form. That's all. Definitely a bug in Uniface9 (or changed behaviour, since, according to documentation, exit shout exit the current component immediately). We are forced to use macro quit instead of exit, but this is just a stupid workaround (we do not want to activate quit trigger, we just need to exit the form, unfortunately it is impossible, since exit does not work here :-/).

Kind regards,
Zdenek Socha

I tested the SHOW command, but with the same negative result as sochaz. In my case I don't want the users to use the quit-button, but of course I can prohibit this by some kind of component-variable that makes quit-trigger execute only if the macro "^quit" is executed from the asynchronous interrupt trigger. 

Regards RogerW.

A similar problem with Uniface9.3 compared to Uniface7 and the asynchronous-interrupt trigger is the following: FormA is starting FormB, the asynchronous-interrupt trigger of FormB is starting FormC. FormC does  
exit(0),"FormA"
 to go directly back to FormA. FormC is stopped but FormB isn't stopped but set focus and the code point somehow lost. 
There is no problem  if FormC is started from a button, then both FormC and FormB are stopped and FormA set focus.
Any advice appreciated!

Regards RogerW.

PS. This is an old Uniface7 application, closing forms automatically and the forms are modal. I wouldn't like to make too many changes, fex. a change to non-modal forms, as I remember there where some problems with that.

I got it working somehow!?!
What I learned is that you shouldn't expect that asynchronous trigger code is working the same in Uniface7 and Uniface9. And you must probably rewrite your timers, fex. using the UTIMER.

Regards RogerW.

Hi Roger,

DLLs you used in V7 have to be recompiled and linked with the libs of V8.

These new DLLs can be used in V8 and V9.

Success, Uli

V8? Why not link with the right Uniface9 version 3GL libs?

Regards RogerW.

Hi Roger,

you are right; I see the uniface-world from a "V7 to V8 and V8 to V9" angel so i named the V8 3gl-environment.
But if one jumps direct into the V9 environment, he  does not have to install a V8 to get his DLLs done.

There is no difference between V8 and V9 (at least as far as I have tested legacy DLLs),
so no need to recompile/link when migrating from V8 to V9.

Success, Uli

Hi Uli,

You are probably right that the compilation prcedure etc. are the same but even between Uniface9.2 and Uniface9.3 the Uniface lib files are of different size. So I suppose that it's a good habit to use the libs shipped by the used Uniface-version, or ...?

Regards RogerW. 

Hi Roger,

I spoke in the context of legacy DLLs like UTIMER where the V7 version does not work in V8 or V9 environments.

For new 3GL features, the makes a difference and you should (if possible) use the 3gl-libs which come with your environment.
Thanks for your hint on that; it was not meant that nothing has changed 3gl-wise since V8.

But if you go from V9.2 to V9.3 in your production environment, your "old" DLLs can still be used with the higher version.

Success, Uli

P.S. Hope I have not confused too many uniface-developers

Hi Roger,

may be your observations are caused by the difference between modal and non-modal forms.

As in the good-old-days, modal forms were managed as a (linear) stack,
so a "go back to xyz" was always possible.

non-modal forms are managed as a pool,
where the sequence of forms does not matter.

But: you can create components attached to a "parent" component.
These attached components only live as long as theparent component exists.

Success, Uli

P.S. perhaps some lab-people can validate my statements (I'm only 80% shure)

Hi Uli,

As I mentioned/meant, I'm trying to do migration from Uniface7 to Uniface9 with as small changes as possible. So, I try to preserve the forms modal if they are modal in the Uniface7 application. The migration has worked very well, except for this small application using a timer and the asynchronous interrupt trigger.  Fex. the 3GL timer that I used before, used some Uniface 3GL functions that didn't work anymore and the asynchronous interrupt trigger code behaved in another way than in Uniface7.
Of course there have to be differencies between Uniface7 and Uniface9, but just a warning to others, there can be bigger differencies in this kind of code ....

Regards RogerW.

PS. UTIMER was quite easy to use and there is a video on YouTube about it.

Hi,

we have the same problem after migration. We spotted this problem in production after migration (from U84 to U93). We use our own timer in our own dll, but the same problem... exit does not exit the form. If we can see the form and then click to a field, the form is suddenly exited.

I have reported this problem to CPWR on May 2009 already, unfortunately they refuse to fix this bug and provided me with many workarounds. :( We consider this rather big migration issue, nevertheless, ppl from Uniface technical support still refuse to fix this bug. :(

Regards,

Zdenek Socha