Application menu problems and TransformProcessType/SetSystemUIMode

Question

kjbrock OP

Created Sep ’20

Replies 5

Boosts 0

Participants 2

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?

Answered by kjbrock in 632496022

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.

Boost

Answer 1

TyngJJ OP

Sep ’20

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

0

Answer 2

kjbrock OP

Sep ’20

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

0

Answer 3

TyngJJ OP

Sep ’20

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

0

Answer 4

kjbrock OP

Sep ’20

Accepted Answer

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.

0

Answer 5

TyngJJ OP

Sep ’20

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.

0