I've search high and low but have not found any mention of this issue. When I enter full screen mode (calling enterFullScreenMode on my NSView), my application stops receiving mouse drop events. I can click on a draggable object but I can't drag it to another container. It works fine, except when I'm in "full screen mode".
I'm running in Chromium Embedded Framework, so specifically, I stop receiving OnDragEnter CEF events (https://magpcss.org/ceforum/apidocs3/index.html). Has anyone experienced this kind of behavior? Any ideas on what could be causing it?
After further investigation, it's this command that was disabling drag and drop:
[[(AppDelegate *)[[NSApplication sharedApplication] delegate] window] setLevel:1000000];
Apparently the value 1000000 is invalid, which results in this peculiar side effect.
Related
I'm making a mac app that appears as a popover from the menu bar. The view has several components, when everything is running and the popover is open I see that it is taking up about 3% CPU. However when I minimize the popover and let it run it the background it jumps up to 6-7% CPU. This does not make any sense to me since the view is no longer being shown so I would imagine less would be required to run.
However I am not doing anything when I close the popover, just sending a [popover close] message.
Is there something else I should be doing when I close the popover to keep down CPU usage?
Thanks
Without knowing your code, it is hard to say what's going on. You will need to find that out by using Instruments Time Profiler. Once you know what the application is doing while minimized, you should be able to locate and fix the issue.
I hadn't really seen this as a problem until my client mentioned that the majority of his clicks on buttons on the app I'm developing do nothing. I enquired a little about what exactly he was doing and it turns out that he was clicking (using a mouse, this is a sencha touch app that is embedded inside of a windows application and will ultimately be running on a windows 7 UMPC 'tablet') on a button and releasing BUT the pointer had moved between the click and the release (by a couple of pixels). However this seems to not trigger the tap handler for the button. The only way it works is if you click and release in the exact same spot with no dragging inside of the button at all.
I think thats a little odd - clicking and moving the pointer and then releasing, all while still inside of the button - should trigger the event handler IMO. Clicking, moving and releasing OUTSIDE of the button shouldn't (which it does, as expected).
Anyone else experience this or know of a way to counteract this behaviour?
Thanks
Turns out that this only happens when the app is hosted within WebKit.NET browser control - if I just run it within Chrome the click behaviour is fine - can click and move the mouse and release (while inside the button) and the onTap event fires fine.
I have continued work on an app made by another. It looks in relevant parts identical to the standard NSDocument window-based app that you get when starting a new project (where the Window menu works like normal, ie. the NSDocument appears in the Window menu with the title Untitled).
But in this app, something seems to have happened to the Window menu or the app, that has somehow disconnected this automated behavior from the NSDocument.
Quite substantial work is needed to get this finished, submitted, and later rejected (by reviewers) app into a fresh project.
I'm looking to the experienced Mac app devs for:
What requirements/dependencies need to be fulfilled for the NSDocument to appear in the Window menu as normal?
I have checked MyDocument.h/.m (they are the standard stubs, virtually unchanged), and properties and outlets/delegates in MyDocument.xib, MainMenu.xib (none seem to be missing), and -Info.plist (which is identical to that of a New Project app). I'm experienced with XCode and Cocoa Touch, but not yet with Cocoa.
I'm willing to check things and write test code and give quick feedback, if you would help me over this last hurdle :)
I just had the same problem, and solved it by creating a reference to the window, and showing the window when the nib gets loaded:
- (void)windowControllerDidLoadNib:(NSWindowController *)aController
{
[super windowControllerDidLoadNib:aController];
[window makeKeyAndOrderFront: self];
}
The cause of the problem is still unknown to me. If after trying that it doesn't work, try debugging it. You may discover the real cause, for example the window may have been already deallocated because there isn't any strong reference (not even in NSApp) to it.
Recently i've tried ColorSnapper app, and I've noticed that it works keeping other applications active.
(Check the screen below, as you can see safari window is still active and ColorSnapper keeps being active too).
How can is possible reproduce this effect ?
I believe these types of apps use LSBackgroundOnly or LSUIElement as Launch Services keys in their plist files (reference).
Here's a bit more about it.
I just try it and LSBackgroundOnly is the solution, but you must set the level of the window.
Example :
[mySpecialNSWindow setLevel:NSMainMenuWindowLevel];
This will display the special window above the windows of other applications.
I think the right approach is a mixture of (1) making the app LSBackgroundOnly, (2) using a custom transparent window as described here and set its level to NSFloatingWindowLevel, (3) using something like this in your app delegate to monitor mouse movements though your app is not active and, for example, to let your window follow the mouse position:
[NSEvent addGlobalMonitorForEventsMatchingMask:NSMouseMovedMask handler:^(NSEvent *event) {
[window setFrameOrigin:[NSEvent mouseLocation]];
}];
You can then have views as you like in the (transparent) window, move them around and modify its contents according to the mouse position.
I'm trying to get my NSWindow to:
Be visible on all Spaces
Be visible when showing the Desktop (by pressing F11)
Not be visible in Mission Control/Expose
The following does exactly that, but with a side effect:
[self setCollectionBehavior: NSWindowCollectionBehaviorCanJoinAllSpaces
| NSWindowCollectionBehaviorStationary ];
When switching to the Dashboard on Mac OS X Lion, the window remains visible alone with Dashboard items for a second, then it is hidden.
Is this expected behavior or a bug? Users of my app find it confusing to see the window on the Dashboard before they disappear. I would have expected them to only show on Spaces and not the Dashboard.
I looked at http://cocoadev.com/wiki/DontExposeMe searching for workaround
nothing really worked except.
self.window.level = kCGDesktopWindowLevel;
now maybe DETECT changes to expose and set that then :) ...
see How can one detect Mission Control or Command-Tab switcher superseding one's program in OS X? for that :)
maybe an answer will come up there
I was able to reproduce this behaviour and I think it's just a bit of faulty animation on Apple's side.
Just so I can explain this better, create a new project, add these two lines to applicationDidFinishLaunching:, and run it.
[self.window setCollectionBehavior: NSWindowCollectionBehaviorCanJoinAllSpaces | NSWindowCollectionBehaviorStationary ];
[self.window setHidesOnDeactivate: YES];
(self.window is the window that is created automatically when creating a new project. it doesn't really matter here anyway, just as long as it is a window that appears on the screen)
Now notice this behaviour: when changing from one space where you can see your window to another in which there are other windows from other apps (and so your window is supposed to disappear since your app will be deactivated), your window only disappears when the animation finishes. So, what is happening?
Here's what I think it happens: when switching from one space to another, windows that show on all spaces only react to the change after the animation, hence the brief appearence of your window on the dashboard. I think you'll notice it disappears exactly when the slide animation ends.
So, unfortunately, I don't know how to fix your problem. It just seems to happen this way.