Fournier Eric
2006-05-01 18:39:30 UTC
I've subclassed CProjectBuilder to allow me to take over the Tweak
menu bar, and auto-start my email application (Hermes), and have
subclassed CTweakProjectInMorphic and CProjectMorph classes to allow
mostly my replacement of the CProjectBuilder with my subclass
UMnMultiAppEnviron.
I run my Hermes emailer in the default EToysProject/EToysWorld
instances. I discovered recently that the Hermes windows, when
expanded (maximized) expanded to cover the world menu bar. Suspecting
I needed to get my windows within the EToysWorld instance extents, I
changed my window openers to be more like:
UMnMultiAppEnviron>>showInitialStuff
"Redefines CProjectBuilder's: A hack spot to auto-start"
aWorld := projectShell projectWorld.
HermesApp openIn: aWorld at: .....
I can open additional windows:
HermesApp>>openBrowserWindow
aWindow openIn: (self world) at: .....
Now the window controls seem to keep the windows in the extent of
EToysWorld, but I noticed that the window closed operation fails to
bring the next window in the stack (or the last window open) forward,
and this is a problem since my menu controls need to bind to a front
window.
Tracing my way in, I discovered that CProject2>>onTopWindowClosed at
list := CWindowManager default windowsIn: world satisfying:[:w| w
isCollapsed not].
...reports that world is UMnMultiAppEnviron NOT EToysWorld. It seems
the windows OPEN in the correct world (by inspection), but
EToysProject has not properly updated its world attribute, so it
looks in a empty element list in UMnMultiAppEnviron. I suspect I
disabled some project entry code somewhere, but my redefining of
methods has been very limited.
Can anybody point me in the right direction here?
-- Eric
menu bar, and auto-start my email application (Hermes), and have
subclassed CTweakProjectInMorphic and CProjectMorph classes to allow
mostly my replacement of the CProjectBuilder with my subclass
UMnMultiAppEnviron.
I run my Hermes emailer in the default EToysProject/EToysWorld
instances. I discovered recently that the Hermes windows, when
expanded (maximized) expanded to cover the world menu bar. Suspecting
I needed to get my windows within the EToysWorld instance extents, I
changed my window openers to be more like:
UMnMultiAppEnviron>>showInitialStuff
"Redefines CProjectBuilder's: A hack spot to auto-start"
aWorld := projectShell projectWorld.
HermesApp openIn: aWorld at: .....
I can open additional windows:
HermesApp>>openBrowserWindow
aWindow openIn: (self world) at: .....
Now the window controls seem to keep the windows in the extent of
EToysWorld, but I noticed that the window closed operation fails to
bring the next window in the stack (or the last window open) forward,
and this is a problem since my menu controls need to bind to a front
window.
Tracing my way in, I discovered that CProject2>>onTopWindowClosed at
list := CWindowManager default windowsIn: world satisfying:[:w| w
isCollapsed not].
...reports that world is UMnMultiAppEnviron NOT EToysWorld. It seems
the windows OPEN in the correct world (by inspection), but
EToysProject has not properly updated its world attribute, so it
looks in a empty element list in UMnMultiAppEnviron. I suspect I
disabled some project entry code somewhere, but my redefining of
methods has been very limited.
Can anybody point me in the right direction here?
-- Eric