maybe its only me picking up on this but you could probably work a little on both how you initially described your question, as well as how you adress people trying to help.
Took a while just to understand what you were after, and it seems I wasnt the only one.
Anyway, hope you figure it out mate.
Anawim
@carloscosta - Cool. I guess I assumed composer.* because of the word ‘scene’ being used. My bad. I guess it’s at least partly right what they say about assuming. 
(I’m talking about me here…)
display groups would solve the problem… but only if you could “know” something about how “others” are using them (in particular, how any scene manager is doing its job, whether composer or something else) so that you could counter any negative side-effects of the “other’s” use.
there is no built-in group that is permanently above all other groups – in fact there’s only one built-in stage group, so it obviously can’t be above itself! (although any native object will always display above the opengl canvas, so Enterprise could do what you want)
for example, if you “knew” it was to be used with composer, then simply create your group outside of composer *after* composer has been required (at which time it creates it’s own group to house all scene groups). then your group should forever remain above anything/everything that composer does in its own group.
otoh if instead you “knew” it was to be used with DIY “scenes” that the end-user is creating as groups at the stage group level, then you could (probably) monkey-patch display.getCurrentStage().insert so as to preserve your group’s ordering within it. (and/or monkey-patch display.newGroup, etc)
in short, if you cannot “know” anything about the “environment” you’ll be running in, then there might not be any “better” solution than your current approach of just forcing your group to the front on a runtime event.
my question was really simple: “is there an easy way to force an object to be on top of every other object, even if others objects are created after?”
i think my fault was giving some background info about what was i doing so everyone started from there and sugesting things i already knew
for that, I apologize to everyone who I may missleaded.
Regards,
Carlos
@carloscosta - I’ll PM this to you in case you’re not continuing to read this thread, but I’m posting it here because I hope to be at least a little helpful to you and others.
In your post above I noticed you said something about hating Runtimes.
I’m guessing this may be because it is easy to get crashes with Runtimes like ‘enterFrame’ and/or custom Runtime event listeners.
For example, this code using a table listener would crash:
local obj = display.newCircle( 100, 100, 100 ) obj.enterFrame = function( self ) self.x = self.x + 10 end Runtime:addEventListener( "enterFrame", obj ) timer.performWithDelay( 1000, function() display.remove(obj) ) end)
To prevent a crash you can do this:
local obj = display.newCircle( 100, 100, 100 ) obj.enterFrame = function( self ) self.x = self.x + 10 end Runtime:addEventListener( "enterFrame", obj ) function obj.finalize( self ) Runtime:removeEventListener( "enterFrame", self ) end obj:addEventListener( "finalize" ) timer.performWithDelay( 1000, function() display.remove(obj) ) end)
PS - I’m always mentioning SSK2 (now free), but in this case it has a handy feature for safely cleaning up Runtime listeners.
The safe code above would look like this in SSK2:
local obj = display.newCircle( 100, 100, 100 ) obj.enterFrame = function( self ) self.x = self.x + 10 end listen( "enterFrame", obj ) function obj.finalize( self ) ignoreList( { "enterFrame" } , self ) -- add more event names to table to safely remove them. end obj:addEventListener( "finalize" ) timer.performWithDelay( 1000, function() display.remove(obj) ) end)
this works as well
local obj = display.newCircle( 100, 100, 100 ) obj.enterFrame = function( self ) if type( self.removeSelf ) == "function" then self.x = self.x + 10 else Runtime:removeEventListener( "enterFrame", obj ) end end Runtime:addEventListener( "enterFrame", obj ) timer.performWithDelay( 1000, function() display.remove(obj) end)Hi sphere, i hate runtimes, because they are always working 30/60 times a second (depending on your config) running, slowing down the app (even if we don’t notice…i do) and consuming battery…that the only reason never had a problem with crashes, i always remove then before trying to remove anything inside it.
saying that, your last code is very cool way to remove the runtime. thank you, for sharing your knowledge, i learned something from it. i would never by myself remember to compare the self.removeSelf to check if it exists.