Yes it addresses both issues.
First, itâs a bit odd that two posters have a walk-through a Stop....Most of the time it is a StopLimit and then it is in 99% of all cases due to a traders-mistake of setting the Limit-price to tight to the Stop-price (which should be wider than the Spread, otherwise it will walk -through).
But I have seen cases in the past (which I analyzed to the bottom) that a Stop or StopLimit did indeed not work on the IB-Server, it is because of this fact, that ButtonTrader has a safe-guard-procedure, which monitors the Stop-processing on the IB-server....as soon as it notices that the stop does not function (within 2 seconds) ButtonTrader will intervene by forcing an immediate close (fully automated).
But I have to say that I have not seen it recently in real trading (it happens regularly on the demo and simu-accounts, but is very rare in real-trading or an issue of the past (IB is on top of it to solve issues like this)).
The other issue is the way the triggering works on the IB-server. It will trigger a Buy StopLimit when the Bid-quote hits your Stop-price (or passes it). Then the Ask is already a few pips higher, so your Limit-order (of the activated StopLimit) might enter the market somewhere in between the Bid and Ask. This Buy will not execute (is not on the Ask) but becomes the best Bid (and when the market runs higher then you have your walk-through already).
That is the way triggering works on the IB-Server, which is quite normal, by the way, and is the wanted behavior by many traders....But not by all traders...so ButtonTrader offers you several other triggering-mechanisms (a bit too much to explain them here (see Ref-guide)), but in short: you can select triggering on Bid, on Ask, or on Mid-Point, etc.
So if you select Ask-triggering for the case above. Then the trigger will work much faster and you will not have any slippage (related to the trigger-price). But of course also this triggering-method has its disadvantages (when the market spikes with a wide spread it might close your position earlier than wanted {but also this can be solved, by using a hit-counter, which delays the trigger by counting first a number of spike-hits (see Ref-Guide)}).
Hope it helps
