I am working on a program that will replicate, and then extend the functionality of Aero Snap.
Aero Snap restores a maximized window, if the user "grabs" it's title bar, and I am having difficulties identifying this action.
Given a cursor position in screen coordinates, how would I check if the position is within the window's title bar? I am not really at home in the Win32 API, and could not find a way that works reliably for complicated scenarios such as:
Note that tabs that chrome inserts into the title bar. Office does something similar with the quick launch menu.
title bar hits are via the message "non client" messages - ie the area of a window that is not the client (or inner) window.
WM_NCLBUTTONDOWN is probably the message you want to trap.
You also probably want to set a window hook to hook mouse messages, if its the NC message you want, you handle it your way, if not - pass it on to the message chain.
Edit: if Chrome is using the DwmExtendFrameIntoClientArea calls to draw the tabs, then you will need to use WM_NCHITTEST.
Related
I must find the coordinates of a point which is out of the application window.
I intend to have a button "Specify Point" and when the user clicks this button, their next mouseclick will be registered by the program as this desired point. The problem is I don't know how to implement this....Any ideas ?
You can call SetCapture to direct mouse clicks from anywhere on the desktop to your window. Call ReleaseCapture after the click to return to normal.
If the user clicks on another application you will receive the click but the other application will also be activated, which you probably don't want. To avoid this, an alternative approach is to overlay the entire desktop with an always-on-top very nearly fully transparent window (a fully transparent window won't get clicks). Transparent windows are known as layered windows; use the WS_EX_LAYERED extended style to create one.
Does anyone know how to detect if a Win32(c++) window has stopped moving?
WM_MOVE detects when the window is moving, but how does one detect when it has stopped moving?
The windows message you wish to handle is WM_EXITSIZEMOVE.
WM_EXITSIZEMOVE message (Windows) # MSDN
Depending on what you wish to accomplish, there's also the possibility that you might be better served by reacting to WM_NCLBUTTONUP, which is sent when the mouse button is released in the non-client areas of a window, such as the title bar of any window with a caption, border chrome, etc.
WM_NCLBUTTONUP message (Windows) # MSDN
My application has a big graphics area with some controls (sliders, buttons, text edit controls) in a side panel. The graphics area understands some keyboard commands.
My problem is that when a control in the side panel is in focus, the main graphics area won't receive any keyboard commands, so this confuses the users. However, for some controls, this is intended, e.g. text edit controls.
What I want is the focus to automatically return to the graphics area at the earliest possible occasion (which I call "greedy" focus) -- e.g. when text editing is finished (Enter key), or when the user has selected an item from a combo box.
I am looking for a clean and robust strategy for dealing with the problem, either using Windows API or Borland Vcl.
I'd appreciate if you want to share your ideas.
I haven't fully solved the problem yet, but a very useful message to intercept on form level is CM_DIALOGKEY (Borland Vcl only). It gets sent for every key that is normally used for navigating within the UI. That is, cursor keys, tab and shift-tab, Enter and possibly others.
I've added an event handler for CM_DIALOGKEY that returns the focus to the graphics area and also forwards the key press to that component. This way the user can still control the UI elements via keyboard (important for text entry), but cursor keys are handled by the graphics area.
I know what you mean I had similar problem with some BIG apps lice CAD/CAM ...
My solution is simple, robust and I use it for years.
1.all keystrokes handling for that gfx area
must be done in events of the Form where the area is located
not in panels,paint box whatever...
2.create unfocus function (preferably member of form but it is not required)
this function will loose focus of any VCL item
so the focus goes to form itself which is what you want
I am using this:
//---------------------------------------------------------------------------
void main_unfocus()
{
Main->bt_unfocus->Visible=true;
Main->bt_unfocus->SetFocus();
Main->bt_unfocus->Visible=false;
}
//---------------------------------------------------------------------------
Main is the Form pointer
bt_unfocus is button (can be any focusable VCL component)
I place this button usually on the left upper corner of App and set its size to 2x2 pixels
it is invisible at start
the idea is to set focus to it (but first unhide it so no exception is thrown)
and then hide it so it loses focus
work well in BCB5 and BDS2006 (did not used it with any other IDE)
as you can see most of the time is this component invisible
4.now when to call main_unfocus ?
when you go with mouse from outside to inside of your gfx area (OnMouseMove event)
or when you click on it
also you can combine this with remembering if the focus is or not in gfx area
that can be done with events like OnExit ...
or when you hit Esc while focus is inside edit box ...\
I am sure you grasp the idea and adjust this to your needs
Hope it helps
I want to allow a user to drag my Win32 window around only inside the working area of the desktop. In other words, they shouldn't be able to have any part of the window extend outside the monitor(s) nor should the window overlap the taskbar.
I'd like to do it in a way that does cause any stuttering. Handling WM_MOVE messages and calling MoveWindow() to reposition the window if it goes off works, but I don't like the flickering effect that's caused by MoveWindow().
I also tried handling WM_MOVING which prevents the need to call MoveWindow() by altering the destination rectangle before the move actually happens. This resolves the flickering problem, but another issue I run into is that the cursor some times gets aways from the window when a drag occurs allowing the user to drag the window around while the cursor is not even inside the window.
How do I constrain my window without running into these issues?
Windows are, ultimately, positioned via the SetWindowPos API.
SetWindowPos starts by validating its parameters by sending the window being sized or moved a WM_WINDOWPOSCHANGING message, and then a WM_WINDOWPOSCHANGED message notifying the window proc of the changed size and/or position.
DefWindowProc handling of these messages is to, in turn, send WM_GETMINMAXINFO and then WM_SIZE or WM_MOVE messages.
Anyway, handle WM_WINDOWPOSCHANGING to filter both user, and code, based attempts to position a window out of bounds.
Keep in mind that users with multi-monitor setups may have a desktop that extends into negative x- and y-coordinates, or that is not rectangular. Also, some users use alternative window managers such as LiteStep, which implement virtual desktops by moving them off-screen; if you try to fight this, your application will break for these users.
You can do this by handling the WM_MOVING message and changing the RECT pointed to by the lParam.
lParam: Pointer to a RECT structure with the current position of the window, in screen coordinates. To change the position of the drag rectangle, an application must change the members of this structure.
you may also want to handle WM_ENTERSIZEMOVE to know when the window is beginning to move, and WM_EXITSIZEMOVE
WM_GETMINMAXINFO is what you seem to be looking for.
I would like to send some keystrokes from a C++ program into another window.
For that reason I would like to have the user select the target window similar to how it is done in the Spy++ utility that comes with Visual Studio (drag a crosshair cursor over target window and have target window highlighted by a frame).
How is this dragging and selecting done in Windows? I am completely lost as to where I might start to look for a mechanism to implement this feature.
Here's how it's usually done:
Capture the mouse using SetCapture. This will cause all mouse messages to be routed toward your app's window.
Handle the WM_MOUSEMOVE message. In your handler code, grab the window underneath the mouse using WindowFromPoint. That will get you the HWND of the window the mouse is currently over.
Now that you've got the window, you need a device context (HDC). You can get one using GetWindowDC for the specified window.
Now you can draw into the DC using typical GDI functions.
There are some things you have to look out for - cleanly erasing the selection rectangle and so forth, but that's one way to do it.
You could also draw into a screen DC to do this, but in any case you'll need the window handle in order to get the window rect.
If you Google around Spy++ source code you'll see a few examples of this technique.
Formers answers are wrong.
Spy++ source code has been given on G. Groups for years (see mainly Win32 api ng news://194.177.96.26/comp.os.ms-windows.programmer.win32)