Using C++ VS2017 Win10...
I am testing some code to set a characteristic value on a BLE device. I had originally had the default function call
HRESULT hr = BluetoothGATTSetCharacteristicValue(
hBleService.get(),
_pGattCharacteristic,
gatt_value,
NULL,
BLUETOOTH_GATT_FLAG_NONE);
I had to switch the flag to BLUETOOTH_GATT_FLAG_WRITE_WITHOUT_RESPONSE to get any sets to take place even though IsWritable and IsReadable were the only 2 properties set showing true but that is a different story and another topic.
Anyway, before I found the problem with the flag I had tried to use the ReliableWriteContext parameter so the code changed to
HANDLE hDevice = _bleDeviceContext.getBleDeviceHandle();
BTH_LE_GATT_RELIABLE_WRITE_CONTEXT ReliableWriteContext = NULL;
HRESULT hr1 = BluetoothGATTBeginReliableWrite(hDevice,
&ReliableWriteContext,
BLUETOOTH_GATT_FLAG_NONE);
HRESULT hr = BluetoothGATTSetCharacteristicValue(
hBleService.get(),
_pGattCharacteristic,
gatt_value,
ReliableWriteContext,
BLUETOOTH_GATT_FLAG_WRITE_WITHOUT_RESPONSE);
if (NULL != ReliableWriteContext) {
BluetoothGATTEndReliableWrite(hDevice,
ReliableWriteContext,
BLUETOOTH_GATT_FLAG_NONE);
}
Once I fixed the flag issue my BluetoothGATTSetCharacteristicValue() function would work with either the NULL or the ReliableWriteContext parameters. No difference that I could see.
My question is,then, what does the ReliableWriteContext do exactly? MS docs only say:
The BluetoothGATTBeginReliableWrite function specifies that reliable
writes are about to begin.
Well that doesn't tell me anything. So should I keep the reliable writes because the word "Reliable" sure sounds like it is something that I want? Or do I not use it because it does not seem to be necessary>
Any insight would be appreciated.
Ed
Related
Based on what I can find on the internet this doesn't seem to be something a lot of people do but I'm pretty stuck so I'm going to put it out here. I'm using WMI in C++ to try to manipulate SQL Server settings. I have the following code that doesn't return a result from my WMI query and I'm at a loss as to why:
hr = pLoc->ConnectServer(CComBSTR(L"root\\Microsoft\\SqlServer\\ComputerManagement10"), // Object path of WMI namespace
NULL, // User name. NULL = current user
NULL, // User password. NULL = current
0, // Locale. NULL indicates current
NULL, // Security flags
0, // Authority (e.g. Kerberos)
0, // Context object
&pSvc);
// ----- Check for success and set proxy blanket here -----
IEnumWbemClassObject* pClassEnum = 0;
hr = pSvc->ExecQuery(_bstr_t("WQL"), _bstr_t("SELECT * FROM FilestreamSettings"),
WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY,
NULL,
&pClassEnum);
if (SUCCEEDED(hr) && pClassEnum)
{
ULONG uReturn = 0;
while (pClassEnum && !myInstanceFound)
{
hr = pClassEnum->Next(WBEM_INFINITE, 1, &pObjInstance, &uReturn);
if (0 == uReturn || !pObjInstance)
{
break;
}
// Get the value of the InstanceName property - the SQL Server instance name
CComVariant vtProp;
hr = pObjInstance->Get(L"InstanceName", 0, &vtProp, 0, 0);
if (SUCCEEDED(hr) && (VT_BSTR) == vtProp.vt)
{
if (vtProp.bstrVal == _bstr_t('MyInstance'))
{
myInstanceFound = true;
}
}
}
.
.
.
}
The ExecQuery command succeeds. The pClassEnum enumerator object is not null, so the while loop executes. The call to 'Next', however, does not return an object (pObjectInstance is null) and &uReturn is 0 (which, as I understand it means that the call to 'Next' returned 0 results). However, if I run the same query in the wbemtest tool, I get two results (which is correct, as I have 2 SQL Server instances on this machine). I have limited C++ skills and this is my first time with WMI. Not only do I not see what's wrong here, I'm not even sure what else to try. The few code samples I've seen suggest this code should be correct. Any help would be greatly appreciated!
Thanks,
Dennis
Update: The call to Next() actually returns S_FALSE. Which, if I'm reading the docs correctly, mostly just confirms the issue of not getting a result. Next() returns S_FALSE if there are less than the number of requested results (in my case, less than 1 - or in other words, 0).
Update #2: This same code does work on my laptop (well, the Next() call does anyway). Differences are: Does work on my laptop - Win 10, Sql Server 2019 (have to change namespace to be ComputerManagement15 instead of 10), FileStream already enabled. Does not work - Win 7 VM, Sql Server 2008, FileStream not enabled. A query using Wbemtest tool gets the correct data in both cases. Just thought I'd post in case this helps.
FYI, in case anyone stumbles across this: I didn't technically solve this, in that I never got my C++ code to work. I wrote some C# code using SQL Server Management Objects (basically a wrapper over WMI) and made it into a COM server that I could call from C++. Even this didn't work directly because my C# COM server kept getting an "Access Denied" even if I ran the C++ COM client application as Administrator. What eventually worked was to extract the SSMO code out into its own C# console app which I then ran from my C# COM server as its own process using the "run as" verb so it would run as Administrator. This finally managed to enable Filestream on my SQL Server instance. It's possible there was a better/easier way to get this done but I found something that worked (although it was pretty kludgy). So if there's a chance this helps anyone else, I'm putting it out there.
Going back to the days of Windows XP one could use the following code to tell if there's no file association existed for an extension:
TCHAR buffPath[MAX_PATH] = {0};
DWORD dwszBuffPath = MAX_PATH;
HRESULT hR = ::AssocQueryString(
ASSOCF_NOFIXUPS | ASSOCF_VERIFY,
ASSOCSTR_EXECUTABLE,
_T(".weirdassextension"),
NULL,
buffPath,
&dwszBuffPath);
if(hR != S_OK &&
hR != E_POINTER)
{
//Association does not exist
}
But since Windows 8, the AssocQueryString API returns S_OK and buffPath is set to something like C:\WINDOWS\system32\OpenWith.exe if it doesn't find anything.
Is there a better way now to determine that file extension has no Shell association?
PS. I do not want to just compare the file name to OpenWith.exe. What if there's a legit executable called just that... There must be a better way.
I think I got it. The trick was to use the correct flags. This seems to work from XP and up:
WCHAR wbuffPath[MAX_PATH] = {0};
DWORD dwszBuffPath = MAX_PATH;
HRESULT hR = ::AssocQueryStringW(ASSOCF_INIT_IGNOREUNKNOWN,
ASSOCSTR_EXECUTABLE,
L".weirdassextension",
NULL,
wbuffPath,
&dwszBuffPath);
if(hR == 0x80070483) // HRESULT_FROM_WIN32(ERROR_NO_ASSOCIATION)
{
//The association is missing
}
There's one other trick there, that took me some time to figure out -- DO NOT use AssocQueryStringA(). The shim for AssocQueryStringA() that converts its passed string parameters to Unicode has a bug in XP (and evidently in Vista as well) that will make that API fail on those OS. So, if you do your own ANSI-to-Unicode conversion and call AssocQueryStringW() the problem will go away (Evidently 14 years is not enough time for Microsoft to fix that bug?).
If I use windowed activation (giving a valid HWND to the Flash PLayer in the GetWindow function is enough to trigger this), the player will run the loaded swf file. However, if I use windowless activation, the loaded file does not run, only the very first frame is displayed. This article claims that I'm supposed to call
DoVerb(OLEIVERB_SHOW, NULL, (IOleClientSite *)this, 0, NULL, NULL);
However, this does not have any effect. What am I doing wrong?
Edit: Since I made this post, I found out that it returns -2147467259, which is not a known HRESULT, but certainly not 0. What does it mean?
After some more digging I found out that the return value is OLE_E_NOTRUNNING.
I have found the problem. Before this call, I was doing:
hr = _shockwaveFlash->put_WMode(BSTR("opaque"));
BUT I blatantly ignored the HRESULT there. It made the Flash Player confused, because it is not a valid way to insert a BSTR constant in the code (which is a wide string). Correctly:
hr = _shockwaveFlash->put_WMode(L"opaque");
Now it works as it should. Check you HRESULTs, kids :)
In C++, I have opened a serial port that has a HANDLE. Since the port may close by an external application, how can I verify that the HANDLE is still valid before reading data?
I think it can be done by checking the HANDLE against a suitable API function, but which?
Thank you.
Checking to see whether a handle is "valid" is a mistake. You need to have a better way of dealing with this.
The problem is that once a handle has been closed, the same handle value can be generated by a new open of something different, and your test might say the handle is valid, but you are not operating on the file you think you are.
For example, consider this sequence:
Handle is opened, actual value is 0x1234
Handle is used and the value is passed around
Handle is closed.
Some other part of the program opens a file, gets handle value 0x1234
The original handle value is "checked for validity", and passes.
The handle is used, operating on the wrong file.
So, if it is your process, you need to keep track of which handles are valid and which ones are not. If you got the handle from some other process, it will have been put into your process using DuplicateHandle(). In that case, you should manage the lifetime of the handle and the source process shouldn't do that for you. If your handles are being closed from another process, I assume that you are the one doing that, and you need to deal with the book keeping.
Some WinAPI functions return meaningless ERROR_INVALID_PARAMETER even if valid handles are passed to them, so there is a real use case to check handles for validity.
GetHandleInformation function does the job:
http://msdn.microsoft.com/en-us/library/ms724329%28v=vs.85%29.aspx
as the port may close by a external application
This is not possible, an external application cannot obtain the proper handle value to pass to CloseHandle(). Once you have the port opened, any other process trying to get a handle to the port will get AccessDenied.
That said, there's crapware out there that hacks around this restriction by having secret knowledge of the undocumented kernel structures that stores handles for a process. You are powerless against them, don't make the mistake of taking on this battle by doing the same. You will lose. If a customer complains about this then give them my doctor's advice: "if it hurts then don't do it".
If you are given a HANDLE and simply want to find out whether it is indeed an open file handle, there is the Windows API function GetFileInformationByHandle for that.
Depending on the permissions your handle grants you for the file, you can also try to move the file pointer using SetFilePointer, read some data from it using ReadFile, or perform a null write operation using WriteFile with nNumberOfBytesToWrite set to 0.
Probably you are under windows and using ReadFile to read the data. The only way to check it is trying to read. If the HANDLE is invalid it'll return an error code (use GetLastEror() to see which one it is) which will probably be ERROR_HANDLE_INVALID.
I know that it's a little bit late but I had a similar question to you, how to check if a pipe (a pipe I created using CreateFile) is still open (maybe the other end shut down the connection) and can read, and if it is not, to open it again. I did what #Felix Dombek suggested, and I used the WriteFile to check the connection. If it returned 1 it means the pipe is open, else I opened it using the CreateFile again. This implies that your pipe is duplex. Here's the CreateFile:
hPipe2 = CreateFile(lpszPipename2, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_FLAG_WRITE_THROUGH, NULL);
and here is how I checked for the connection:
while(1)
{
bool MessageSent = WriteFile(hPipe2, "Test", 0, &cbWritten, NULL);
if (!(MessageSent))
{
LogsOut("Read pipe has been disconnected");
//Call method to start the pipe again
break;
}
Sleep(200); // I need this because it is a thread
}
This is working just fine for me :)
You can use DuplicateHandle to test handle validity.
First method: You can try to duplicate the handle you want to check on validity. Basically, invalid handles can not be duplicated.
Second method: The DuplicateHandle function does search the Win32 handle descriptor table from beginning for an empty record to reuse it and so assign into it a duplicated handle. You can just test the duplicated handle address value on value greater than yours handle address and if it is greater, then the handle is not treated as invalid and so is not reused. But this method is very specific and limited, and it does only work, when there is no more empty or invalid handle records above the handle value address you want to test.
But all this just said above is valid only if you track all handles creation and duplication on your side.
Examples for Windows 7:
Method #1
// check stdin on validity
HANDLE stdin_handle_dup = INVALID_HANDLE_VALUE;
const bool is_stdin_handle_dup = !!DuplicateHandle(GetCurrentProcess(), GetStdHandle(STD_INPUT_HANDLE), GetCurrentProcess(), &stdin_handle_dup, 0, FALSE, DUPLICATE_SAME_ACCESS);
if (is_stdin_handle_dup && stdin_handle_dup != INVALID_HANDLE_VALUE) {
CloseHandle(stdin_handle_dup);
stdin_handle_dup = INVALID_HANDLE_VALUE;
}
Method #2
// Assume `0x03` address has a valid stdin handle, then the `0x07` address can be tested on validity (in Windows 7 basically stdin=0x03, stdout=0x07, stderr=0x0b).
// So you can duplicate `0x03` to test `0x07`.
bool is_stdout_handle_default_address_valid = false;
HANDLE stdin_handle_dup = INVALID_HANDLE_VALUE;
const bool is_stdin_handle_dup = !!DuplicateHandle(GetCurrentProcess(), (HANDLE)0x03, GetCurrentProcess(), &stdin_handle_dup, 0, FALSE, DUPLICATE_SAME_ACCESS);
if (is_stdin_handle_dup && stdin_handle_dup != INVALID_HANDLE_VALUE) {
if (stdin_handle_dup > (HANDLE)0x07) {
is_stdout_handle_default_address_valid = true; // duplicated into address higher than 0x07, so 0x07 contains a valid handle
}
CloseHandle(stdin_handle_dup);
stdin_handle_dup = INVALID_HANDLE_VALUE;
}
In order to check the handle , first we need to know what is our HANDLE for, (for a File/Port/Window, ...), Then find an appropriate function to check it (thanks #janm for help). Note that the function's duty may be specially for this destination or not. In my case that iv'e opened a Serial port by CreateFile() , i can check the COM status by GetCommState() API function that fills our COM info struct. If the port is not open anymore or inaccessible the function returns 0 and if you call GetLastError() immediately, you`ll get the ERROR_INVALID_HANDLE value. Thanks everyone for helps.
I am looking for a clean way to check if a registry key exists. I had assumed that RegOpenKey would fail if I tried to open a key that didn't exist, but it doesn't.
I could use string processing to find and open the parent key of the one I'm looking for, and then enumerate the subkeys of that key to find out if the one I'm interested in exists, but that feels both like a performance hog and a weird way to have to implement such a simple function.
I'd guess that you could use RegQueryInfoKey for this somehow, but MSDN doesn't give too many details on how, even if it's possible.
Update: I need the solution in Win32 api, not in managed code, .NET or using any other library.
The docs in MSDN seem to indicate that you should be able to open a key for read permission and get an error if it doesn't exist, like this:
lResult = RegOpenKeyEx (hKeyRoot, lpSubKey, 0, KEY_READ, &hKey);
if (lResult != ERROR_SUCCESS)
{
if (lResult == ERROR_FILE_NOT_FOUND) {
However, I get ERROR_SUCCESS when I try this.
Update 2: My exact code is this:
HKEY subKey = nullptr;
LONG result = RegOpenKeyEx(key, subPath.c_str(), 0, KEY_READ, &subKey);
if (result != ERROR_SUCCESS) {
... but result is ERROR_SUCCESS, even though I'm trying to open a key that does not exist.
Update 3: It looks like you guys are right. This fails on one specific test example (mysteriously). If I try it on any other key, it returns the correct result. Double-checking it with the registry editor still does not show the key. Don't know what to make of all that.
First of all don't worry about performance for stuff like this. Unless you are querying it 100x per sec, it will be more than fast enough. Premature optimization will cause you all kinds of headaches.
RegOpenKeyEx will return ERROR_SUCCESS if it finds the key. Just check against this constant and you are good to go.
RegOpenKey does return an error if the key does not exist. How are you using it? The expected return value is ERROR_FILE_NOT_FOUND.
From your code:
HKEY subKey = nullptr;
LONG result = RegOpenKeyEx(key, subPath.c_str(), 0, KEY_READ, &subKey);
if (result != ERROR_SUCCESS) {
I would look at the value of key and subPath and make sure they are what you expect, and that the key does not actually exist. What is the value of subKey afterwards? It is obviously opening something - try enumerating it to see what the keys and values under it are.
There is no issue with RegOpenKey not returning an error if the key does not exist - I would not try to assume there is some kind of weird OS bug in something as commonly used as the registry.
Maybe you have a registry key that is not visible to you, the user that is running the registry editor, but not to your code? A permissions problem perhaps? Is your code running as an elevated user in windows Vista or server 2008? Did you try running the registry editor as administrator?
Note that beside the "core" Registry functions that start with "Reg" there are also helper functions starting with "SHReg". These are intended for use by the Shell i.e. Explorer but are documented and can be used in normal applications too. They're typically thin wrappers that make some common tasks easier. They're part of the "Shell LightWeight API" (shlwapi.dll)