Roku Developer Program

[dev42]

I submitted my first app! It needs a lot more love, but I had to pass this milestone.

So, in order to improve the refactoring / code (re)design, I'm looking for ways for 2 child objects to be able to communicate with each other. On top of that, is there a built in feature where the child can know what the parent knows?

My prior way of solving this was to pass the parent's "m" to the function. ( I don't have my code with me at the moment so my memory is a bit fuzzy. Edit: and I did go with GetGlobalAA() on a few things. ) I'd give this argument the name: "mm" in the function . That way I could access whatever it was I needed.

Well, now I'm considering a different approach. Instead of passing in the parent's "m", why not have an attribute called... wait for it... and I hope you aren't lactose intolerant because it is going to be legen-Dairy... "parent"? *rim-shot*

So, each child will now have a pointer that points to the parent object. Easy peesy.

If there is some sort of inheritance that I've missed or someway to know how to get at data all child object should know about their parent (obj), please let me know!

peace & 42

[TheEndless]

You're not missing anything. There's no built in way to associate two objects. You should note, however, that passing m into your child objects (or vice versa) will cause a circular reference, so depending on how many children you have, it'll likely spit out a big ole' "orphan" number at you when you exit the channel with the Home button.

[EnTerr]

From elsewhere

"dev42" wrote:
... I've passed a reference to the parent object on to what I thought was the child object. In another thread TheEndless pointed out that I may be creating circular references by doing this. Since I don't get any "orphan" message on screen, I'm going to assume I'm not exactly doing this with child "objects" but with 2 & 3 hop "nested" functions.

What @TheEndless said above about circular references is only if you store in the child a pointer to the parent (which naturally has somewhere pointer to that child). Passing a parent reference down a function chain will not create orphans alone, unless reference gets stored in a minion. And even if there is circular reference, it's not the end of the world. To see the warning will have to invalidate all outside links to parent and children first (but keep their incestuous inter-relations) and then get the GC invoked somehow.

[dev42]

I really didn't know where to post this. So, I'm going to create a circular reference and link to the other thread.

Nice bunny, do you need a hug? ( Elf ref ) ... fake Modal Menu with getMessagePort()

I've got a few more Q's in regard to adding / removing objects from the "allObjsToDrawStackList":

• Would it be OK to make allObjsToDrawStackList a global?


• or better to pass it into *all* offspring obj methods?


• and what about the parent object... like appending a sub-menu to the parent menu?

[Rek]

"dev42" wrote:
Would it be OK to make allObjsToDrawStackList a global?

It might be OK, but probably wouldn't be best. It seems like that variable should be confined to some sort of render manager object. Making it a global will just limit you in the future. For example, what if you wanted to support two render systems and swap them out with each other dynamically? Just a thought.

"dev42" wrote:
or better to pass it into *all* offspring obj methods?

I'm not sure what you mean by "pass it into *all* offspring obj methods"... I'm going to assume you meant that in order to have children add themselves to the stack, they must have direct write-access to the stack variable. If that is in fact what you meant, then I would suggest adding a method to the parent which does that (something like "addDrawable"). Then each child need only call 'parent.addDrawable(m)'. If you have multiple levels in the hierarchy, you may want to have each component provide an "addDrawable" function that just calls its parent's "addDrawable". That way, all leaf components can pass their drawables up to the root of the hierarchy without ever having direct access to the stack.

"dev42" wrote:
and what about the parent object... like appending a sub-menu to the parent menu?

Not sure what you're asking here.

[dev42]

"Rek" wrote:

"dev42" wrote:
Would it be OK to make allObjsToDrawStackList a global?

It might be OK, but probably wouldn't be best. It seems like that variable should be confined to some sort of render manager object. Making it a global will just limit you in the future. For example, what if you wanted to support two render systems and swap them out with each other dynamically? Just a thought.

That, dear sir, sounds exquisite, but I wouldn't have the foggiest on how to go about doing such a thing. That said, I've really tried to be too generic with my first app to make future app development "easier". Unfotunately, I've overly complicated areas of this app for that purpose. I'm suspecting this should have been postponed to a later date. :roll: But, if you care to elaborate, I'm sure there are quite a few of us interested in this. 😉
_____________

"Rek" wrote:

"dev42" wrote:
or better to pass it into *all* offspring obj methods?

