Trying to use a CScrollBar in my MFC C++ application for Windows7.
I receive all messages just fine and have a handler that looks something like this:
void Dialog::OnHScroll(UINT nSBCode, UINT apos, CScrollBar* pScrollBar)
{
SCROLLINFO si;
si.cbSize = sizeof( si );
si.fMask = SIF_TRACKPOS;
m_slider.GetScrollInfo(&si,SIF_TRACKPOS|SIF_POS|SIF_PAGE);
int nTrackPos = si.nTrackPos; //0 except on TB_THUMBTRACK
int nPos = si.nPos; //0 except on TB_THUMBTRACK
UINT nPage = si.nPage; //seems correct always but I dont need it
The reason I try to extract the position using GetScrollInfo is because they may be bigger than what fits inside a 16bit var, and therefore I cannot use the pos being passed as the argument.
My problem however is that I only get a valid position when dragging the bar and receiving the TB_THUMBTRACK as well as the ending TB_ENDTRACK for drag operations. If I click in the scrollbar or use the arrows at each end all positions (argument pos, and everything in the SCROLLINFO struct except page) will be 0.
Does anyone know how to get the correct positions for all messages? Ie TB_LINEUP, TB_LINEDOWN etc.
Take a look at the sample code for the WM_HSCROLL event handler that's shown in MSDN:
MSDN Documentation
Related
I am trying to make a simple spin control and edit box in WTL &/ winapi. and this does not work properly, because I only see 0 as initial value and the arrows don t work, code here:
HWND spin = GetDlgItem(IDC_SPIN1);
HWND edit = GetDlgItem(IDC_RANDOM_EDIT);
::SendMessage(spin, UDM_SETBUDDY, (WPARAM)edit, 0); //set buddy
::SendMessage(spin, UDM_SETRANGE, MAKELPARAM(0,100), 0); //interval
::SendMessage(spin, UDM_SETBASE, 10, 0); //initial position
You have your wparam and lparam reversed. You also have the low and high words reversed.
::SendMessage(spin, UDM_SETRANGE, 0, MAKELPARAM(100,0)); //interval
See the definitions of UDM_SETRANGE and MAKELPARAM.
In WTL you have wrapper class CUpDownCtrl for up-down control. So it goes as simple as this:
CUpDownCtrl Control = ... // e.g. GetDlgItem(IDC_MYCONTROL);
INT nMinValue = 0, nMaxValue = 100;
Control.SetRange(nMinValue, nMaxValue);
I'm using winapi's raw input devices for mouse input and it seems I'm not getting the correct values in my RAWMOUSE struct.
When I get the RAWMOUSE struct I get the values of lLastX and lLastY as I'd expect but for some reason the ulRawButtons is constantly 0. The msdn documentation says that ulRawButtons is "The raw state of the mouse buttons" so I take it this should change when I press a mouse button.
This is the code I create the raw input device with (I removed error checking for readability):
RAWINPUTDEVICE rid;
rid.usUsagePage = 0x01;
rid.usUsage = 0x02;
rid.dwFlags = RIDEV_INPUTSINK;
rid.hwndTarget = myWindowHandle;
RegisterRawInputDevices(&rid, 1, sizeof(rid));
After the WM_INPUT message I call:
void handleRawInput(HWND window, UINT, WPARAM wParam, LPARAM lParam)
{
RAWINPUT input;
UINT szData = sizeof(input), szHeader = sizeof(RAWINPUTHEADER);
HRAWINPUT handle = reinterpret_cast<HRAWINPUT>(lParam);
GetRawInputData(handle, RID_INPUT, &input, &szData, szHeader);
if (input.header.dwType == RIM_TYPEMOUSE)
{
// Here input.data.mouse.ulRawButtons is 0 at all times.
}
}
I'm using mingw32 (4.7) and I've defined WIN32_LEAN_AND_MEAN, WINVER=0x0501 and WIN32_WINNT=0x0501.
Any ideas why I'm not getting the correct values for ulRawButtons?
Windows populates the RAWMOUSE struct with what the mouse driver tells it via the MOUSE_INPUT_DATA struct.
You'll notice that the MSDN page for MOUSE_INPUT_DATA states the following:
RawButtons
Specifies the raw state of the mouse buttons. The Win32 subsystem does not use this member.
What the MSDN page doesn't say is that not only does Win32 not use RawButtons/ulRawButtons but the mouse drivers it ships do not populate them. So, unless you have a mouse driver from a 3rd party vendor, you are never going to get this field set.
I think what you are looking to use is: input.data.mouse.usButtonFlags for mouse clicks and input.data.mouse.usButtonData for scroll wheel delta.
I'm using WINAPI Treeview to show some data.
I have to get the selected TV_ITEM text, when I select a TV ITEM.
I'm using following code
case WM_NOTIFY:
switch( ((LPNMHDR)lParam)->code)
{
case TVN_SELCHANGED:
{
NMTREEVIEW* pnmtv = (LPNMTREEVIEW)lParam;
LPTSTR str = (pnmtv->itemNew.pszText);
MessageBox( hWnd, str,"load",MB_OK );
}
break;
}
I can't get the correct value, I got some kind of garbage value.
MessageBox shows some kind of special characters(Those are not in keyboard)
Shall anyone help me, how to get the selected item text.
Thanks in advance
Have you read the documentation on TVN_SELCHANGED? It never mentions pszText. You need to
TVITEM item;
item.hItem = pnmtv->itemNew.hItem;
item.mask = TVIF_TEXT;
item.pszText = // allocate buffer
item.cchTextMax = // length of buffer
::SendMessage(hWnd, TVM_GETITEM, 0, (LPARAM)&item);
and then you'll get item.pszText
P.S. If you're working with windows API, how often have you seen Windows allocating and managing strings for you? It just doesn't happen.
I want to get handle of child window, but cannot.
I want to automatically insert text in an Edit control.
Here is what I have:
//global var
int id=0;
BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam) {
id = GetDlgCtrlID(hwnd);
HWND hwnd_Child;
hwnd_Child = GetDlgItem(hwnd, id);
SendMessage(hwnd_Child, WM_SETTEXT, NULL, (LPARAM)"mYtexttttt");
/* other code */
// id is always 0, why ?
// return FALSE; // stop enumerating
return TRUE; // continue enumeration
}
void MyFunction ()
{
HWND hwnd_Parent;
hwnd_Parent = FindWindow(NULL,"MyTitle"); if(! hwnd)return;
EnumChildWindows(hWnd ,(WNDENUMPROC)EnumWindowsProc, NULL);
}
In WinSpy++, the control IDs of all the components are 000000000. Is it possible that the control ID isn't defined?
How do I find the child handle of some specific (edit box) component if I have the handle of the main window, and the control ID is not defined?
Also, main window is a game application which runs with DirectX, I think.
I want to automatically insert text in a Edit control.
If WinSpy tells you that the control IDs are 0 then getting a 0 back from GetDlgCtrlID() is of course the expected outcome. You'll have to do something else, like counting down the number of EnumWindowsProc() calls and/or calling GetClassName() so you can see it is an edit control. Or GetWindowRect() to go by position.
In your callback method, please do the following:
// get the window text
GetWindowText(hWnd, (LPTSTR)windowText, MAX_PATH);
// get the window info
WINDOWINFO objWinInfo;
GetWindowInfo(hWnd, &objWinInfo)
The above should help you get the child windows.
Also you can do FindWindowEx to the get the child windows.
Control ids are one convenient way to identify child windows; but not the only way. So it is quite possible that control id will be set to arbitrary (or zero) values (in which case the parent window just refers to them directly by their handles.
From your point of view if no control ids exist you must reference them by the position in the tab sequence which should be constant and can be iterated through.
I'm wondering how to get true mouse displacement with windows.
For example, I could save the position of a previous mouse position, and request the new position, and subtract the latter from the previous. But this would not give me true mouse displacement.
Imagine the previous cursor position would be the maximum x coordinate of your screen resolution, and the user is moving his mouse to the right. Is there still a way to capture the true mouse displacement then?
Thanks
Although it might be possible to actually read sensor data (after all the mouse itself only reports movement, not location), I'm not aware of how this could be done. I think at the very low levels of windows, that displacement information gets translated into cursor position on the screen and from then on, you will always be limited by your screen resolution.
In whatever you are trying to do, is the mouse cursor still visible?
A little while ago, I wrote a WPF numeric edit box control that mimicked the way those controls work in Expression Blend. The ones where you can drag the mouse from the edit box itself and it'll change the value. I ran into exactly same issue that you found and my solution was to hide the mouse cursor, detect displacement on every tick and reset the cursor to the center of the screen. Then when the user lets go of the button to stop dragging, I would put the cursor back to where I found it before the drag. This worked out really well and Expression Blend also behaves this way in hiding the cursor.
As far as I know DirectX has its own APIs to interact with peripherals, that is recommended for game developers. You should look into it - try for example DirectX 8 and the Mouse, more detailed documentation you can find on MSDN.
The most reliable way is to use window hooks. Here is a minimalist sample using C(++)
LRESULT CALLBACK LowLevelMouseProc(int nCode, WPARAM wParam, LPARAM lParam){
MSLLHOOKSTRUCT* hookStruct = (MSLLHOOKSTRUCT*)lParam;
int ScreenWidth = GetSystemMetrics(SM_CXVIRTUALSCREEN);
int ScreenHeight = GetSystemMetrics(SM_CYVIRTUALSCREEN);
int x = hookStruct->pt.x * ScreenWidth / 65536);
int y = hookStruct->pt.y * ScreenHeight / 65536);
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
HHOOK LowLevelMouseProcHook = NULL;
void hook_window_procedure()
{
if (LowLevelMouseProcHook == NULL)
LowLevelMouseProcHook = SetWindowsHookEx(WH_MOUSE_LL, (HOOKPROC)LowLevelMouseProc, (HINSTANCE)NULL, NULL);
}
void unhook_window_procedure()
{
if (LowLevelMouseProcHook != NULL)
UnhookWindowsHookEx(LowLevelMouseProcHook);
}
You can hook the mouse calling hook_window_procedure(); and unhook it by calling unhook_window_procedure();
You will receive calls to void LowLevelMouseProc(...) whenever the mouse moves. lParam contains a pointer to MSLLHOOKSTRUCT and you find all needed mouse information in its structs. Most interesting here is POINT pt; that is in relative screen coordinates assuming 1/65536th of the screen. Transform them to real pixels by multiplying with int ScreenWidth or int ScreenHeight and dividing by 65536
If you struggle being clamped by the screen borders, you can make a workaround setting the mouse back to the center of your window each call. This is often seen in older games. If you are not forced to use only the Windows API, I would try using Direct Input.
Another way would be to evaluate WM_INPUT directly in your WindowProc for example. This reads data directly from the Human Interface Device (HID) stack and should have raw Mouse-Data in it. Here is a link to the MS-Documentation
The method on windows is as such:
// you can #include <hidusage.h> for these defines
#ifndef HID_USAGE_PAGE_GENERIC
#define HID_USAGE_PAGE_GENERIC ((USHORT) 0x01)
#endif
#ifndef HID_USAGE_GENERIC_MOUSE
#define HID_USAGE_GENERIC_MOUSE ((USHORT) 0x02)
#endif
RAWINPUTDEVICE Rid[1];
Rid[0].usUsagePage = HID_USAGE_PAGE_GENERIC;
Rid[0].usUsage = HID_USAGE_GENERIC_MOUSE;
Rid[0].dwFlags = RIDEV_INPUTSINK;
Rid[0].hwndTarget = hWnd;
RegisterRawInputDevices(Rid, 1, sizeof(Rid[0]));
then in message loop:
case WM_INPUT:
{
UINT dwSize = sizeof(RAWINPUT);
static BYTE lpb[sizeof(RAWINPUT)];
GetRawInputData((HRAWINPUT)lParam, RID_INPUT, lpb, &dwSize, sizeof(RAWINPUTHEADER));
RAWINPUT* raw = (RAWINPUT*)lpb;
if (raw->header.dwType == RIM_TYPEMOUSE)
{
int xPosRelative = raw->data.mouse.lLastX;
int yPosRelative = raw->data.mouse.lLastY;
}
break;
}
Installing hooks will trigger sensitive antiviruses.
MSDN doc to refer
This sort of displacement ? : http://en.wikipedia.org/wiki/Differential_calculus
Try pitch/yaw : How could simply calling Pitch() and Yaw() cause the camera to eventually Roll()?
FPS style : http://cboard.cprogramming.com/game-programming/94944-mouse-input-aiming-fps-style-using-glut.html
and this : Jittering when moving mouse
pseudo code:
int mouseX, mouseY;
int oldMouseX, oldMouseY;
while(game_is_Running)
{
oldMouseX = mouseX;
oldMouseY = mouseY;
mouseX = get_new_mouse_from_windows_X();
mouseY = get_new_mouse_from_windows_Y();
if ((mouseX - oldMouseX) > 0)
{
// mouse moved to the right
}
else if ((mouseX - oldMouseX) < 0)
{
// mouse moved to the left
}
if ((mouseY - oldMouseY) < 0)
{
// mouse moved down
}
else if ((mouseY - oldMouseY) > 0)
{
// mouse moved up
}
}
A common method for this (in games):
Every frame of the game, get the position of the mouse and then recenter the mouse in the middle of the window using operating system functions. For every frame other than the first, this should give you an accurate displacement information. The key is to just be re-centering the mouse every frame so it never reaches the blocking outer bounds of the screen.
EDIT: Woops, didn't realize that DXM had already said this.
It is not possible to track physical mouse displacement with the Windows API. However, DirectInput provides features to keep track of it. You can also 'fake' it using only the Windows API, using the neat little trick in the answer of SO user DXM