MacOSX Menubar

Hi,

I am using MacOSXExtra in 7.9.1 to replace the OSX Menubar with a menu that goes with my application.

So I modified the Xcode MainMenu.nib within the visual.app contents with my own menu.

In my MacOSXSystemSupport class method enableMenuBarItems a typically have a line with:

 self primActivateMenuItem: 2 state: true. "VisualWorks->Preferences"

 self primActivateMenuItem: 62 state: true. "Open existing file"

In my InputState class method setMenuDispatchTable I have notably the following:

        MacOSXMenuDispatch at: 2 put: #visualWorksSettings:eventMenu:.

MacOSXMenuDispatch at: 62 put: #openExistingFile:eventMenu:.

In InputState instance methods on the protocol private macosx dispatching I find for opening the settings tool:

visualWorksSettings: window eventMenu: event

"Open the VisualWorks SettingsTool."

[Tools.VisualWorksSettings openManager] forkAt: 50

Forking from OSX on the class side is not really what interests me,  what I want to do is have direct access to my running application window.

As the window is given through the parameter I can do this

openExistingFile: window eventMenu: event

window application class = MainProject

ifTrue: [window application connectToExistingFile]

This however freezes the VM with an undebugable exception, 

only adding the fork will have thing go through but not the way that I want them and all the examples use this method.

 So the question is if there is another way to send message my running application without forking it ?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks Michel,

The thing is that I am out of my comfort zone here, I am getting a scheduled window but I need a CCompositePointer so for as far I can see it I need I still need some glue to get the CCompositePointer from the window

openNewFile: window eventMenu: event

window application class = MainProject

ifTrue: 

[ObjectiveCRuntime object: window getScheduledWindowCCompositePoint  performOnMainThread: #reconnectToNewFile]

Regards,

@+Maarten,

Le 17 mai 2014 à 02:00, Michael Lucas-Smith <[hidden email]> a écrit :

Any Cocoa calls must be performed on the main thread. Try using performSelectorOnMainThread and the other variations of this method.

Cheers,

Michael

On 17 May 2014 08:04, Maarten Mostert <[hidden email]> wrote:

Hi,

I am using MacOSXExtra in 7.9.1 to replace the OSX Menubar with a menu that goes with my application.

So I modified the Xcode MainMenu.nib within the visual.app contents with my own menu.

In my MacOSXSystemSupport class method enableMenuBarItems a typically have a line with:

 self primActivateMenuItem: 2 state: true. "VisualWorks->Preferences"

 self primActivateMenuItem: 62 state: true. "Open existing file"

In my InputState class method setMenuDispatchTable I have notably the following:

        MacOSXMenuDispatch at: 2 put: #visualWorksSettings:eventMenu:.

MacOSXMenuDispatch at: 62 put: #openExistingFile:eventMenu:.

In InputState instance methods on the protocol private macosx dispatching I find for opening the settings tool:

visualWorksSettings: window eventMenu: event

"Open the VisualWorks SettingsTool."

[Tools.VisualWorksSettings openManager] forkAt: 50

Forking from OSX on the class side is not really what interests me,  what I want to do is have direct access to my running application window.

As the window is given through the parameter I can do this

openExistingFile: window eventMenu: event

window application class = MainProject

ifTrue: [window application connectToExistingFile]

This however freezes the VM with an undebugable exception, 

only adding the fork will have thing go through but not the way that I want them and all the examples use this method.

 So the question is if there is another way to send message my running application without forking it ?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc