Explv Posted March 5, 2017 Posted March 5, 2017 (edited) import org.osbot.rs07.api.filter.Filter; import org.osbot.rs07.api.ui.RS2Widget; import org.osbot.rs07.api.ui.Tab; import org.osbot.rs07.event.Event; public final class ToggleShiftDropEvent extends Event { @Override public final int execute() throws InterruptedException { if (Tab.SETTINGS.isDisabled(getBot())) { setFailed(); } else if (getTabs().getOpen() != Tab.SETTINGS) { getTabs().open(Tab.SETTINGS); } else if(getShiftDropWidget() == null || !getShiftDropWidget().isVisible()) { getGameSettingsWidget().interact(); } else { boolean enabled = getSettings().isShiftDropActive(); if (getShiftDropWidget().interact()) { Sleep.sleepUntil(() -> getSettings().isShiftDropActive() != enabled, 3000); setFinished(); } } return random(100, 200); } private RS2Widget getShiftDropWidget() { return getWidgets().singleFilter(getWidgets().getAll(), new WidgetActionFilter("Toggle shift click to drop")); } private RS2Widget getGameSettingsWidget() { return getWidgets().singleFilter(getWidgets().getAll(), new WidgetActionFilter("Controls")); } } class WidgetActionFilter implements Filter<RS2Widget> { private final String action; WidgetActionFilter(final String action) { this.action = action; } @Override public boolean match(RS2Widget rs2Widget) { if (rs2Widget == null) { return false; } if (rs2Widget.getInteractActions() == null) { return false; } for (String action : rs2Widget.getInteractActions()) { if (this.action.equals(action)) { return true; } } return false; } } Edited July 10, 2018 by Explv 11
Team Cape Posted March 5, 2017 Posted March 5, 2017 (edited) explv == bae always returns true Edited March 5, 2017 by Imateamcape 1
Trees Posted April 28, 2017 Posted April 28, 2017 (edited) Thanks for the snippet, I changed the match code around a bit. Using try/catch avoids needing to check rs2Widget/getInteractions for null, and using Arrays.asList avoid needing to iterate the array. Since we are talking about <5 actions 99% of the time, it's kinda insignificant, but still looks better. @Override public boolean match(RS2Widget rs2Widget) { try { return Arrays.asList(rs2Widget.getInteractActions()).contains(action); } catch (Exception e) { return false; } } Edited April 28, 2017 by Trees
Explv Posted April 28, 2017 Author Posted April 28, 2017 (edited) 4 hours ago, Trees said: Thanks for the snippet, I changed the match code around a bit. Using try/catch avoids needing to check rs2Widget/getInteractions for null, and using Arrays.asList avoid needing to iterate the array. Since we are talking about <5 actions 99% of the time, it's kinda insignificant, but still looks better. @Override public boolean match(RS2Widget rs2Widget) { try { return Arrays.asList(rs2Widget.getInteractActions()).contains(action); } catch (Exception e) { return false; } } Exceptions are supposed to be used in exceptional circumstances, not for normal flow control. It is the best practice in my opinion to null check here. Edited April 28, 2017 by Explv
Trees Posted April 29, 2017 Posted April 29, 2017 6 hours ago, Explv said: Exceptions are supposed to be used in exceptional circumstances, not for normal flow control. It is the best practice in my opinion to null check here. They can be used for normal flow in order to avoid excessive nested if statements. Maybe not needed here though. Would recommend creating a var to hold the interact options though so you don't call it twice.
Explv Posted April 29, 2017 Author Posted April 29, 2017 (edited) 10 hours ago, Trees said: They can be used for normal flow in order to avoid excessive nested if statements. Maybe not needed here though. Would recommend creating a var to hold the interact options though so you don't call it twice. Yes they can, but they shouldn't, it's bad practice. When you know that a null value is possible, you should use control flow statements to handle it. Again, exceptions should be used for exceptional circumstances. Using try & catch for program flow in a non-trivial scenario can even decrease performance due to the overhead of garbage collection. If you want to create a variable to hold the interact options, go ahead, I personally did not feel the need to micro-optimise every little bit of this code, which will likely only ever be called once in a script. Edited April 29, 2017 by Explv 1
Trees Posted May 1, 2017 Posted May 1, 2017 On 4/29/2017 at 10:24 AM, Explv said: Yes they can, but they shouldn't, it's bad practice. When you know that a null value is possible, you should use control flow statements to handle it. Again, exceptions should be used for exceptional circumstances. Using try & catch for program flow in a non-trivial scenario can even decrease performance due to the overhead of garbage collection. If you want to create a variable to hold the interact options, go ahead, I personally did not feel the need to micro-optimise every little bit of this code, which will likely only ever be called once in a script. Actually in most c-based programming languages, using a try-catch flow can actually provide better performance (not sure if that's regarding exceptions or not)
Explv Posted July 10, 2018 Author Posted July 10, 2018 Please note one of the widget actions changed, I have updated the code in the original post.