tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/4093-prevent-context-to-be-destroyed-when-adding-it-to-another-stageRobotlegs: Discussion 2018-10-18T16:35:50Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T15:28:38Z2013-07-22T15:28:38ZPrevent context to be destroyed when adding it to another stage<div><p>Hi Jeff,</p>
<blockquote>
<p>All fine, but now I'd like to switch the modules between native
windows, meaning I want to add modules to another window's stage
then their initial one. Therefore I'd need to call
someWindow.stage.addChild(someModule). But this removes the module
from its initial stage and thus its mediator is being destroyed -
and I guess the entire context? End of party.</p>
</blockquote>
<p>Yep, end of party, because a context is destroyed the moment its
contextView leaves the stage.<br>
If I understand correctly, you're trying to add the same instance
of someModule to another window. So, window1 has someModule added
to its stage, and then you try to add it to window 2, right? That's
'reparenting', i.e. flash will remove the first instance of
someModule from window1 (first parent) before adding a new instance
of someModule to window 2 (second parent). Even if you could keep
the context of the first instance alive, the second instance will
create its own context.<br>
May I ask why you need to re-parent the module or rather why you
need to keep the context alive? Maybe there is another solution to
your use case where you can avoid re-parenting.<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T15:45:14Z2013-07-22T15:45:14ZPrevent context to be destroyed when adding it to another stage<div><p>hi Ondina,</p>
<p>I dropped the idea of reparenting, it's not going to work.</p>
<p>I'm still working on this modular two-windows app, where native
window One contains the 'leading' master module/context/game and
native window Two a 'following' slave module/context/game, which is
just listening and showing part of the master game. I did this by
using two contexts where the master module dispatches modular
events and the slave module listens for them. That works great. But
now I'd like to 'switch views', i.e. every now and then show the
master game in window Two and the slave game in window One.</p>
<p>I tried just moving the windows, but that's very noticeable,
because they need to be fullscreen and, well, that process is
noticeable, not what I want.</p>
<p>I also tried creating two instances of one Module and assigning
master and slave roles to them. But I cannot relay and receive
modular events as they are instances from the same Module which
results in infinite loops when I dispatch an event like that. I'm
not sure why, because looping even happens when the event is not
being listened for at all, just dispatched.</p>
<p>Now I'm thinking of two different modules with both their own
ModuleConnectorConfig, so i can at least send modular events back
and forth, but I feel that both modules should be able to be slave
and master and behave like that when roles are assigned.</p>
<p>I am pretty sure I'm overcomplicating things, any basic ideas
are very welcome,</p>
<p>thanks,<br>
Jeff.</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T15:59:47Z2013-07-22T15:59:47ZPrevent context to be destroyed when adding it to another stage<div><blockquote>
<p>I am pretty sure I'm overcomplicating things, any basic ideas
are very welcome,</p>
</blockquote>
<p>No, no, you're not. That's a thing the ModuleConnector is
missing at the moment.</p>
<p>see a temporary solution to the infinite loop:<br>
<a href=
"http://knowledge.robotlegs.org/discussions/robotlegs-2/3327-go-modular-for-multiple-games#comment_27433210">
http://knowledge.robotlegs.org/discussions/robotlegs-2/3327-go-modu...</a></p>
<p>Anyway, I'll think about your use case...<br>
Is this a test project that you can share? If so, maybe seeing it
in action will help me find a (better) solution (???)</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:03:06Z2013-07-22T16:03:06ZPrevent context to be destroyed when adding it to another stage<div><p>Funny, I was just reading that solution - which you discussed in
a thread I started myself ;)</p>
<p>It is not a test project, I'm working in the real one, which I'm
afraid I cannot share.<br>
Will look at the infinite loop thing first.</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:03:59Z2013-07-22T16:03:59ZPrevent context to be destroyed when adding it to another stage<div><p>okay:)</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:13:48Z2013-07-22T16:13:48ZPrevent context to be destroyed when adding it to another stage<div><p>Just a random thought:</p>
<p>Add an instance of someModule to window1 and another instance of
somemodule to window2. someModule should have a "switchable
behaviour", i.e. act as a master or as a slave. When you decide
(event triggered somehow) someModule should be a master it would
use a MasterModuleConnectorConfig and as a slave it would use a
SlaveModuleConnectorConfig, each with the appropriate channels and
events.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:13:59Z2013-07-22T16:13:59ZPrevent context to be destroyed when adding it to another stage<div><p>Cool, that also takes away my infinite loop, I'll first try to
continue based on that and will let you know if my question is
still valid!</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:16:02Z2013-07-22T16:16:02ZPrevent context to be destroyed when adding it to another stage<div><p>hm, I see. Yes, i was wondering how flexible these
ModuleConnectorConfigs are. Can I change from ModuleConnectorConfig
during a context's lifecycle? And how would that look?</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-22T16:28:45Z2013-07-22T16:28:45ZPrevent context to be destroyed when adding it to another stage<div><p>You'd add an event listener for a custom event inside your
SomeModuleContext or where you have access to your context, and in
the hadnler you do</p>
<p>context.configure(SlaveModuleConnectorConfig)<br>
or<br>
context.configure(MasterModuleConnectorConfig)</p>
<p>I haven't tried it yet, but it should work, I think.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/278896792013-07-23T19:56:12Z2013-07-23T19:56:12ZPrevent context to be destroyed when adding it to another stage<div><p>I'm gonna close this topic for now, thanks!</p></div>JeffW.