@robby There are some failing quickscript-test tests, probably due to race conditions: http://drdr.racket-lang.org/60618/cs/racket/share/pkgs/quickscript-test/drracket.rkt I need these steps to be done in a serial way: (queue-callback/res
(λ () (send drr create-new-tab)))
(wait-for-drracket-frame)
(run-script "show-counter")
(queue-callback/res
(λ () (check string-suffix? (send (get-text) get-text) "\n0")))
(wait-for-drracket-frame)
(run-script "increase-counter")
(run-script "increase-counter")
(run-script "increase-counter")
(queue-callback/res
(λ () (check string-suffix? (send (get-text) get-text) "\n3")))
(wait-for-drracket-frame) Is that the wrong way to do it?
Nothing jumps out at me as obviously the issue, I’m sorry to say.
Oh, I see one thing.
Note: The quickscript script is persistent, which means it retains its state from call to call (and updates the state)
The first line creates a new tab (in the queue’d callback) but the second line is waiting for a drracket frame, not waiting for a new tab.
The wait-for-drracket-frame window just waits for the front most frame to be a drracket window.
You might need to wait for something else in those places?
aha, that could explain the issue indeed. Is there a way to wait for the tab to be in keyboard focus?
you can write whatever predicate you need
Take a look at the implementation of wait-for-drracket-frame
Ok great, thanks, I’ll take a look this weekend hopefully
The essence of it is the call to poll-until
Right, I think I get the idea
There is some extra stuff in that function to print a message that you can ignore
The waiting for pending events might matter but might not depending on what’s going on but probalby you don’t want to rely on that.
If the work you’re starting is itself not going to finish on a single event (but queue’s other events) then you want to put that into your polling function
hth
Does this (test:menu-select "Scripts" "Tests" name) pushes something to the event queue, or is it synchronized?
From the code, it seems to be synchronized as I can see some semaphore waits, but I’m not 100% sure
The call to test:menu-select creates an event that selects the menu and puts that into the event queue.
That will trigger a call to that menu’s callback, which might just finish all its work or it might put more events into the queue, depending on what the menu item is/does.