Within my Cocoa app, I call NSWorkspace's openFile: method to open some file with its default application.
Sometimes this works just fine, and the other application gets focus, as it should.
But alas, sometimes (the occurrence of which seems to be totally random), after the focus goes briefly to the other application, it goes quickly back to my Cocoa app. This is unwanted.
Any ideas what the causes could be?
Note: I have also tried the openFile:withApplication:andDeactivate:, passing YES to the last argument. This doesn't work either. The strange random occurrences of focus going back to my Cocoa app persist.
I'm unable to reproduce this now. Not sure what the problem was.
Related
I am making a vim-style "window manager" that takes text input, much like Alfred or Spotlight in Mavericks (in a floating panel).
The problem I'm having is when I call activateWithOptions: on a running application it steals focus from my window. I was hoping the problem would be solved by simply bring my app to the foreground again, however it seems the activation is running on a separate thread, and I end up activating my app before the original app gets activated.
I have tried reactivating when I receive NSWorkspaceDidActivateApplicationNotification, but that doesn't work either.
Ideally I'd like to pause execution until the application is focused for multiple reasons, since that would be the window I manipulate further.
Does anyone have any suggestions?
I have a sandboxed Cocoa app. I noticed that when I call [[NSWorkspace sharedWorkspace] selectFile:path inFileViewerRootedAtPath:path] no Finder window opens the first time is called. Finder.app is brought to the foreground (menu bar changes to Finder), but otherwise nothing happens.
When I bring my app back to the front and again have it select a file in Finder, the Finder window opens with the file selected as expected. I tried this with #"" as second argument, same thing.
When a Finder window is open already, everything works as expected.
Has anybody else seen this problem? Workaround is to immediately call selectFile:... twice, but that doesn't seem right.
Edit: not related to sandboxing. Same issue without sandbox.
I think activateFileViewerSelectingURLs is better. It correctly selects multiple files in the finder.
I am implementing a text service on windows. Things work fine. However when I shift window focus to another application and shift focus back to the original application, the selected text services gets de-activated (I notice a call to ITfTextInputProcessor::Deactivate). I think this call is unexpected. Post this call, The service has to be re-activated manually. I am surely doing something goofy. Just that I don't know what it is.
Offhand, I'd say that you are indeed doing something goofy. :) In particular, I'd pay careful attention to your ITfThreadMgrEventSink::OnSetFocus implementation (and, obviously, you need to implement ITfThreadMgrEventSink in your text service and connect it via AdviseSink if you haven't already.)
After more research, I've figured out what’s happening:
When you set focus back to Word, TSF gets the current thread’s active keyboard layout (actually a locale ID).
It then compares that keyboard layout with the language ID of the currently active text service.
If they’re different, TSF then activates the text service for the active keyboard layout, and deactivates any previously active text service.
I believe this behavior is different on Vista/Windows 7.
The fix would be to use LoadKeyboardLayout/ActivateKeyboardLayout to set the process keyboard layout in your ITfTextInputProcessor::Activate implementation. Apparently some apps also need you to call ITfInputProcessorProfiles::ChangeCurrentLanguage() as well.
Is there any benefit of using COINIT_MULTITHREADED in a DirectShow application? For now it has given me some troubles, but I am not sure if using CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) is the right fix for the problems.
The full story:
I have a pretty straightforward web camera capture application with ability to choose the capture source and call the device manufacturer settings through OleCreatePropertyFrame.
My app runs pretty stable, no memory leaks, I can switch between devices without any problems (I completely rebuild DirectShow graph each time when user chooses device).
But there is only one problem after showing the property page of the capture filter. If I just show it and close without changing anything, all continues normally. If I change any setting in the property pages and then close the property frame, also everything continues seemingly normal .. until the next time I change the device and rebuild the graph. The previous graph gets destroyed normally, no errors, filters are being removed and released correctly. And right when I create a new graph and call graphBuilder->SetFiltergraph( pfg ), my app crashes with some weird access violation errors insde of Kernel32. But if I change COINIT_MULTITHREADED to COINIT_APARTMENTTHREADED, this error disappears.
So is that COINIT_MULTITHREADED a real problem of my application or maybe there is some other monster hiding somwhere? Has someone experince with it?
Any thread that creates a window must be STA. Both user32 and gdi are fundamentally thread-unsafe.
I have a Macintosh Mozilla plugin which puts up a separate window for login information.
It seems to work fine, it gets keyboard events like typing and hitting
return to hit the default button. HOWEVER, it doesn't seem to get cut
and paste events. When I hit Cmd-v, the edit menu flashes, but nothing
happnes.
Is this a problem with my responder chain? Do I have to specially tell
Mozilla that I want these events? or am I likely to have some other
problem that I haven't even thought of?
It turns out the problem is that I'm using cocoa windows inside Mozilla, which isn't Cocoa... fail.