Imagine I save my window's position in my preferences file. Now, the user moves the window to a second monitor, then quits my app. Then he disconnects the second monitor and launches my app again.
Now my app wants to restore the window's saved location. But if it blindly restores the old window coordinates, the window will be off-screen.
I used to use ConstrainWindowToScreen for my Carbon app, but now that I'm porting it to Cocoa, I can not find an equivalent for this.
The docs suggest that, somehow, Cocoa would automatically prevent this from happening. While that might be the case when the monitors change while the window is open, in my case where I've stored the window location myself and restore them when I re-open the window at launch, this isn't going to work. I need to invoke Cocoa's magic functionality on demand, but how?
(Note: I am aware that I could iterate over all available screens, but that's quite a pain to write myself if I want to get this foolproof. Still, if you can present a complete C or ObjC function that solve it this way, that'd be appreciated, too.)
See the "Managing Window Frames in User Defaults" section in the NSWindow Class Reference. Those methods ensure that a window will be placed entirely on screen.
If you want to save and restore the window location yourself (as a string), use -stringWithSavedFrame and -setFrameFromString:.
Use -saveFrameUsingName: and -setFrameUsingName to have NSWindow save and restore its frame in the user defaults, given a window name.
I agree with Darren's suggestion to use the built-in mechanism for restoring window positions. Really, it's as easy as setting a window's frame autosave name in IB (or with -setFrameAutosaveName:).
That said, if a window has a title bar, then all of the methods which order it onto the screen (e.g. -orderFront: or -makeKeyAndOrderFront:) will automatically reposition it to make sure at least the title bar and a significant chunk of the window is on the screen. It's honestly difficult to get a titled window to be theoretically visible but actually off-screen.
Related
I want to detect when a window is being moved in real time and figured that CGDisplayStreamCreate etc. should provide just that. But I'm having difficulty deciding which window is being moved when my CGDisplayStreamFrameAvailableHandler is called. Is there a direct way to match the updated rects with with an app and its windows?
CGDisplayStream cannot tell you which applications/windows are responsible for a given screen update. You might be able to use another API like Accessibility to determine window locations and then guess which of the kCGDisplayStreamUpdateMovedRects corresponds to each window, but that will not be very reliable. If you're going to go the route of Accessibility, you may as well use Accessibility notifications for window move events: How can my app detect a change to another app's window?.
If you also need the pixel contents of the windows when they are moving, then you'll need to do some unfortunate time alignment between CGDisplayStream and Accessibility callbacks.
The title basically sums up my question. I'd like to know what the difference between the Mac Carbon SelectWindow and ActivateWindow(..., TRUE) is. I've found these in old source and wonder if they are interchangeable (or what their Cocoa equivalents might be).
From memory...
SelectWindow was the response to clicking on a window. It brought the window to the front, activated it, and (usually) made it the first responder. (I'm using Cocoa terminology here.) It's sort of like OrderFront
The SelectWindow function removes highlighting from the previously
active window, brings the specified window to the front, highlights
it, and generates the activate events to deactivate the previously
active window and activate the specified window. If the specified
window is already active, SelectWindow has no effect. Call
SelectWindow when the user presses the mouse button while the cursor
is in the content region of an inactive window.
Activate Window updated the window frame to indicate that the window was the first responder.
You don't really need to know a Cocoa equivalent, you just need to identify what you want to do. Many things from Carbon that required you to implement them are done for you by AppKit. Other paradigms of Carbon APIs just do not happen in Cocoa. They look similar, and had many similar hooks to common OS things, but they're very very different.
So, I have a dialog based application using pure WinAPI. There is a main dialog, and then multiple other dialogs that are toolwindows. These toolwindows are meant to free-float around, the user can drag them, hide them, and show them, but they have no taskbar entry. This is what I intended, but the problem is, when I switch from the main window to a different application, then click on the taskbar entry for the main window, the main window will show up, but the toolwindows will not. They stay hidden behind the main window and sometimes windows of other applications, and you cannot use them until you move all of the top-most windows and hunt down the toolwindow.
So, what I'm trying to do to work around this is, when the user restores the window from being minimized, I want to enumerate through all of the tool windows and bring them to the front, maybe by calling SetActiveWindow().
But what message gets sent when the window is restored? I was thinking WM_SHOW, or WM_RESTORE, but they don't exist.
Another question, and if you answer this the first question is irrelevant because I will no longer need to use that workaround: Is there a better method of bringing all tool-windows to the front?
Give the tool windows the WS_POPUP style (and not WS_OVERLAPPED), and make the main window their parent (strictly it is their owner window). That way the tool windows will remain on top of the main window. This may (or may not) be what you want.
The naive answer to the question is to listen to WM_SIZE and respond to a wParam value of SIZE_RESTORED.
The other obvious possibility is to make all the tool windows be owned by the main window. So long as you are happy for the tool windows always to be on top of the main window, this will solve your problem. The owned windows will be hidden when the owner is minimized, and re-shown when the owner is restored.
Learn more about ownership in the MSDN topic on Window Features.
I am working on a utility application that controls other running applications. On certain input event my application displays a window, user can pick some operation from the window, the window disappears and control returns to the previous app. My problem is that clicking in my app’s window activates my application, thus removing focus from the previous application’s window. I can re-activate the previous application when my window closes, but I’d rather keep the original application activated all the time. Is that possible?
It's quite easy to to, just make your window an instance of NSPanel (a subclass of NSWindow), and set it as non-activating in Xcode/IB (or create it programatically, with NSNonactivatingPanelMask in the style mask).
One idea would be: while your app is running, try to keept track of the active window in the system.
After you activate your app and click the command button, restore the previous active window.
This is only an idea, I don't know how to do it on mac.
I am using Interface Builder to work on NIBs and one of the NIBs must have a view on my external monitor which is not attached because I cannot see it on my MacBook. I have had this problem with editing iPad NIBs which I work on with my larger external monitor.
For some reason Interface Builder is not detecting that there is now just one screen and not pulling this view onto this monitor. There has to be a way to get this back into the visible space so that I can work on it. I have tried double clicking on the view icon in the organizer which normally brings the view forward but it is not coming into view.
What can I do? Is this really a bug that has been around this whole time?
I was seeing this problem as well -- the easiest way to fix it is:
In Interface Builder, double-click on the view object. This would ordinarily bring up the window and give it focus, but in this case it's invisible.
Hit Cmd-W to "close" the invisible window
Double-click the view object again; the window should now re-open onscreen.
Yes - it messes up this way when a XIB is created on a computer with multiple monitors but then later edited on different computer with just one.
To my knowledge the only way to fix is to to open the XIB with a text, or ideally XML, editor and search for negative values in various positioning strings. I've searched for {{-and then changed any negative values found to 0. For example, you'll run across {{-237,172}} When you find the open brace, open brace, minus sign pattern then change the negative value to a zero. i.e. {{-237,172}} becomes {{0,172}}.
When you re-open the XIB in IB you'll then be able to see your views.
To be safe make a copy of the XIB before hand editing.
Try using Exposé to see if the window shows up there. Ordinarily you can use Window > Arrange in Front to rearrange your windows, but it seems the non-document windows in IB don't obey ordinary Cocoa window handling so this command has no effect on them.
I wasn't able to reproduce it myself (when I disconnected my 2nd monitor, the window on it moved to my main monitor), but it may have something to do with the arrangement of your screens. If this turns out to be an IB bug you can reproduce, please file it (bugreport.apple.com).
Not sure if this will work, but open the window from your xib (double-click it) in Interface builder, then go to the "Window Size" section of the inspector. 2 Places might help in there, first the "Initial Position" shows a representation of the window and you might be able to just drag it back to the proper place. Second is "Content Frame". There are "X and Y" settings so try changing them to 0 and see if that does it.
<object class="NSMutableArray" key="dict.values">
<bool key="EncodedWithXMLCoder">YES</bool>
<string>WhatEverYouNamedIT</string>
<string>UIResponder</string>
<string>{{237, 644}, {320, 480}}</string>
<string>com.apple.InterfaceBuilder.IBCocoaTouchPlugin</string>
</object
I opened the .xib file with Dashcode and changed the {{237, 644} to {{0, 172} saved and opened with IB and the view "canvas" windows was back on my laptop screen everything else opened up on my external monitor.
THANKS!!!