Ha, this is certainly correct. Thanks for finding this. I’ll correct for this. Do you need it right now or can it wait for a future release? (i am in a long rework of the editor to make a menu with my own buttons)
@Jmv38 take your time, as long as I keep one button up I’m fine. btw love the button class, its quick and easy.
Thanks! Positive feedback is good, since i put all my love in my code!
I think the problem is in the touched function. I have added 1 line, that shold fix it:
function Buttons:touched(touch)
local lastTouched = Buttons.lastTouched
-- was a button touched? which one?
local n = #Buttons.list
if n == 0 then return false end -- no buttons
local newTouched
for i=1,n do
local j = n-i+1 -- button touches are scanned from top to bottom
local b = Buttons.list[j]
if b:touched(touch) then
newTouched = b
break
end
end
-- this part manage the case when touch occurs but outside of the button that
-- was touched last (sliding out of the button): then the button must be released.
-- NB: works correctly with only one touch...
if lastTouched and lastTouched ~= newTouched and lastTouched.isFireButton
then lastTouched:setState(false) end
if newTouched then
Buttons.lastTouched = newTouched
return true
else
return false
end
end
@Jmv38 could you add in the ability when changing a button setting to apply to the group and not just apply to all?
Hahaha! Was questionning myself about that too! Ok i’ll do it. I am also wondering about the ‘best’ way to implement group: just a property of a button (plus tables in Buttons), or a specific group class? The group class sounds logical but i am scared i could get lost with too many objects hierarchy… However if i add many group specific functionnalities, that should be better.
Btw, if you could post screenshots of what you’ve done with it, that would be useful for me to think of improvements.
@Jmv38 I actually have used it in places that I would normally use a parameter.action(), It’s simple to implement and I can keep my project full screen. I’ve also used it to make a d-pad on the fly.
It would be nice if the isFireButton would Chain call the callback based on the delay set, instead of using button:state.
The idea it that a ‘simple’ button fires the callback when you release your finger up.
Firebuttons are live fast multishoot buttons, so my idea was that i cant know what the user want exactly, so the button.state variable let him implement whatever he wants on top of that, In the draw() loop. Isnt this suffucient? The problem is that there are so many possible cases…
What is a d-pad?
D-pad is a directional set of buttons for controlling a game character.
@Jmv38 Dpad is like your sliding left to right buttons but also up and down As well. I had an idea for a drop down button which I’m adding to my ui class for my weapon changer which is a button on press down a few more buttons slide out from underneath it and you change your selection whilst pressed and moving then, on release the selected button calls the callback and the drop down buttons collapse
I see.
@luatee for the moment i am not ready to implement this, not because it is difficult, but because it is a buton group action, and i am not clear yet about what the groups really are.
@briarfox i finally understood what you meant with the firebuton callback and delay: you meant the delay would set the fire rate, correct? That is a good idea, i’ll do it.
I am also wondering:,should i keep the calback principle, os shold i switch to an event broadcast instead? Then you would specify the event name, not the callback function. One more line needed though to associate the even to a function somewhere else. But a better mechanism? What do you think?
@Jmv38 great news on using the delay! I like the idea of the button triggering an event. Lets say I give the user the option to setup a d-pad on the left or the right. There would be two different groups of buttons. One visible the other not. I just have both sets of buttons trigger the same set of events so I would only need to set one callback instead of having to set callbacks for each group. I vote events!
I will be a deep update. Probably 2 to 4 weeks.
@Briarfox you know what? Finally, groups are… event managers! That seems to solve all coordination problems in a very natural manner. Your discussion about event class really came right at the good moment!
@Jmv38 Awesome! Using an event manager is really neat. Can’t wait to see your button class and please update the event manager thread if you tweak your manager.
Actually i use your last version, unmodified. But for the moment i dont use extend(), i prefer to define an explicit event manager field for each use (there is a global event, inner event, group event and userEvent for the moment). I have added the userEvent system, but i have kept the callback system too, for those who would find the event system too scary to use.