This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
GamerNebulae's profile picture

Making pages and keeping track of elements on those pages

Started by GamerNebulae, 11 June 2014 - 09:44 PM
GamerNebulae #1
Posted 11 June 2014 - 11:44 PM
Hello everyone!

I was working on my API (it is a graphical API that you can use to make buttons on monitors, progress bars, etc.) and I was wondering if there was a way of how I can store information about the elements that are on that specific page so you can easily scroll through. This is my API so far: http://pastebin.com/EWTX5sAj
Bomb Bloke #2
Posted 12 June 2014 - 02:15 AM
You're really spoiled for choice here.

You could store a pageID number against each element. When drawing, you'd then check to see whether the page each element belongs to is active, and use that info to determine whether to go ahead and render it. Probably the "simple" way to do it, but not very efficient - when you go to draw a page, you'd need to check all stored elements to see if they're on it.

You could create a table of pages stored within the API, each page represented by a sub-table of elements that belong to it. When rendering a page, you just draw those elements which are registered within the relevant sub-table. This is more or less how my card API deals with piles of cards.

You could create a table for each page which is returned to the calling script when that page is created. That table would contain functions which render to that table - you'd then redraw that page by calling the functions within that page's table, instead of the functions within the original API. This is how ComputerCraft 1.6's window API operates.

You could do the same thing, but with a metatable (which should be rather more efficient in terms of memory usage). The source of the vector API is an example of that.
GamerNebulae #3
Posted 12 June 2014 - 09:49 AM
-snip-

Would I store functions inside the page table? Example:

page[#page + 1] = {
  mCreateButton(...),
  mCreateButton(...),
  mCreateButton(...),
  mCreateProgressBar(...)
}
Edited on 12 June 2014 - 07:49 AM
Bomb Bloke #4
Posted 12 June 2014 - 10:49 AM
Not if you're going to store that table in the API itself, no.

I mean, you could if you really wanted to. There's nothing stopping you. It's just pointless to have more than one copy of the functions if you don't need to have them.
GamerNebulae #5
Posted 12 June 2014 - 10:51 AM
-snip-

The way I had my API working is you can create a button or progress bar anywhere on the screen. That is why there are several of them and they are all separated by their Unique Idenitfier (variable ID). But would this work?
Edited on 12 June 2014 - 08:51 AM
Bomb Bloke #6
Posted 12 June 2014 - 04:15 PM
Sure.

One of your options is to just add a value to each element along these lines, specifying which page it's to be drawn on:

pbData[ID]["page"] = page

Then you could make a function somewhat along these lines:

function redrawPage(page)
  for elementID, elementTable in pairs(pbData) do
    if elementTable.page == page then
      mDrawProgressBar(elementID)
    end
  end

  for elementID, elementTable in pairs(bData) do
    if elementTable.page == page then
      mDrawButton(elementID)
    end
  end
end

Not terribly efficient, but hopefully you get the idea.
GamerNebulae #7
Posted 12 June 2014 - 05:55 PM
-snip-

I understand the method you described above, but now my question is: how would I execute my method?
Bomb Bloke #8
Posted 12 June 2014 - 11:15 PM
I'm not sure I'm understanding what you mean by "your method".
GamerNebulae #9
Posted 13 June 2014 - 12:25 AM
-snip-

By creating the table with the functions and after that iterate through the table.
Bomb Bloke #10
Posted 13 June 2014 - 02:42 AM
That depends on what you want to achieve. Are you planning on using that table to create elements? If so, why bother with a table? Or are you planning on using that table to just redraw them? In that case, you'd make a table containing tables (one sub-table for each page), and as you create the elements, add their IDs to said sub-tables.