Preserved text after remove? Huh?

[richard9]

May be going crazy. May just need to run a newer build. May just be doing things the wrong way entirely.

[code]-- I’m doing this because setting the text and reference point
– for existing text doesn’t behave well if the text is using text wrap…
– (by setting width / height)

– 1. Remove the text object
textObject:removeSelf()

– 2. Set display properties anyway!
textObject:setReferencePoint(display.CenterReferencePoint)
textObject.x, textObject.y = 200,200[/code]

If you comment out section (2), the text is gone. If you leave it uncommented, the text stays!

To make things worse…

-- 1.5 if something == false then local textObject = display.newText("something else", 0, 0, nil, 20) end

If you add that code, there are now two (2) text objects, each sharing the formatting.

Is this expected? A bug? Any thoughts?

(OSX, 2011.712) [import]uid: 41884 topic_id: 20816 reply_id: 320816[/import]

[Danny]

Depends how your structuring your code.

If your doing that in a loop it’s going to simply double up.

[import]uid: 84637 topic_id: 20816 reply_id: 81940[/import]

[bejoy]

richard9 - check our code. you might be adding the text object twice or more. [import]uid: 84539 topic_id: 20816 reply_id: 81954[/import]

[carlos_m_icaza]

don’t delete?

just
look at member text in the text display object.

http://developer.anscamobile.com/content/displaynewtext

myText.text = “Hello World!”

blah blah blah

myText.text = “Carlos woz here”

blah blah blah

c.
[import]uid: 24 topic_id: 20816 reply_id: 81973[/import]

[richard9]

Danny, that was my first thought too, but it’s not a loop (it’s a function call.) I’ll keep debugging…

Carlos, that was the original plan, but I’m having some problem keeping positioning after setting width and height (for word-wrap purposes). Despite setting the same display.TopLeftReferencePoint and x/y I was noticing x/y shift on reload.

…I gotta find a way to insert into a display group without obliterating the x/y I set… [import]uid: 41884 topic_id: 20816 reply_id: 81983[/import]

[Danny]

Maybe you should be doing :

display.remove(textObject) textObject = nil [import]uid: 84637 topic_id: 20816 reply_id: 81986[/import]

[richard9]

Danny, you’ve hinted at the solution, but it’s a bit more convoluted than that. My bad, let me explain

[code]textObject:removeSelf()

local doStuff1 = function()
textObject = display.newText(“blah”)
end

local doStuff2 = function()
print(textObject.x…", "…textObject.y)
end

local doStuff3 = function()
textObject:setReferencePoint(CenterReferencePoint)
textObject.x, textObject.y = 100, 100
end[/code]

If I call only doStuff1(): It works fine. I gather that despite removeSelf() being called, ‘textObject’ is still in the namespace, so I overwrote it.

If I call only doStuff2(): It works fine. (Maybe because when you call removeSelf() a table persists as per intended?)

If I call only doStuff3(): As best I can tell, feeding new information to textObject caused it to be pulled out of garbage collection, so it reappears!

This could be intended for all I know but was a surprising find nonetheless. I thought removeSelf() would do the job but I guess I need to make a superRemoveSelf() function

Danny, your suggestion works perfectly. I just found out the long way…For some reason I had led myself to believe removeSelf() was preferred over display.remove(). No idea why. [import]uid: 41884 topic_id: 20816 reply_id: 81994[/import]

[Danny]

Sorry your last part confused me, so its all working now ? [import]uid: 84637 topic_id: 20816 reply_id: 81995[/import]

[richard9]

Yeah, I’ve got it not duplicating now.

Lesson 1: Don’t use removeSelf() with display objects
Lesson 2: object = nil

I was hoping it was as easy as just pointing the variable at new content but that just makes dupes unless you are willing to use = nil and give up locality.

Still no idea how to get an object to preserve x/y upon group insertion, (and I gotta debug that weirdness with alignment on wrapped text) but that’s not the topic

[import]uid: 41884 topic_id: 20816 reply_id: 81996[/import]

[Danny]

Awesome, glad you got it.

You can still use removeSelf. All display.remove does is checks that the object isnt nil before removing it, it is the same as removeSelf in essence. It helps avoid nasty un-meaningful removes however due to the built in check
[import]uid: 84637 topic_id: 20816 reply_id: 81998[/import]

[richard9]

Is that “coming back into existence” bit intended functionality, by the way? Just really surprised me. [import]uid: 41884 topic_id: 20816 reply_id: 82002[/import]

[Danny]

Nope it’s just the way your handling it. [import]uid: 84637 topic_id: 20816 reply_id: 82004[/import]

[richard9]

Er…huh?

I just meant, is it intended that objects are recoverable by setting new data? Or is that a bug I should file about preserved data? [import]uid: 41884 topic_id: 20816 reply_id: 82015[/import]

[Danny]

Sorry, misunderstood

Its by design (lua)

You can remove an object and if you dont set it to nil after, you can re-assign it till your hearts content [import]uid: 84637 topic_id: 20816 reply_id: 82026[/import]

[carlos_m_icaza]

if the object is deleted - any actions to it after deletions will result in erratic behaviour and or hard crash.

c
[import]uid: 24 topic_id: 20816 reply_id: 82040[/import]