I have an application with LSUIElement set to 1. It has a built-in editor, so I want the application to appear in Cmd+Tab cycle when the editor is open.
-(void)stepIntoForeground
{
if (NSAppKitVersionNumber < NSAppKitVersionNumber10_7) return;
if (counter == 0) {
ProcessSerialNumber psn = {0, kCurrentProcess};
OSStatus osstatus = TransformProcessType(&psn, kProcessTransformToForegroundApplication);
if (osstatus == 0) {
++counter;
} else {
//...
}
}
}
-(void)stepIntoBackground
{
if (NSAppKitVersionNumber < NSAppKitVersionNumber10_7) return;
if (counter == 0) return;
if (counter == 1) {
ProcessSerialNumber psn = {0, kCurrentProcess};
OSStatus osstatus = TransformProcessType(&psn, kProcessTransformToUIElementApplication);
if (osstatus == 0) {
--counter;
} else {
//..
}
}
}
The problems are:
there's also a Dock icon (not a big deal);
there's also Menu, that is not a big deal too, but they appear not always.
Is there any way to disable menu at all or to make it appear always in foreground? Thanks in advance.
This is how we do it.
(Works 10.7+)
DO NOT USE LSBackgroundOnly NOR LSUIElement in the app plist
Add and init your menu and NSStatusBar menu
After app initialized but not yet shown any window take a place where you might want to show the first window if any. We use applicationDidFinishLaunching.
If you do not want to show any window yet after app initialized use
[NSApp setActivationPolicy:NSApplicationActivationPolicyProhibited];
on 10.9 you can use at last the otherwise much correct
[NSApp setActivationPolicy:NSApplicationActivationPolicyAccessory];
If you should open any window after app init finished than simply show the main window
Maintain your list of windows
If last window closed, call
[NSApp setActivationPolicy:NSApplicationActivationPolicyProhibited];
on 10.9 you can use at last the otherwise much correct
[NSApp setActivationPolicy:NSApplicationActivationPolicyAccessory];
When your first window shown next time, call
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
[NSApp activateIgnoringOtherApps:YES];
[[self window] makeKeyAndOrderFront:nil];
This should do the trick, if at least one app window is visible you will have menu, dock icon with state signaled, and cmd+tab element with your app, if last app window closed only your NSStatusBar element stays.
Known issues:
The first step is important because without that if a system modal dialog suspends your startup (f.e. your app is downloaded from the net and become quarantined a confirmation dialog might appear at first startup depending on your security settings) your menubar might not be owned by your app after your first app window shown.
Workaround: Starting as normal app (step 1.) would solve this problem, but will cause another small one, your app icon might appear for a moment in the dock at startup even if you would like to startup without any window shown. (but we can deal with this, not owning the menubar was a bigger problem for us, so we chose this instead)
Changing between NSApplicationActivationPolicyRegular and NSApplicationActivationPolicyAccessory (or NSApplicationActivationPolicyProhibited on OSes bellow 10.9) will kill your tooltip of status bar menu element, the tooltip will be shown initially but will not ever after the second call of NSApplicationActivationPolicyAccessory -> NSApplicationActivationPolicyProhibited
Workaround: We could not find a working workaround for this and reported to Apple as a bug.
Changing from NSApplicationActivationPolicyRegular to NSApplicationActivationPolicyAccessory has other problems on some OS versions like there might be no more mouse events in visible app windows sometimes
Workaround: switch first to NSApplicationActivationPolicyProhibited (take care this leads to unwanted app messages, like NSApplicationWillResignActiveNotification, NSWindowDidResignMainNotification, etc. !)
Changing from NSApplicationActivationPolicyAccessory to NSApplicationActivationPolicyRegular is bogus as on some OS versions
the app main menu is frozen till the first app front status change
the app activated after this policy not always get placed front in the application order
Workaround: switch first to NSApplicationActivationPolicyProhibited, take care the final switch to the desired NSApplicationActivationPolicyRegular should be made delayed, use f.e. dispatch_async or similar
With swift 4, in applicationDidfinishLaunching(_:Notification)
NSApplication.shared.setActivationPolicy(.regular)
did the trick for me, but I was only trying to get keyboard focus to my programmatically created window. Thanks.
You can set App "Application is agent (UIElement)" to YES in your plist file.
EDIT:
I think there are some hacks to do this.
But it's really not the way it's meant to be.
Cmd+tab is for getting an application to foreground, but if you don't have a menu bar, it doesn't look like foreground to the user.
I'd rather make a menu bar to access the app.
Related
You know how sometimes when you close a Finder window or document, it shrinks toward its representation in Finder. I want my application to be able to do this, too. Is there an API for this? I can't find any.
Executive summary: Use the NSDocument system if you want this behavior.
Details:
It looks like you're using TextEdit in your GIF. As it happens, Apple publishes the source code for TextEdit as sample code. So we can look and see if it does anything special to make this happen.
I couldn't find anything in the TextEdit source code. I poked around for a while and set some breakpoints but didn't find any evidence that TextEdit does this “manually”.
I discovered that if you open the file using File > Open (instead of double-clicking the file in the Finder), you do not get the animated closing window, even if the file is visible in the Finder.
But if you open the file using File > Open, then (without closing that window) double-click the file in the Finder, then you do get the animated closing window.
So I poked around a bit more, setting breakpoints and looking at disassembler listings, and I found what I think is the important bits, in -[NSWindow _close]. It goes basically like this:
- (void)_close {
if (!_wFlags.windowDying) { return };
if (_auxiliaryStorage->_auxWFlags.windowClosed) { return; }
void (^actuallyCloseMyself)() = ^{ ... code to actually close the window ... };
NSWindowController *controller = self.windowController;
if (![controller respondsToSelector:#selector(document)]) { goto noCloser; }
NSDocument *document = controller.document;
if (![document respondsToSelector:#selector(fileURL)]) { goto noCloser; }
QLSeamlessDocumentCloser *closer = [[NSDocumentController _seamlessDocumentCloserClass] seamlessDocumentCloserForURL:document.fileURL];
if (closer == nil) { goto noCloser; }
CGRect frame = NSRectZero;
[closer closeWindow:self contentFrame:&frame withBlock:actuallyCloseMyself];
goto done;
noCloser:
actuallyCloseMyself();
done:
_auxiliaryStorage->_auxWFlags.wantsHideOnDeactivate = YES;
}
So basically, if your window is attached to an NSWindowController, and the controller has an NSDocument, then AppKit will try to set up a “seamless close” using a QLSeamlessDocumentCloser. The QL prefix means it's part of QuickLook (the class is in fact found in the QuickLookUI framework, which is part of the Quartz framework).
I guess what happens is, when you open a file in the Finder, the Finder tells the QuickLook system (probably the quicklookd process) where on the screen it is displaying the icon for the file. When the closer is called (in TextEdit), if QuickLook has a frame to close to, it animates the window down to that frame before actually closing the window. If you didn't open the file via the Finder, QuickLook doesn't have a frame to animate to, so it presumably just calls the actuallyCloseMyself block immediately.
How can I bring a window to the top if not there, and close it otherwise, when the tray icon is clicked, using the Windows API? That is, very similar to what the taskbar icon does. By bring to the top I mean fully visible to the user.
I cannot find a way to tell whether the window is on top or not, because when the tray icon is clicked, the taskbar is always on top. I tried inspecting the Z-order of the windows but it looks inconsistent. For example, when the application window is on top and tray icon is clicked, I would expect a constant number of taskbar/tray windows to be brought to top, and the window immediately following them being the one that was on top. But that's not the case, it seems.
I could mostly implement it, the problem is that the toggle doesn't care whether the window is open and fully visible to the user (on top). When the tray icon is clicked and the window is currently closed, it is opened and brought to top correctly. When the window is open and on top, it is also closed correctly. However, when the window is open but not on top, it will be closed instead of being brought to foreground.
To expand upon what Hans Passant said:
"On top" is not important, since some windows can be always on top; it's whether the window is the foreground window or not that you're concerned with.
Use GetForegroundWindow() to see if your window is the foreground window and if not, SetForegroundWindow() to make it so.
Thanks to Mike Gelfand who solved the problem! The following function will return:
-1 when window is closed
0 when window is fully visible
1 or above when window is open but not fully visible
int GetMyWindowLevel(HWND myWindow) {
WINDOWINFO myWindowInfo;
myWindowInfo.cbSize = sizeof(myWindowInfo);
if (!GetWindowInfo(myWindow, &myWindowInfo))
return -1;
int myWindowLevel = -1;
HWND currentWindow = GetTopWindow(NULL);
for (; currentWindow != NULL;
currentWindow = GetNextWindow(currentWindow, GW_HWNDNEXT)) {
WINDOWINFO currentWindowInfo;
currentWindowInfo.cbSize = sizeof(currentWindowInfo);
if (!GetWindowInfo(currentWindow, ¤tWindowInfo))
continue;
if ((currentWindowInfo.dwExStyle & WS_EX_TOPMOST) !=
(myWindowInfo.dwExStyle & WS_EX_TOPMOST) ||
(currentWindowInfo.dwStyle & WS_POPUP) != 0)
continue;
++myWindowLevel;
if (currentWindow == myWindow)
break;
}
return currentWindow == myWindow ? myWindowLevel : -1;
}
I have an MFC application. In my application if I run on Windows XP it's working fine. But if I run in Windows Vista the MFC dialog hides behind the taskbar.
bool bHide=true;
CRect rectWorkArea = CRect(0,0,0,0);
CRect rectTaskBar = CRect(0,0,0,0);
CWnd* pWnd = CWnd::FindWindow("Shell_TrayWnd", "");
pWnd->ShowWindow(SW_SHOW);
if( bHide )
{ // Code to Hide the System Task Bar
SystemParametersInfo(SPI_GETWORKAREA,0,(LPVOID)&rectWorkArea,0);
if( pWnd )
{
pWnd->GetWindowRect(rectTaskBar);
// rectWorkArea.bottom -= rectTaskBar.Height();
rectWorkArea.bottom += rectTaskBar.Height();//-----to hide taskbar
SystemParametersInfo(SPI_SETWORKAREA,0,(LPVOID)&rectWorkArea,0);
// pWnd->ShowWindow(SW_SHOW);
pWnd->ShowWindow(SW_HIDE); //--to hide taskbar
}
}
I used this code but it hides the taskbar. But I want to show the application above the task bar.
You don't own the taskbar, so you are not supposed to hide it. You have the option to auto-minimize it by the way. You have another option of using secondary monitor without taskbar there.
On the primary monitor your app is given work area, you are being able to locate (judging from the code snippet provided above). It is the best to position your window within this area without interfering with the taskbar, whether it is above or beyond.
If you still feel like making it more like a competition "who is on top" with the task bar, you might want to take a look at SetWindowPos API and window Z-Order.
finally i found the solution , what we want to do is we should add the below code in our oninitdialog,
SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
the above line is enough to show the mfc dialog on above the taskbar . but sometimes the focus of the dialog get changed looks hanged(no response in dialog) the application.if it occurs put the below code.
SetWindowPos(&this->wndBottom,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
I'm trying to use CGAssociateMouseAndMouseCursorPosition(NO) in a program. This disconnects the mouse from the on screen cursor when your application is "in the foreground". Unfortunately it also disconnects it when Mission Control or the application switcher or who knows what else comes up.
So far I know:
The application is still active.
The window is still key.
Nothing is sent to the default notification center when these things come up.
The application stops receiving mouse moved events, but an NSEvent addGlobalMonitorForEventsMatchingMask:handler: also does not receive them, which is strange to say the least. It should receive any events not delivered to my application. (I was planning to detect the missing events to know when to associate the mouse again.
So, is there a way to detect when my application is no longer in control, specifically because Mission Control or the switch has taken over? They really expect the mouse to work and I need to restore that association for them.
I share your surprise that a global event monitor isn't seeing the events. In a similar situation, I used a Quartz Event Tap for a similar purpose. The Cocoa global event monitor is quite similar to event taps, so I figured it would work.
I put the tap on kCGAnnotatedSessionEventTap and compared the result from CGEventGetIntegerValueField(event, kCGEventTargetUnixProcessID) to getpid() to determine when the events were going to another app (e.g. Mission Control or Exposé). (I disable the tab when my app resigns active status, so it should only receive events destined for another app when this sort of overlay UI is presented.)
By the way, you mentioned monitoring the default notification center, but, if there's a notification about Mission Control or the like, it's more likely to come to the distributed notification center (NSDistributedNotificationCenter). So, it's worth checking that.
I needed to check for mission control being active and ended up with an approach along the lines of Ken's answer.
Sharing is caring so here is the smallest sensible complete code that worked for me: (Swift 5)
import Foundation
import AppKit
let dockPid = NSRunningApplication.runningApplications(withBundleIdentifier: "com.apple.dock").first?.processIdentifier
var eventTargetPid: Int32?
let eventTap = CGEvent.tapCreate(
tap: .cgAnnotatedSessionEventTap,
place: .headInsertEventTap,
options: .listenOnly,
eventsOfInterest: CGEventMask(
(1 << CGEventType.mouseMoved.rawValue)
| (1 << CGEventType.keyDown.rawValue)
),
callback: { (tapProxy, type, event, _:UnsafeMutableRawPointer?) -> Unmanaged<CGEvent>? in
// Now, each time the mouse moves this var will receive the event's target pid
eventTargetPid = Int32(event.getIntegerValueField(.eventTargetUnixProcessID))
return nil
},
userInfo: nil
)!
// Add the event tap to our runloop
CFRunLoopAddSource(
CFRunLoopGetCurrent(),
CFMachPortCreateRunLoopSource(kCFAllocatorDefault, eventTap, 0),
.commonModes
)
let periodSeconds = 1.0
// Add a timer for periodic checking
CFRunLoopAddTimer(CFRunLoopGetCurrent(), CFRunLoopTimerCreateWithHandler(
kCFAllocatorDefault,
CFAbsoluteTimeGetCurrent() + periodSeconds, periodSeconds, 0, 0,
{ timer in
guard eventTargetPid != dockPid else {
print("Dock")
return
}
print("Not dock")
// Do things. This code will not run if the dock is getting events, which seems to always be the case if mission control or command switcher are active
}), .commonModes)
CFRunLoopRun()
This simply checks whether the dock was the one to receive the last event of interest (here that includes mouse movement and key-downs).
It covers most cases, but will report the wrong value between the command switcher or mission-control hiding and the first event being sent to a non-dock app. This is fine in my use-case but could be an issue for other ones.
Also, of course, when the dock at the bottom is active, this will detect that too.
Have you tried asking NSRunningApplication?
my dock menu always be added "Quit" and other 2 menu items automatically, how may I block / modify them?
updated:
really NO way to delete/block/redirect the "Quit" menu item.
used Peter's recommendation at last like blow
hope helpful to others
-(NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication *)sender
{
if (needPassword)
{
[self checkPassword:self];
return NSTerminateCancel;
}
else
{
return NSTerminateNow;
}
}
-(void)checkPassword:(id)sender
{
if(passwordCorrect)
{
!needPassword;
[[NSApplication sharedApplication] terminate:self];
}
}
Trying to intercept all possible ways the user might tell your application to quit is bound to fail. (Did you remember the Quit Apple Event?)
It'll be both easier and more effective to just implement the applicationShouldTerminate: method in your application's delegate. Put up the password panel and return NSTerminateLater. Then, when the user either enters the correct password or cancels, send the application a replyToApplicationShouldTerminate: message.
Whichever Quit commands (menu items, etc.) you've already ripped out, put them back. Let the user invoke the normal Quit command in the normal way; that will trigger the aforementioned should-terminate procedure to determine whether the quit will actually happen.
1)Open the MainMenu.xib
2)Create your own dock menu
3)Right click on the File's Owner (NSApplication instance)
4)Connect the property "dockMenu" with your custom menu
If you want to do that because of learning purposes it's fine. However, when you want to sell this application you should reconsider this. Users expect your app to have a quit button in the dock menu.