Hi Awen,

once, I concepted a progress bar with a cancel-option.
not with a  GUI, but a simple UNIFIELD (which worked quite well).

Will check my notes andd see if can transfer it to nowadays versions.

SUccess, Uli

Hi Awen,

same situation as described by Wolfgang:
The solution with the Unifield worked well in V7, but in V8 the behaviour is totally different.

WIll investigate a bit in the next days

Success, Uli

Hi Awen,

Tony Marston once showed a tip on cancelling long retrieves:

http://www.tonymarston.net/uniface/tip02.html

May be you can get some inspiration out of that code?

Best regards, Arjen

We've got a generic solution which works perfect in Version 7, unfortunetly not in Versions above.

The basic idea is working with a second component (the "ESCAPE") which shows up an Escape-Button (an possibly sliders and whatsoever). The Master and Escape are communicating via "instancemessage" (Version 7!). The Escape gets "a bit time" (We did it with macro-Statements) to get active, that the user can press the Escape button. The master interrupts his process regulary to give the focus a very short time to the ESCAPE form.

...and it did work under Version 7 really perfect. We used it for retrieving-Processes, where we stepped through the hitlist ($curocc + Delta) until either the ESCAPE sends a break OR the hitlist was completed.

Unfortunetly since Version 8 it did not work any more...

We did some investigations on this problem in Version 8 (e.g. with async + postmessage), but not really successful. A solution can be found by using userver (on each client) to simulate this behaviour, but it was also a bit tricky. At the end we decided to choose the pragmatic way.

As I understand your problem, you don't need necessarily an additional form (ESCAPE-Form). Perhaps some of the ideas above can be useful
(interrupt the process, send a macro to prompt to an unused field, which is most of the time invisible, and continue the process in the Fields-Gets-Focus-Trigger .... somehow this way)

W.
 

Hi Awen,

just a quick solution which works in any uniface version:

- At start of the loop, create a STATUSFILE in the working directory.
- At each n-th cycle, test the existence of STATUSFILE to continue looping.
- At the end of the loop, delete the STATUSFILE in the working directory

And give your user a command file outside of the uniface application
to delete the STATUSFILE manually.

SUccess, Uli

Hi Awen,

we use some 3 GL code for interrupting (pressing the keyboard) long processes. If you are interested in, please contact me. I'll send you the related C source.

Regards,  Joern

First i'd like to thank everybody for taking time to answer this,

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
 

PeekMessage(&msg, NULL, WM_KEYDOWN, WM_KEYDOWN, PM_REMOVE) doesnt work properly under Windows 7 (under Windows XP OK) I used GetMessage instead...

Hello,

we use very similar solution... in 3GL we have a small form, this form is a new thread, so it "runs" independently from Uniface processing the code. There is a button like "cancel" which user can press to abort the long operation. From within Uniface proc code (cycle) we check the form regularry to get the status of the button - if it is pressed, the form is hidden and cycle ends... so the operation is aborted.

The only disatvantage is, that we show the form as always on top, so it is on the top of all other window applications, but this is something users can live with. This solution works fine with U8 and U93.

I have also tried to use Uniface progress bar and cancel button, but with no success. It seems like impossible task to do purly in Uniface. :( And unfortunatelly, Uniface's approach to modality is quite easy/basic/stupid (one can't mix modal and non-modal forms), which makes this task even harder. The 3GL solution seems to be good and working here.

Regards, Zdenek Socha