Application menu problems and TransformProcessType/SetSystemUIMode

Question

I've got an old app that I'm looking at (XIB interface) which calls these functions:

Code Block ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType(&psn, kProcessTransformToForegroundApplication);
SetSystemUIMode(kUIModeNormal, 0);

If I remove these calls, the application menu doesn't show up at all. With these calls in, the menu bar doesn't respond until the app leaves the foreground and then becomes active again.

I created a new XIB-based app and compared the AppDelegate and raw XIB code to what's in the older app, and they look the same, but the newer app's menus work fine without the above calls.

Of what are these calls a legacy, and does anyone know what changes can be made to get rid of them?

macOS

761

Posted by

kjbrock

Reply

Add a Comment

Answer 1

Once upon a time, in the long ago when the app was just coming into being, a plist value was set that told the OS that it was an agent app. It shouldn’t normally be visible, and we didn’t want a dock icon for it.

Eons later, when there were bugs filed about the lack of a dock item, the problem was fixed not by removing that plist value but by adding code that forced a dock icon, and forced the app to the foreground. A side effect of this code was that the menus were not usable until the app went to the background and came back the to foreground.

So basically removing the LSUIElement value and all the extra code above fixed the issue.

I think that whoever added the code was unaware that it was the plist value causing the problem in the first place.

Posted by

kjbrock

Add a Comment

Answer 2

Did you compare your main.m? Are you calling NSApplicationMain() somewhere, or manually performing the equivalent using Carbon?

Posted by

TyngJJ

Add a Comment

Answer 3

main.m is the same also. Calls NSApplicationMain(argc,argv) to kick things off.

Posted by

kjbrock

Add a Comment

Answer 4

In your Info.plist are you using NSPrincipalClass NSApplication, and does your NSMainNibFile refer to an XIB with a Main Menu in it?

Posted by

TyngJJ

Add a Comment

Answer 5

Once upon a time, in the long ago when the app was just coming into being, a plist value was set that told the OS that it was an agent app. It shouldn’t normally be visible, and we didn’t want a dock icon for it.

Eons later, when there were bugs filed about the lack of a dock item, the problem was fixed not by removing that plist value but by adding code that forced a dock icon, and forced the app to the foreground. A side effect of this code was that the menus were not usable until the app went to the background and came back the to foreground.

So basically removing the LSUIElement value and all the extra code above fixed the issue.

I think that whoever added the code was unaware that it was the plist value causing the problem in the first place.

Posted by

kjbrock

Add a Comment

Answer 6

In that case, -[NSApplication setActivationPolicy:] should be the ObjC/Cocoa equivalent to the C/Carbon procedure.
LSUIElement is still a great feature for menu bar apps, though slightly more complicated ones which want things like state restoration need a little more help.

Posted by

TyngJJ

Add a Comment

Application menu problems and TransformProcessType/SetSystemUIMode

Accepted Reply

Replies