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, 20187 yr by Explv

Dope

Bookmarked

explv == bae always returns true

Edited March 5, 20178 yr by Imateamcape

nicely done 

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, 20178 yr by Trees

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, 20178 yr by Explv

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.

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, 20178 yr by Explv

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)

Please note one of the widget actions changed, I have updated the code in the original post.

nice