In Toad 17.1 and new beta the Session Browser refresh introduced a 1 second delay for refreshing details panels (Session, Process, IO, etc.), this is quite annoying as even when pressing F5 the values do not refresh immediately as before 17.1 and you need to wait at least a second before pressing F5 again (or refresh delays additional second, compounding the problem). Same goes when shanging active session rows on left side.
My use case: Usually session browser is useful when in need to detect fast changing values on the fly and I press refresh about 3x per second or switching fast between two sessions to catch what is needed at the moment at specific detail RHS tab and this is not possible anymore.
Intentionally, a slight delay on was added on refreshing the RHS as you move around in LHS. This was added because in older versions, if you moved around too much in the LHS, the the work that the RHS had to do would build up, sometimes resulting in a "catch-up" that it had to do (when the only thing that mattered was the last query it had to run).
Unintentionally, 17.1 introduced a blink on the RHS. That's what is fixed in the current beta and what I thought you were referring to.
I see that the F5 delay is still there. I'll see if I can remove it (but leave the click/change node delay).
For what it's worth, if you just want to refresh the RHS, you can F6 and there is no delay that way.
F6 is a good tip, helps for now. And future similar F5 would be great as F6 is not so prevalent keyboard shortcut for refreshing and easy to forget it exists.
I see now why this forced delay is needed in some cases. Would you consider adding a new option to specify the delay like 0..1000 ms like for example "Popup auto invoke delay (ms)" in Code Assist options. And maybe reduce the default to 500 (depends of cource on other people who have bunching problems)? Quite often I need to click through all sessions and 1 second is considerably long in this context and usually all RHS tab-s load in 100ms time subjectively.
Is it possible to make the delay dynamic or somehow detect if previous RHS query/queries have ended and if yes then no delay at all? But might be too big of rewrite if query and UI thread logic does not already have architecture to support this reliably.
Not really because the problem isn't just "has the previous query ended." It is also "is user likely to do something in the next 250ms (or so) that will cause the same query to fire again (maybe with different parameter values)"