@Dave1707 just for once, i wont agree with you. It is quite important in an app to have the buttons always at the same place: you get used to and dont even read the buttons any more. Like for keyboards: in latin countries, it is impossible to use english ketboard, and vice versa. But this is just a remark, i dont want to start a big argument on that! Keep helping people the way you do, this is excellent! I think your restless commitment might change the worldwide use of LUA in the long run… =D>
@Jmv38 The buttons are always drawing in the same spot, with the same title, it just doesn’t matter which one draws first or last or whatever order. What Sky was saying is that when using pairs, a table value might not be returned in a sequential order like it would be using ipairs. In my example, it doesn’t matter which button is first or last because the buttons don’t depend on their order. All of the individual button information is in a unique table position, so I can go thru the table forwards, backwards, or in random order and everything will still look the same and act the same. I know what you mean about keys always being in the same spot. There are many times where I end up with one of the letters “qwertyuiop” instead of one of the numbers “1234567890” because I didn’t switch to the numeric keyboard. I hit the correct key, just not the correct value. Thanks for the comment about helping. I think I’d rather write code to help then to write code to sell.
@dave1707 Yes, I guess it doesn’t matter in your example, but for everyone else learning from that I need to say that using pairs on an indexed table is bad coding practice. If you had a lot of buttons that might overlap, then it would matter which one was drawn first, and if they were added by the user they would be mad because it “didn’t make sense” the order they were drawn in.
@SkyTheCoder 1). Why would I draw buttons that are going to overlap ( bad coding practice ). 2.) It’s the responsibility of the programmer to learn how to code and the correct commands to use. 3). My examples are just that, examples. Are they exactly correct, no, they’re just meant to give a start on how to do something. If I was writing an app to sell, then I would be more careful of how I write code. So you’re going to continue to find things in my examples that aren’t exactly right.
There’s no need to get defensive, Dave. Sky is trying to help.
There are cases where you might draw overlapping UI elements, such as using containers to group buttons and input boxes together. I had to build a windowing interface into an OpenGL program a few years ago, and so I had to do all this from scratch: windows, buttons, input boxes, the whole thing.
Establishing a z-order is important when implementing a UI. What you want to do when drawing UI elements is always draw them from first to last, so the last item added to the list is displayed on top.
There are a couple of key things to do when hit testing controls: always draw them in the right order (the last item added should draw on top) and use a “handled” flag to stop processing events once a control has received the click/touch/whatever.
for example:
function touched(t)
for i,c in ipairs(controls) do
c:touched(t)
if c.handled then
break
end
end
end
You do your hit testing inside of each control, and if a control gets hit, you set the handled property to true. This causes the parent’s loop to break out as soon as some control announces that it received the touch.
And the cool thing is that you can nest this: so you can have a window control that loops through its children and does the same thing.
thx
@tomxp411 i do the same but a bit differently: c:touched(t) will return a value. true means it has been touched. If true, then i would break. I think it is superior because in your implementation c.touched has to be reset later or there will be problems. But you can also reset it at the beginning of the c:touched() function, so maybe it is equivalent… What do you think?