Can't address new table (problem with "self" var)

The Setup : I have a message window, kind of like you’d see in an old RPG.

  • It closes, adds text, and reopens with :page()
  • If new window info is passed, :page() destroys the old window and builds a new one between open/close.

The Problem : Internally, my code is finding the wrong table and I can’t figure out how to prevent it?

Code Example (simplified)

  1. Object and use

[code]
– Make the object
local window = makeWindow()
window.page = page

– Continuous text functions
local function text1() window:page(“Even here!”, { width = 72 } )
local function text2() window:page(“Still working.”, { onTouch=text1, width = 28 } )

– Start text
window:page(“Hi there!”, { onTouch = text2 } )
– Because a new width is passed, I destroy and rebuild the window[/code]

  1. The function

[code]local function page(self, text, options>
if options.width then
destroy(self) – calls display.remove(self) and self = nil
self = makeWindow() – now self = a new table!
self.onTouch = options.onTouch – reassign the touch event (not the listener, but to execute on successful touch)
end

self:toggle(“open”) – make the window reappear
self:setText(text) – print out the text.
end[/code]

  1. Results:
  • Touch: Indicates the new window made.
  • When executing text2(), still talking about the original window not the new one.

So I guess at this point I’m asking if it I destroy self, what happens to the outside variable referencing it, and is there a more realistic way to pull this off? [import]uid: 41884 topic_id: 35316 reply_id: 335316[/import]

Alright, so in the off chance someone sees this, I’m guessing that:
a. “window” is a direct reference to table 0x1
b. changing self means that the new object is table 0x2
c. “window” is still referring to table 0x1 regardless.

So what I’m trying to figure out is if there’s a way to change self such that “window” refers to the new object…without going outside of the function. [import]uid: 41884 topic_id: 35316 reply_id: 140380[/import]

That’s a good question Richard… and above my pay-grade. I think what you suspect is right. Have you tried to print the value of the table so you can see the address and see if it’s changing like you expect? [import]uid: 199310 topic_id: 35316 reply_id: 140406[/import]

Yeah, that’s why I posted. :wink: 0x1 and 0x2 are simplifications but the basic gist is that window and the self var differ from that point in time and there’s no internal way to link the two again.

I was really hoping to keep that code internal but it seems that when you destroy code for any reason that’s the end of the line as far as manipulating it.

I’m thinking of maybe keeping the core displayGroup but trying to destroy the display objects it holds…totally non-trivial but could work. [import]uid: 41884 topic_id: 35316 reply_id: 140435[/import]

Alright, so in the off chance someone sees this, I’m guessing that:
a. “window” is a direct reference to table 0x1
b. changing self means that the new object is table 0x2
c. “window” is still referring to table 0x1 regardless.

So what I’m trying to figure out is if there’s a way to change self such that “window” refers to the new object…without going outside of the function. [import]uid: 41884 topic_id: 35316 reply_id: 140380[/import]

That’s a good question Richard… and above my pay-grade. I think what you suspect is right. Have you tried to print the value of the table so you can see the address and see if it’s changing like you expect? [import]uid: 199310 topic_id: 35316 reply_id: 140406[/import]

Yeah, that’s why I posted. :wink: 0x1 and 0x2 are simplifications but the basic gist is that window and the self var differ from that point in time and there’s no internal way to link the two again.

I was really hoping to keep that code internal but it seems that when you destroy code for any reason that’s the end of the line as far as manipulating it.

I’m thinking of maybe keeping the core displayGroup but trying to destroy the display objects it holds…totally non-trivial but could work. [import]uid: 41884 topic_id: 35316 reply_id: 140435[/import]