Lion Full Screen menu bar doesn't slide down - cocoa

I've got a small window that has no borders, titlebar, buttons, etc. I want to support full -screen mode (the new Lion kind) and I basically have all that working -- I can switch into and out of fullscreen mode and the window resizes itself, etc, no problems.
However, when I move the mouse to the top of the screen, the Menu bar with the icon to close the full screen mode does not slide down.
How do I get that working? Is it keyed off a style mask? Something else?

A-ha, the key is in what you return for
- (NSApplicationPresentationOptions)window: (NSWindow *)window willUseFullScreenPresentationOptions: (NSApplicationPresentationOptions)proposedOptions
You need to add NSApplicationPresentationAutoHideMenuBar | NSApplicationPresentationHideDock to the returned values in addition to NSApplicationPresentationFullScreen.

The only thing you need to do to make full screen mode work in Lion is to call ‑setCollectionBehavior: on your window and pass in NSWindowCollectionBehaviorFullScreenPrimary.
You don't need to do anything else. All the kiosk-mode stuff is not necessary unless you are targeting 10.6 or earlier.

Related

Is it possible to determine if a window has a scrolling function/interaction in AutoHotKey?

For the purpose of putting more actions on fewer buttons I was hoping to detect if a window has scrolling functions. For example when a pop-up is asking you if you want to save something or not it tends to default to No. That window does not have any functionality tied to the mouse wheel action. In that scope I was planning to have the mouse wheel up and down input up or down directions. Maybe there is a way to detect if the window has scrolling enabled? Or maybe there is another work-around such as that pop-up window having a specific windows class?
Look at the GetScrollBarInfo function in the answer here How I can check if a Window has visible scrollbars using his HWND? for some useful info, but in my view, easiest is to capture window classes and fire mouse wheels accordingly, just like the example in the help for #if except you will need a correct WinTitle (use class of pop up) instead of identifying the Taskbar, and you will send tab and alt+tab in your mousewheels instead of the volume controls:
#If MouseIsOver("ahk_class Shell_TrayWnd")
WheelUp::Send {Volume_Up}
WheelDown::Send {Volume_Down}
MouseIsOver(WinTitle) {
MouseGetPos,,, Win
return WinExist(WinTitle . " ahk_id " . Win)
}
https://www.autohotkey.com/docs/commands/_If.htm
Hth,

How can i draw to or add a custom button to every window of all applications?

I have seen several tools adding a custom button and/or drawing on the title bar of all windows of all applications in Windows. How is that done?
Extra points for an example in Delphi.
EDIT:
I found something for dotNET that does this:
http://www.thecodeking.co.uk/2007/09/adding-caption-buttons-to-non-client.html#.VdmioEDenqQ
How I see this job:
First of all we should be able to paint this button on the our own window caption. This procedure will be used later
This part of the program enumerates the active and visible windows
This part of the program using injection attach our dll to enumerated windows
From injected dll we can draw the button on the window caption
Inside this dll we should process the click on the button
We should have mechanism to send result to our main program
I haven't done this, so the following is what I would investigate if I were to try:
For each application / each top-level window:
Create a floating window and position it over the title bar wherever you want it to sit. Set up the parent / child relationship, but this window is part of your own process. (There are occasionally problems parenting a window from one process to one from another process, but try. I'd avoid injecting into other processes if possible.)
You can investigate the window flags to see if the window has a title bar (ie if you should add a button) via GetWindowLong with GWL_STYLE looking for WS_CAPTION. The same call will also let you see the type of caption / frame, which you can combine with GetSystemMetrics with, eg, SM_CYDLGFRAME to figure out the right size for your button on this specific window's title bar.
This window is now your button: paint, handle clicks etc as appropriate.
Make it a non-focusable window so that clicks to it don't take focus away from the window is is on the title bar of. You don't want clicking it to make the title bar change colour, for example. Do this by setting the WS_EX_NOACTIVATE window flag, something like: SetWindowLong(Handle, GWL_EXSTYLE, GetWindowLong(Handle, GWL_EXSTYLE) orWS_EX_NOACTIVATE).
The main problem is to keep it positioned correctly when the window moves, is resized, etc. To do this, install a hook for the system move events. You can also hook minimize and restore via EVENT_SYSTEM_MINIMIZESTART and EVENT_SYSTEM_MINIMIZEEND. This will allow you to keep track of all windows moving around onscreen, such that you can adjust the button-window position if necessary.
That gives you a window which you can paint as a button (and respond to clicks etc), that visually is "attached" to other windows so it stays in the same place as the user drags the title bar, minimizes or maximises the app, etc, and that is in your own process without cross-process problems.

OS X: Capture keyboard input without visually taking focus

I'd like to develop an app that lives in the background but can show some UI that captures keyboard input when asked, like Spotlight.
When Spotlight is active, it gets keyboard input but the window in the background still has visual focus. (Any insertion point in the background application goes away though.)
How can I create this effect myself?
The window must…
be a subclass of NSPanel which
overrides canBecomeKeyWindow to return true and
has been initialized with a style mask including NSNonactivatingPanelMask.
Then you can bring it to the front with window.makeKeyAndOrderFront(nil), even if your application is not active.

Change window menu's location

In Windows when you open a menu, its location on the screen depends on the location of its parent window and screen resolution. Ie when a menu does not fit the screen, then it moves to another side.
How does this mechanism work in the OS? Is it possible to substitute the value of screen resolution, so that the window would consider that the screen is smaller than it actually is?
I want to make a drop-down and context menus to appear only in window area. Now I use CBThook and WndProc and recount the location of the menu that appears. Perhaps there is a way to make it easier?
TrackPopupMenuEx does allow you to specify a rectangle on the screen that the menu should not overlap, I guess that is sort of the opposite of what you want, but it is as close as you are going to get without horrible hacks.

Hide window until the top window is displayed

I am facing a little annoying design problem. Not easy to give a title of my question.
I must display two windows, one over another one. The first one is a Cocoa window, the second is made with Qt. In the second window, an action is performed, but the user can choose to close this window. He must fall back on the first window.
To display my first window, which is actually a SFAuthorizationPluginView, I do:
[myview displayView];
then, to display the window made with Qt on top of first window:
QWidget* w = openMyScreen();
NSView* v = (NSView*)w->winId();
[[v window] setLevel:2003];
This works well, however there is a small delay before the second window is displayed. We can thus see for a very short time the first window.
I need that the second window stays on top of the first window, because the user can close the second window and must have access to the first window.
Any ideas on a trick how to hide the first window, just the time, the second window appears?
Thanks in advance
NSDisableScreenUpdates and NSEnableScreenUpdates (link) might be useful in this situation. The documentation says:
You typically call this function so that operations on multiple windows appear atomic to the user.
which seems to describe your situation.
A word of unrelated advice though: Don't go setting window levels willy-nilly. A window level of 2003 will likely cause the window to appear over things like the dock or even the menu bar, which would definitely be strange. You should stick to the standard levels declared in NSWindow.h unless you have good reason. NSFloatingWindowLevel might be appropriate (although I'm not sure what level the SFAuthorizationPluginView window is displayed at).
Starting with MacOS 10.4, you can use :
[NSWindow disableScreenUpdatesUntilFlush];

Resources