Prevent context to be destroyed when adding it to another stage
hello!
I'm running into a nasty problem, and maybe someone has a brilliant idea to save me :)
I'm working on a pure as3 air project with multiple modules
(i.e. contexts). Each module is initially added to its own native
window.
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.
I'm looking for ideas how I can somehow keep the context and still add it to another window's stage. Maybe by keeping a reference to it (sounds bad if possible) or maybe the view manager can help me out?
I know, bit of a vague problem, but any ideas are welcome.
thanks,
Jeff.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Ondina D.F. on 22 Jul, 2013 03:28 PM
Hi Jeff,
Yep, end of party, because a context is destroyed the moment its contextView leaves the stage.
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.
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.
Ondina
2 Posted by JeffW. on 22 Jul, 2013 03:45 PM
hi Ondina,
I dropped the idea of reparenting, it's not going to work.
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.
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.
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.
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.
I am pretty sure I'm overcomplicating things, any basic ideas are very welcome,
thanks,
Jeff.
Support Staff 3 Posted by Ondina D.F. on 22 Jul, 2013 03:59 PM
No, no, you're not. That's a thing the ModuleConnector is missing at the moment.
see a temporary solution to the infinite loop:
http://knowledge.robotlegs.org/discussions/robotlegs-2/3327-go-modu...
Anyway, I'll think about your use case...
Is this a test project that you can share? If so, maybe seeing it in action will help me find a (better) solution (???)
4 Posted by JeffW. on 22 Jul, 2013 04:03 PM
Funny, I was just reading that solution - which you discussed in a thread I started myself ;)
It is not a test project, I'm working in the real one, which I'm afraid I cannot share.
Will look at the infinite loop thing first.
Support Staff 5 Posted by Ondina D.F. on 22 Jul, 2013 04:03 PM
okay:)
Support Staff 6 Posted by Ondina D.F. on 22 Jul, 2013 04:13 PM
Just a random thought:
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.
7 Posted by JeffW. on 22 Jul, 2013 04:13 PM
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!
8 Posted by JeffW. on 22 Jul, 2013 04:16 PM
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?
Support Staff 9 Posted by Ondina D.F. on 22 Jul, 2013 04:28 PM
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
context.configure(SlaveModuleConnectorConfig)
or
context.configure(MasterModuleConnectorConfig)
I haven't tried it yet, but it should work, I think.
10 Posted by JeffW. on 23 Jul, 2013 07:56 PM
I'm gonna close this topic for now, thanks!
JeffW. closed this discussion on 23 Jul, 2013 07:56 PM.