wxLua - How do I implement a Cancel button? - lua

I have a wxLua Gui app that has a "Run" button. Depending on selected options, Run can take a long time, so I would like to implement a "Cancel" button/feature. But it looks like everything in wxLua is working on one Gui thread, and once you hit Run, pressing Cancel does nothing, the Run always goes to completion.
Cancel basically sets a variable to true, and the running process regularly checks that variable. But the Cancel button press event never happens while Running.
I have never used co-routines; if the Run process regularly yields to a "Cancel check" process, will the Cancel event happen then?
Or is there another way?

(the following assumes that by "Run" you mean a long running operation in the same process and not running an external process using wxExecute or wxProcess.)
"Cancel" event is not triggered because by executing your Run logic you have not given a chance to the UI to handle the click event.
To avoid blocking the UI you need to do something like this. When you click Run button create a co-routine around the function you want to run:
coro = coroutine.create(myLongRunningFunction)
Your Run event is completed at this point. Then in EVT_IDLE event you will be resuming this coroutine as long as it's not complete. It will look something like this:
if coro then -- only if there is a coroutine to work on
local ok, res = coroutine.resume(coro, additional, parameters)
-- your function either yielded or returned
-- you may check ok to see if there was an error
-- res can tell you how far you are in the process
-- coro can return multiple values (just give them as parameters to yield)
if coroutine.status(coro) == 'dead' then -- finished or stopped with error
coro = nil
-- do whatever you need to do knowing the process is completed
end
end
You will probably need to request more IDLE event for as long as your process is not finished as some operating systems will not trigger IDLE events unless there is some other event triggered. Assuming your handler has event parameter, you can do event:RequestMore(true) to ask for more IDLE events (RequestMore).
Your long-running process will need to call coroutine.yield() at the right time (not too short as you will be wasting time to switch back and forth and not too long for users to notice delays in the UI); you probably need to experiment with this, but something timer-based with 100ms or so between calls may work.
You can check for Cancel values either in your IDLE event handler or in the long-running function as you do now. The logic I described will give your application UI a chance to process Cancel event as you expect.

I don't use WXWidgets, but the way I implement cancel buttons in my lua scripts which use IUP is to have a cancel flag, which is set when the button is pressed and the progress display is checked for during the run.
Usage is like this
ProgressDisplay.Start('This is my progress box',100)
for i=1,100 do
ProgressDisplay.SetMessage(i.." %")
fhSleep(50,40) -- Emulate performing the task
ProgressDisplay.Step(1)
if ProgressDisplay.Cancel() then
break
end
end
ProgressDisplay.Reset()
ProgressDisplay.Close()
If you want to see the definition for the ProgressDisplay see:
http://www.fhug.org.uk/wiki/doku.php?id=plugins:code_snippets:progress_bar

Related

Will actionlib.SimpleActionClient.cancel_all_goals block until completion?

Suppose I have the following:
action_client.cancel_all_goals()
print(action_client.get_status() != 'ACTIVE')
Is the above guaranteed to print True every time?
In other words, does SimpleActionClient.cancel_all_goals() cancel all goals before returning, or does it just send instructions to
cancel goals without waiting for the goals to be really cancelled?
action_client.cancel_all_goals() just sends an instruction to cancel goals without waiting.
Since the documentation of the method is not very helpful you need to have a look to action_client.h or action_client.py to find out whats happening.
The code shows that to cancel all goals only a simple message is published (self.pub_cancel.publish(cancel_msg) or self.pub_cancel.publish(cancel_msg)). This means the call is asynchronous and will not block.
This means your code
action_client.cancel_all_goals()
print(action_client.get_status() != 'ACTIVE')
will typically print False but this is not guaranteed because:
The client could be already PREEMPTED, ABORTED, ... before
ROS is not deterministic, this means in theory the client could be cancelled between the calls of cancel_all_goals and get_status due to a thread switch.

Cancel long-running TFDBatchMove while in progress

How can I cancel a batch move after calling TFDBatchMove.Execute, while it is still in progress? E.g. if the user presses a Cancel button on the form. I don't see any kind of Cancel method on TFDBatchMove.
I've tried using
raise Exception.Create('Aborted');
in the OnProgress event of the TFDBatchMove (checking a Cancelled flag set by the Cancel button), but after pressing Ok on the exception message window, the batch move continues.
Another possibility is to just close the Reader component, or set Reader := nil in mid flight, but this seems like a bit of a hack.
Call the AbortJob method. It's described like:
Use the AbortJob method to stop the current data movement.
After a call to AbortJob, the method stops reading data from the
reader data source, stops writing data to the writer and terminates
Execute method.

How to wait for UI element without failing test case

I have a dialog that displays on first execution of my app. I therefore want my test case to handle responding to the dialog - but only if it appears.
The waitForExpectations method will error out if the timeout is reached.
What is the best way to wait for this element to appear for a short time without failing the test case if it does not appear?
You will have to reimplement waiting. As terrible as it sounds, I recommend using Sleep and If statements; you want to lock your test thread while it waits for the app to finish presenting content, then evaluate.
Unfortunately, as far as I'm aware none of the options for waitForExpectationsWithTimeout permit you to not fail the test if the expectationForPredicate is not fulfilled at the end of the timeout time.
Try the following code:
addUIInterruptionMonitorWithDescription("SYSTEM_DESCRIPTION") { (alert) -> Bool in
alert.buttons["BUTTON_TITLE"].tap()
return true
}
app.buttons["BUTTON_TITLE"].tap()
app.tap()
SYSTEM_DESCRIPTION is the title or description of system alert.
BUTTON_TITLE is like "OK", "Allow", ...
Find out more in this answer:
https://stackoverflow.com/a/32228033/6657951

