11 replies to this topic

[Twijn]

I need a way to make a loop continue while a function is called (that will also not return soon) and the function HAS to be called within the other function

[KingofGamesYami]

Wait, what? You want to run something in parallel?

[Twijn]

KingofGamesYami, on 18 November 2015 - 11:15 PM, said:

Wait, what? You want to run something in parallel?

Yeah, after reading that that was quite confusing

I need to be able to run a function within a loop and have the loop continue (hopefully that's better?)

[KingofGamesYami]

That makes more sense, and although I know how to do this, it's not necessarily the best idea in the world. You'd want to "piggyback" your code onto a function that's always called when events happen - coroutine.yield.

[Twijn]

KingofGamesYami, on 19 January 2019 - 11:45 AM, said:

That makes more sense, and although I know how to do this, it's not necessarily the best idea in the world. You'd want to "piggyback" your code onto a function that's always called when events happen - coroutine.yield.

I can't exactly think of a way to make it better... I'm trying to make a button api that runs on startup and will work indefinitely.

Edited by Twijn, 19 November 2015 - 02:05 AM.

[KingofGamesYami]

I use a function in my API that filters events, like this:

function handleEvents( ... )
  local tEventData = { ... }
  if (button was clicked) then
    return "button_click", other_data
  end
  return ...
end

I've actually added a check to it to detect if it was passed event data - and if not, will call os.pullEvent itself.

A different approach would be to add a function that simply handles your buttons and require the user to run it in parallel themselves.

[Bomb Bloke]

It'd be worth checking out the example in the touchpoint API thread, which shows that sort of "event filtering" system in action.

[Twijn]

KingofGamesYami, on 19 November 2015 - 03:10 AM, said:

I use a function in my API that filters events, like this:

function handleEvents( ... )
  local tEventData = { ... }
  if (button was clicked) then
    return "button_click", other_data
  end
  return ...
end

I've actually added a check to it to detect if it was passed event data - and if not, will call os.pullEvent itself.

A different approach would be to add a function that simply handles your buttons and require the user to run it in parallel themselves.

I don't exactly understand the first part... Could you explain it a bit more?

Also, for the user allowing it to run itself, that may cause a few issues.
Because it is a neverending loop, would it technically make multiple loops running at the same time that works off of the same table of buttons? Would that not cause buttons to trigger more then once?
I am also creating this for a different program I'm creating, so that would have its own loop as well. I also would prefer people to just be able to create the functions and add the buttons, it's way simpler.

[KingofGamesYami]

It's not simpler. The user should have control over the API, not the other way around. Seriously, it depends on how your API is structured.

My API forces the user to handle everything. It just makes events telling them a button was pressed and which one. From there, the user of my API has absolute control over everything - otherwise you start to get complicated work-around solutions to using my API, which isn't a good thing.

I do not use a loop. I force the user to make their own loop, because more than 50% of programs are going to need that loop anyway.

The other way I have managed things (when I want things to be simple) is to have my program work like read(). One of the function is a function that returns when a button is clicked, and the data related to that button. I feel this way is easy to transition to for new users, as they have undoubtably used read() before (and if not, why are they using my API?).

Edited by KingofGamesYami, 19 November 2015 - 04:42 PM.

[Twijn]

KingofGamesYami, on 19 November 2015 - 04:40 PM, said:

It's not simpler. The user should have control over the API, not the other way around. Seriously, it depends on how your API is structured.

My API forces the user to handle everything. It just makes events telling them a button was pressed and which one. From there, the user of my API has absolute control over everything - otherwise you start to get complicated work-around solutions to using my API, which isn't a good thing.

I do not use a loop. I force the user to make their own loop, because more than 50% of programs are going to need that loop anyway.

The other way I have managed things (when I want things to be simple) is to have my program work like read(). One of the function is a function that returns when a button is clicked, and the data related to that button. I feel this way is easy to transition to for new users, as they have undoubtably used read() before (and if not, why are they using my API?).

As I believe I said above, I'm going to be using the API additionally. It's going to be a sortof "OS" that provides APIs and other things that are useful to people that make public programs (or even private ones). I'd highly prefer it to just run indefinitely at the startup of the computer, which will overall be easier for people and me because then they do not need to set up any loop to run with the program, it's just all there.

Also, why exactly would people need the loop?e


I have been over thinking everything you have said and I have not made complete sense of it, obviously.

It is not that hard to make them create their own loops... It is actually quite simple.

Sorry for being so stupid. xD

Edited by Twijn, 19 November 2015 - 10:03 PM.

[Bomb Bloke]

Again, the touchpoint API example covers the scenario KoGY's talking about. If you don't understand what he's saying, I again suggest you go read that.

[Twijn]

Bomb Bloke, on 20 November 2015 - 12:57 AM, said:

Again, the touchpoint API example covers the scenario KoGY's talking about. If you don't understand what he's saying, I again suggest you go read that.

Oh, yeah, sorry, I completely didn't see your post somehow! I'll go check it out.