There's a discussion thread "Interrupting process" within this folder. I think, this is basicly what you are looking for ...

uniface.communityzero.com/content/discussions

Bad news: A direct uniface way of solving this problem is not yet known in the community... I also did spend a lot of time in this problem ...

Wolfgang

Hi,

Awen Linbourg has published a small C-routine to check "key pressed".

This (among others like random-numbers or setting windows default printer) is included in my dITo3tB DLL.

Will be published by the end of this months.

Success, Uli

Quoted from uniface.communityzero.com/content/discussions:

I finally choose to implement the 3GL method suggested by Joern: a function is scanning event queue of every windows managed by the thread. It returns the first key pressed, and removes the event from queue to prevent further (and unfortunate) UNIFACE processing.

It works perfectly well in this case.

C Source, to build my3gl.dll

#include <windows.h>

#include <h3gl.h>

XEXPORT(long) READ_KEY(void )

{

  if (GetQueueStatus(QS_KEY)) //quickest way to test for events in a queue

  {

    MSG msg;

    //REMOVING events to avoid side effects in application (like space activating buttons)

    if (PeekMessage(&msg, NULL, WM_KEYDOWN, WM_KEYDOWN, PM_REMOVE))

    {

        return msg.wParam;

    }

  }

  return 0;

}

in UNIFACE:

            activate "my3gl".READ_KEY() ;perform "READ_KEY"
             ; testing for ESPACE or ESCAPE or SCROLL LOCK or PAUSE
            if (($status == 32)||($status == 27)||($status == 145)||($status == 19))
                  askmess "Cancel ?"
                  if ($status = 1)
                    return(1)
                  endif
            endif
 

Hi all,

I took the liberty to enter a wish for this on the list. (Note, because I'm from the Lab does not mean I determine priorities, but it does mean I think it is a good enhancement ;-)

Whish item: Have the posibility to interrupt a Uniface process

Gerton

Hi Gerton,

we (all) include some check of a signal in long-running loops.
 

As far as I see it, the cause is in another area:

as long as uniface runs a proc, ALL other messages to the window are NOT HANDLED at all.

Up to V7, at least unifield triggers have been processed immediately (so you could use a keyboard-activated <DTLF>), this has changed in V8.

Now only 3GL features like "KEY_READ"  or "outside" signals can be used:
create a file in the working dir and check if it still exists (the user has to delete it to stop the loop).

Or to access the queue directly

Success, Uli

P.S.  I understand that while working in a proc, all data etc. should be stable;
but would it be an option to accept at least messages from "CONTROL" widgets directly?
This would enable QUITs as well as EXITs as STOP-LOOPs ...

I guess we would introduce a separate thread for the keyboard interrupts, which would update an interrupt stack. The Proc code could than check at all time the interrupt stack for interrupts it wants to respond on.

Or something... :-)

Good morning David,

you are looking at an old Uniface problem...

My experience:  
No, a Uniface client seems to be a "single thread" solution. There is no way to work with interrupt.
Exept a new widget "ProgressBar with Cancel-button" - you can add it on the Uniface wishList.

But there are some workarounds:

- ESC will work, if the keboard is properly defined (but you can not show a button to press)

- you can realise a service, which works in steps of let say 100 lines, than stops and sends a message to the frontend with the progress bar.
  The frontend sends a postmessage "next step" to the service and than executes "edit". - At this moment it can response to a "press button".

Kind regards,

Rik