abort long running process of a database table : ideas ?

I must process a very long database table an think of the most common way to abort this loop. The principal code sequence goes like this
procedure TForm.ProcessmyTable(Sender : TObject);
begin
.....
myTable.first;
repeat
ReadSingleRecordfromTable ( MyTable, aRecord) ;
ProcessMyRecord(aRecord) ;
MyTable.next;
until MYTable.EOF;
end;
unit .... ;
procedure ProcessMyRecord(aRecord : TMyDataRecord) ;
begin
// do not have user interface stuff here
// Application.Processmessages will not work here !!!
.... ( long running code sequence)
end;
Could do a timer and break the loop based on the timer with var as a flag support .... but is this really the most clever way of solving this issue?
If this code runs in the main thread, then you will need to service the message queue (i.e. call Application.ProcessMessages) if you want the user to interact with your program and abort. In which case I think you already know the solution. Call Application.ProcessMessages. If the user chooses to abort, set a boolean flag and check that flag regularly in the inner-most loop.
Of course, this is all rather messy. The fundamental problem is that you are performing long-running actions on the GUI thread. That's something you should not do. Move the database processing code onto a different thread. If the user chooses to abort, signal to the thread that it is to abort. For example a call to the Terminate method of the thread would be one way to do this.
When do you want to abort? If it takes too long of if the user says 'stop'?
In both cases change your
until MYTable.EOF;
to
until MYTable.EOF or Aborted;
then set your Aborted boolean either when the timer triggers or when the user presses a key (note that you then have to use Application.ProcessMessages in the loop for the program to be able to process the keypress). This will not abort in your processing routine but after each record. If that is not fast enough you will have to show your record processing routine.
If it's such a long process that the user might want to abort surely in a windows app there should be some interaction with the GUI, a count of records done or a progress bar (if not on every record then on a periodic basis) any call to update a label or progressbar will provide the opportunity to set an abort flag (so processmessages is not required). Plus if the user can see some progress they may be less likely to abort when bored but 95% complete.
IMHO :)

QTP Recovery scenario used to "skip" consecutive FAILED steps with 0 timeout -- how can I restore original timeout value?

Suppose I use QTPs recovery scenario manager to set the playback synchronization timeout to 0. The handler would return with "continue with next statement".
I'd do that to make sure that any following playback statements don't waste their time waiting for the next non-existing/non-matching step before failing:
I have a lot of GUI tests that kind of get stuck because let's say if 10 controls are missing, their (consecutive) playback steps produce 10 timeout waits before failing. If the playback timeout is 30 seconds, I loose 10x30 seconds=5 minutes execution time while it really would be sufficient to wait for 30 seconds ONCE (because the app does not change anymore -- we waited a full timeout period already).
Now if I have 100 test cases (=action iterations), this possibly happens 100 times, wasting 500 minutes of my test exec time window.
That's why I come up with the idea of a recovery scenario function setting the timeout to 0 after/upon the first failed playback step. This would accelerate the speed while skipping the rightly-FAILED step, yet would not compromise the precision/reliability of identifying the next matching GUI context (which creates a PASSED step).
Then of course upon the next passed playback step, I would want to restore the original timeout value. How could I do that? This is my question.
One cannot define a recovery scenario function that is called for PASSED steps.
I am currently thinking about setting a method function for Reporter.ReportEvent, and "sniffing" for PASSED log entries there. I'd install that method function in the scenario recovery function which sets timeout to 0. Then, when the "sniffer" function senses a ReportEvent call with PASSED status during one of the following playback steps, I'd reset everything (i.e. restore the original timeout, and uninstall the method function). (I am 99% sure, however, that .Click and .Set methods do not call ReportEvent to write their result status...so this option might probably not work.)
Better ideas? This really bugs me.
It sounds to me like you tests aren't designed correctly, if you fail to find an object why do you continue?
One possible (non recovery scenario) solution would be to use RegisterUserFunc to override the methods you are using in order to do an obj.Exist(0) before running the required method.
Function MyClick(obj)
If obj.Exist(1) Then
obj.Click
Else
Reporter.ReportEvent micFail, "Click failed, no object", "Object does not exist"
End If
End Function
RegisterUserFunc "Link", "Click", "MyClick"
RegisterUserFunc "WebButton", "Click", "MyClick"
''# etc
If you have many controls of which some may be missing and you know that after 10 seconds you mentioned (when the first timeout occurs), nothing more will show up, then you can use the exists method with a timeout parameter.
Something like this:
timeout = 10
For Each control in controls
If control.exists(timeout) Then
do something with the control
Else
timeout = 0
End If
Next
Now only the first timeout will be 10 seconds. Each and every subsequent timeout in your collection of controls will have the timeout set to 0 which will save your time.

Resources