... I'm going to assume you meant that in order to have children add themselves to the stack, they must have direct write-access to the stack variable. ... I would suggest adding a method to the parent which does that (something like "addDrawable"). Then each child need only call 'parent.addDrawable(m)'. If you have multiple levels in the hierarchy, you may want to have each component provide an "addDrawable" function that just calls its parent's "addDrawable". That way, all leaf components can pass their drawables up to the root of the hierarchy without ever having direct access to the stack.

Yes, that's what I meant. The kicker is still needing to have access to the parent. Every now and then I lose understanding about what "m" stands for. 😉 But it isn't the "parent" it is the current node. So, for example... if the app is inside some arbitrary object's .processEvent() function, I can access all of that obj's attributes / methods, but not the parent, unless I create that link/attribute, correct?
Also, would you just pass the obj's drawable, or the whole object?
_____________

"Rek" wrote:

"dev42" wrote:
and what about the parent object... like appending a sub-menu to the parent menu?

Not sure what you're asking here.

[spoiler=My current mental image of my setup:3il6rxe8]

+- main menu -------+-sub-menu---- ...
|                   +-sub-menu---- ...
|                   +- ...
|
+- game canvas/action stuff ---+-obj01-- ...
|                              +-obj02-- ...
|                              +- ...
|
+- textBox/feedback ----+-textBox01-- ...
                        +-textBox02-- ...

[/spoiler:3il6rxe8]
I'm sure this is all moot, I'd just have an addMenu(), addGameObj() & addTextBox() ... but here we go. In this context, there are 2 types of objects: Those that are already hard coded onto the stack/list and those that will be put there dynamically. In the later case, specifically in relation to sub-menu's, I foresee it as adding it not to the root, but to the parent or parent's parent, but there might be cases where adding to the root is better. It probably is something that is relatively simple and I'm just missing it, like: addMenuToParent() or addMenuToRoot() or something like having the entire menu plotted out and just turn the different sub-menu's visibility / focus flag on/off.

[EnTerr]

"dev42" wrote:
... That said, I've really tried to be too generic with my first app to make future app development "easier". Unfotunately, I've overly complicated areas of this app for that purpose. I'm suspecting this should have been postponed to a later date. :roll:

<nod>
Meet a new friend, her name is YAGNI

[dev42]

"EnTerr" wrote:
Meet a new friend, her name is YAGNI

Oh, YAGNI, I know ye well. Then I forget you exist. Met you again for the first time...

New OOP Vocab Inquiry:

• a DialogBox is something that returns a value, but doesn't have to.


• a Menu is something that does something.

Does that work for y'all?

Now, if I push a Menu onto the stack, I'm OK. The Menu will simply do something and so far "something" hasn't yet required any knowledge of the child Obj that pushed it on the stack in the first place!

But, if I want to go the "DialogBox" route, I can push it onto the stack, which is up the family tree, but when it finishes, how to send the result to the child Obj that needs it? Is this where a "callback" is in order? and/or just have the child Obj as a param? or is this where a more stateful approach is what I'm veering towards?

[Rek]

"dev42" wrote:

"EnTerr" wrote:
Meet a new friend, her name is YAGNI

Oh, YAGNI, I know ye well. Then I forget you exist. Met you again for the first time...

New OOP Vocab Inquiry:

• a DialogBox is something that returns a value, but doesn't have to.


• a Menu is something that does something.

Does that work for y'all?

Now, if I push a Menu onto the stack, I'm OK. The Menu will simply do something and so far "something" hasn't yet required any knowledge of the child Obj that pushed it on the stack in the first place!

But, if I want to go the "DialogBox" route, I can push it onto the stack, which is up the family tree, but when it finishes, how to send the result to the child Obj that needs it? Is this where a "callback" is in order? and/or just have the child Obj as a param? or is this where a more stateful approach is what I'm veering towards?

Callbacks for the win:

dialogBox = dialogBoxCreate("Title", "Message")

' Note: An AA is created and passed to the callback as 'c'. This is so we can 
'          access the correct 'm' pointer using 'c.this'
dialogBox.setOnAffirmativeAction({ this: m }, function(c, result as Integer) as Void
   c.this._dialogConfirmed(result)
end function)

dialogBox.setOnNegativeAction({ this: m }, function(c) as Void
   c.this._dialogCanceled()
end function)