GuiButton:Activate()

Feature Requests Engine Features
1

As a Roblox developer, it is currently too hard to run a GuiButton’s .Activated connection with code, currently if you wish to do such, you have to separate the function from the button, in alot of cases this would work, even if it’s inconvenient. However, with certain use cases, especially when working with buttons generated by code and not pre-made ui elements, this quickly becomes a problem. Solutions exist but they require alot of round about management of .Activated functions which could all be solved with this one feature.

If Roblox is able to address this issue, it would improve my development experience because it would make running .Activated connections with code much simpler for new and experienced devs alike. It makes sense to have a way to force run RBXScriptSignals like this as it can be very useful in many situations.

12 Likes
2

Could you give a scenario where this would apply?

3

I have cases whereas I need to do something like this but for different signals.
I think we should be able to fire signals, like in your case it would be GuiButton.Activated:Fire()

2 Likes
4

Sure, the actual case that inspired me to make this post is actually a bit different, where I have 10 buttons on a bottom bar that select items to place, I also have buttons in a larger grid like menu that accomplish the same task just more condensed as well as generated at runtime (it includes all placeable items not just the 10). I want to make it so clicking one button will activate the others since all the logic for animating them when .Activated is run to eliminate any sort of loops. A third variable also comes into play, where the bottom bar is labeled from 1-0, where in you can press numbers on your keyboard to activate those buttons.

Now sure, I’ll admit, other solutions exist that could fix this, perhaps just some better foresight when actually making these buttons, but even still, this feature would not only provide a very simple and elegant solution to problems like these, but also add more tools for developers to use when working with ui and buttons.

5

I would love to be able to fire any signals we want! I wanted to keep the scope of this request smaller to test the waters. I could also see some issues with being able to fire signals so maybe some would need to be disabled.

3 Likes
6

this would go great along with ClickDetector.MouseClick:Fire(), i’ve had a couple instances where i’d like to do that but i can’t remember when. if one doesn’t already exist, you should make a feature request for the ability to fire signals with scripts

4 Likes
7

Yeah, in my case, I wanted to fire GuiButton.MouseButton1Click
It would probably be limited to Gui stuff, I don’t know any other cases

8

Support. This could even be used for things such as an auto-clicker gamepass that clicks automatically for the player. It would make that kind of feature way easier to implement.

9

This is completely unnecessary.

Assume a standard GuiButton implementation:

local function doThing()
    -- ... do thing
end

Button.Activated:Connect(doThing)

What’s the difference between

Button:Activate()

and

doThing()

The fact that you would need to access the button instance to call the function. If you are binding a function anyways, call the function itself.

1 Like
10

its a lot simpler if you want to call it from a separate script

11

The difference is that Button:Activate() triggers the event, it may not seem that important to you, but this is incredibly valuable and helpful for any kind of automated behaviour a developer might want to make (granted, it would be better if we could just fire any signal to begin with).

If I’m writing tests that are detached from the actual code itself, I don’t have access to that function to manually call it and even then manually calling it defeats the purpose of the test because it’s different from how an ordinary user would trigger it. I’d either have to not write tests for those UIs or I’d need to hackily separate out UI logic into modules my tests can access.

5 Likes
12

So was I not right?

You have a function that is connected to an event. Event triggers function. Call triggers function.

What is preventing you from simulating that event activation? You aren’t forced to run a function off an event.

Just make it non anonymous?

Button press means event. Event means function call. The method to call the function is different, but the underlying architecture is the same.

I assume this is probably related to the existence of, say, Tool:Activate() and, for that, there is a purpose: Tools innately can only be activated via mouse press, this method exists so developers can implement custom activation methods for tools.

Buttons do not need this. This is because buttons require human input. You can achieve automation by writing, no offense, proper code. This solves a non existent problem. Every game with automation already knows how to do it, and they do it well.

1 Like
13

Please properly read my post instead of cherry picking the parts that support your argument.