See my answer at Widcomm bluetooth: how to open the virtual COM for my. So, use WMI to find the current COM ports in place and see if any of them are for. With Windows 10, can't open any Bluetooth virtual com ports. Our devices use a serial port (SPP) service on Bluetooth. Windows automatically creates the serial ports when pairing the devices. The devices pair well and the necessary virtual serial ports are created. They all look great but on both computers, no software is able to.
Just an update for anyone who follows in my steps (though the quagmire.) I have worked out a method using the registry that scans 'SYSTEM CurrentControlSet services BTHPORT Parameters LocalServices' and builds a list using the ServiceName, enabled, and AssocBDAddr keys. From there I build a path string with the BT address and scan for it under the ' SYSTEM CurrentControlSet Enum BTHENUM ' I iterate though all of the subkeys (backwards) until I find a portName string key under a path that contains the BT address in part. I need to go backwards due to the fact windoes doesn't always remove the last key when the Bluetooth device parameters are changed or reinstalled. But it does seem to add the latest info after the old stuff. At this point I have all for the past connections. The last step is the find which comports are currently active by polling 'HARDWARE DEVICEMAP SERIALCOMM' the TRegistry object bug reported under is still there as of FPC 2.6.4.
This is where the StringSizeIncludesNull must be set false for this last step to return the full comport string. You may not have this issue with later FPC as the bug is reported as fixed. This code did not work for WIN8. It may be the WMI is the way to go but I do not have an interface for it at this time.
The tools I've tried don't let you search for an answer without knowing the class it is stored in before hand. no solution yet.
Is there a way to retrieve the USB path along which a USB flash drive is connected to? For example: in form of: USBFlashDrivePort(=ExternalHubPortIndex)-ExternalHubIndex(=RootPortIndex)-USBControllerIndex(=RootHubIndex) The reason I am asking is because I need to physically identify the USB flash drive when Windows report problem such as ‘this device can run faster if plugged in a high speed port’ or something like that. I sometimes plug in more than 20 USB drives (through hubs, of course) for file distribution purposes. When Windows report a delayed write failed to a drive there is no way to know which physical drive it is refering. Is it possible at all?
I’m using WMI for the first time and have seriously scratched my head at some things. Per default, whenever something is weird I assume that I’m not getting it.
But after seeing this page I’m convinced WMI is badly designed. Why is it necessary to do all this fancy extraction of DeviceID, replacing quotes, taking the thing after the = sign etc. Why isn’t there simply an attribute giving the DeviceID that you can use to do a simple query right after to get the device you are looking for. All the other stuff seems like something that is unstable if Microsoft ever changes the format of the 'Dependent' or whatever and it is a total waste of code. It really amazes me how Microsoft could design a 'modern' API like this (it gets really ugly when you look at Win32DiskDrivePhysicalMedia the sole purpose of which is to link Win32DiskDrive to Win32PhysicalMedia – which you can only take advantage of by doing the above weird parsing of the dage).