I am hooking the ExtTextOut GDI API.
There I want to retrieve the exact location of the output String.
BOOL ExtTextOut(
__in HDC hdc,
__in int X,
__in int Y,
__in UINT fuOptions,
__in const RECT *lprc,
__in LPCTSTR lpString,
__in UINT cbCount,
__in const INT *lpDx
);
In a specific case I am getting ETO_CLIPPED for the fuOptions param which mean I can get the location of the string from the RECT param or from the X,Y params.
However when I use the LPtoDP API for translating the location (RECT or X,Y) I get wrong location (before translating I get negative values).
I guess it has a wrong offset, however when I check the followings I see no indicaton for that:
Map Mode is MM_TEXT (default)
GetWindowOrgEx is 0,0
GetViewportOrgEx is 0,0
GetWindowExtEx is 1,1
GetViewportExtEx is 1,1
Does anyone have any idea, any help will be appreciated.
Thanks.
Apparently, specifying ETO_CLIPPED in the ExtTextOut fuOptions param
does not imply that the text will be output to that clip, meaning that it is not guaranteed that the device context is of type display device context, and the device context that is used can be a memory device context, as in my case, and therefore do not contains the right coordinates.
msdn: ETO_CLIPPED The text will be clipped to the rectangle.
Related
MSDN -> "GetDlgCtrlID function" -> Remarks:
"... Although GetDlgCtrlID may return a value if hwndCtl is a handle to a top-level window, top-level windows cannot have identifiers and such a return value is never valid."
It seems it is wrong information - "never valid".
At least for Win2k...Win8 this return value is just kernel pointer to hmenu(bar).
And my question is (primarily to MS insiders): why MSDN so inaccurate here?
(Screenshot: http://files.rsdn.ru/42164/gwl(-1)_tagwnd.png)
Upd (tagWND):
Also demo: http://files.rsdn.ru/42164/gwl(-1)_tagwnd.zip
It is not inaccurate. You create a top-level window with CreateWindowEx(). Which looks like this:
HWND WINAPI CreateWindowEx(
_In_ DWORD dwExStyle,
_In_opt_ LPCTSTR lpClassName,
_In_opt_ LPCTSTR lpWindowName,
_In_ DWORD dwStyle,
_In_ int x,
_In_ int y,
_In_ int nWidth,
_In_ int nHeight,
_In_opt_ HWND hWndParent,
_In_opt_ HMENU hMenu,
_In_opt_ HINSTANCE hInstance,
_In_opt_ LPVOID lpParam
);
Note how you don't specify the ID anywhere. But the fine print is in the description for the hMenu argument:
A handle to a menu, or specifies a child-window identifier, depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events. The application determines the child-window identifier; it must be unique for all child windows with the same parent window.
So you can have a menu OR a child ID. Overloaded, pretty common in the winapi, a child control can't have a menu and a toplevel window can't have a child ID. If you forge ahead and ignore this and call GetDlgCtrlID() on a toplevel window anyway then you will get back the value of the hMenu argument you specified in the create call. Well, today, always follow the api or you might get a rude surprise some day, you'd of course use GetMenu() instead.
I've searched all over Google but found no answer, so If someone knows It would be very thankful!
I want to use command line or some WinApi to check the state of the multiple display.
For example : If I set : "extended screen" or "duplicate screen" I want to be able to verify it.
Just have no idea where to start.
thanks a lot
I would start with the WinAPI EnumDisplayMonitors function: http://msdn.microsoft.com/en-us/library/dd162610%28VS.85%29.aspx
BOOL EnumDisplayMonitors(
_In_ HDC hdc,
_In_ LPCRECT lprcClip,
_In_ MONITORENUMPROC lpfnEnum,
_In_ LPARAM dwData
);
You need to call this function setting the first 2 parameters to NULL like this:
EnumDisplayMonitors(NULL, NULL, MyPaintEnumProc, 0);
//Enumerates all display monitors.
//The callback function receives a NULL HDC.
Now you have your MonitorEnumProc callback function: http://msdn.microsoft.com/en-us/library/dd145061%28v=vs.85%29.aspx
BOOL CALLBACK MonitorEnumProc(
_In_ HMONITOR hMonitor,
_In_ HDC hdcMonitor,
_In_ LPRECT lprcMonitor,
_In_ LPARAM dwData
);
You wiil get filled lprcMonitor back:
A pointer to a RECT structure.
If hdcMonitor is non-NULL, this rectangle is the intersection of the clipping area of the device context identified by hdcMonitor and
the display monitor rectangle. The rectangle coordinates are
device-context coordinates.
If hdcMonitor is NULL, this rectangle is the display monitor rectangle. The rectangle coordinates are virtual-screen coordinates.
Based on this values for ALL monitors you can decide whether you have an extended mode (the rects are different) or the duplicate (they are equal).
HTH - good luck!
I want to read and write pixels directly from/to a drawing context, i.e. during a paint operation on a window.
I understand that there are GetPixel/SetPixel functions in Windows GDI, but for big operations it would be far better to be able to read and write pixel data directly to memory.
How can I do this using standard GDI?
You could create a compatible DC, Bitmap:
HDC hMemDC = CreateCompatibleDC(hdc);
HBITMAP hBmp = CreateCompatibleBitmap(hdc, WIDTH, HEIGHT);
SelectObject(hMemDC, hBmp);
Next, there is GetDIBits function you can use to get bits:
int GetDIBits(
_In_ HDC hdc,
_In_ HBITMAP hbmp,
_In_ UINT uStartScan,
_In_ UINT cScanLines,
_Out_ LPVOID lpvBits,
_Inout_ LPBITMAPINFO lpbi,
_In_ UINT uUsage
);
NOTE: You might need to set lpvBits to NULL to get the dimensions and format of the image via BITMAPINFO (lpbi parameter).
Use GetObject to get the BITMAP struct which contains a pointer to the bitmap's data.
I would like to measure rssi value of modem.Is there any api to get rssi value for Windows?I used to do that with Wifi.Manager in android.But i couldn't find any api for Windows
Using Native code is the best. You will need to use WlanQueryInterface() with wlan_intf_opcode_rssi opcode which will return RSSI value as LONG data type. From there you can convert it to dbm.
DWORD WINAPI WlanQueryInterface(
__in HANDLE hClientHandle,
__in const GUID *pInterfaceGuid,
__in WLAN_INTF_OPCODE OpCode,
__reserved PVOID pReserved,
__out PDWORD pdwDataSize,
__out PVOID *ppData,
__out_opt PWLAN_OPCODE_VALUE_TYPE pWlanOpcodeValueType
);
Here using opcode wlan_intf_opcode_rssi you will get RSSI value:
WLAN_INTF_OPCODE >> wlan_intf_opcode_rssi >> LONG
Here is the C++ sample on how to start with:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms706765(v=vs.85).aspx
If you want C# Try this:
How to get SSID and RSSI for Win7 using C#
Since this question appeared on home page for review- the existing answer is outdated.
There is now a Managed Wifi API available as a wrapper around the Windows Native Wifi API.
Signal strength in percentage and RSSI could be obtained as,
Wlan.WlanAvailableNetwork[] networks = wlanIface.GetAvailableNetworkList(0);
Wlan.WlanBssEntry[] redes = wlanIface.GetNetworkBssList(); //Get the atribute that you need
foreach (Wlan.WlanBssEntry network in redes)
{
Console.Write("Network SSID {0} RSSI {1}\n ", GetStringForSSID(network.dot11Ssid),
network.rssi);
}
It's taken a few years, but I am finally taking the plunge into VC++. I need to be able to read x number of sectors of a physical device (namely a hard drive). I am using the CreateFile() and SetFilePointerEx() and ReadFile() APIs.
I have done a LOT of reading online in all the major forums about this topic. I have exhausted my research and now I feel it's time to ask the experts to weigh in on this dilemma. As this is my very first post ever on this topic, please go easy on my :)
I should also point out that this is a .DLL that I consume with a simple C# app. The plumbing all works fine. It's the SetFilePointer(Ex)() APIs that are causing me grief.
I can get the code to work up until about the size of a LONG (4,xxx,xxx) - I can't remember the exact value. It suffices to say that I can read everything up to and including sector # 4,000,000 but not 5,000,000 or above. The problem lies in the "size" of the parameters for the SetFilePointer() and SetFilePointerEx() APIs. I've tried both and so far, SetFilePointerEx() seems to be what I should use to work on 64-bit systems.
The 2nd and 3rd parameters of the SetFilePointer are defined as follows:
BOOL WINAPI SetFilePointerEx(
__in HANDLE hFile,
__in LARGE_INTEGER liDistanceToMove,
__out_opt PLARGE_INTEGER lpNewFilePointer,
__in DWORD dwMoveMethod
);
Please note that I have tried passing the LowPart and the HighPart as the 2nd and 3 parameters without any success as I get a CANNOT CONVERT LARGE_INTEGER TO PLARGE_INTEGER (for parameter 3).
HERE IS MY CODE. I USE A CODE-BREAK TO VIEW buff[0], etc. I would like to read past the 4,xxx,xxx limitation. Obviously I am doing something wrong. Each read past this limit resets my file pointer to sector 0.
#include "stdafx.h"
#include <windows.h>
#include <conio.h>
extern "C"
__declspec(dllexport) int ReadSectors(long startSector, long numSectors)
{
HANDLE hFile;
const int SECTOR_SIZE = 512;
const int BUFFER_SIZE = 512;
LARGE_INTEGER liDistanceToMove;
PLARGE_INTEGER newFilePtr = NULL; // not used in this context.
// just reading from START to END
liDistanceToMove.QuadPart = startSector * SECTOR_SIZE;
DWORD dwBytesRead, dwPos;
LPCWSTR fname = L"\\\\.\\PHYSICALDRIVE0";
char buff[BUFFER_SIZE];
// Open the PHYSICALDEVICE as a file.
hFile = CreateFile(fname,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
// Here's the API definition
/*BOOL WINAPI SetFilePointerEx(
__in HANDLE hFile,
__in LARGE_INTEGER liDistanceToMove,
__out_opt PLARGE_INTEGER lpNewFilePointer,
__in DWORD dwMoveMethod
);*/
dwPos = SetFilePointerEx(hFile, liDistanceToMove, NULL, FILE_BEGIN);
if(ReadFile(hFile, buff, BUFFER_SIZE, &dwBytesRead, NULL))
{
if(dwBytesRead > 5)
{
BYTE x1 = buff[0];
BYTE x2 = buff[1];
BYTE x3 = buff[2];
BYTE x4 = buff[3];
BYTE x5 = buff[4];
}
}
// Close both files.
CloseHandle(hFile);
return 0;
}
startSector * SECTOR_SIZE;
startSector is a long (32bits), SECTOR_SIZE is a int (also 32bits), multiply these two guys and the intermediate result is going to be a long, which will overflow and you then stuff it into the __int64 of the LARGE_INTEGER, which is too late. You want to operate on __int64s, something like
liDistanceToMove.QuadPart = startSector;
liDistanceToMove.QuadPart *= SECTOR_SIZE;
for example.