I am using SystemState.phonesignalStrength property to fetch signal strength in my Windows Mobile Application 6.5(C#) for HTC HD 8585,
Problem With this property is that it always gives 100 value as signalstrength even if there is no sim in phone or phone is in Airplane Mode.
I my very confused what is happening.
Any Idea ,How Can i use it to fetch correct signal strength?
You can P/Invoke the RIL API function RIL_GetSignalQuality.
Alternatively, you can P/Invoke the State and Notification Broker API and monitor the SN_PHONESIGNALSTRENGTH* registry key defined in snapi.h.
I don't believe Microsoft provides access to either of these things through the Compact Framework, but there may be 3rd party libraries that do the P/Invoking for you. OpenNetCF is a good place to start.
Both of these things are, however, OEM support dependent. (Microsoft provides the interface, the OEM must implement it.)
Related
For more details, I'm using BluetoothApis.h and WinSocks2.0 as well as C++/WinRT on a win32 app. I have all the connections finished but wanted to add a check for a Bluetooth low energy (BLE) capable radio before trying to connect. Unfortunately the C++/WinRT functions don't play very nice with win32 apps. Radio.GetRadiosAsync and BluetoothAdapter.GetRadioAsync both have to be compiled to a target architecture (see "Remarks" section on either page), which in my case, has to be a 32-bit machine due to a .dll that I am using, but if those functions don't work on 64-bit machines... I'm not familiar with how 64-bit machines run 32-bit apps.
My question is this; is there a way to check if a bluetooth radio is BLE capable? I've looked through the bluetoothApis.h and found how to get radios, but I couldn't find a way to check for BLE capability. I've also looked through the bluetoothLEApis.h but couldn't find anything related to the radio itself. If anyone has an idea, do tell.
After closer inspection, I noticed that there was another member function that can create a Bluetooth object.
The BluetoothAdapter class' GetDefaultAsync() function does NOT have the same restrictions as GetRadioAsync() does. This is enough to retrieve the information on the Bluetooth low energy capabilities that I need.
I want to write a Windows application which accesses the joystick. It is just a very simple application which reads the values and sends them to a server, so I am not using any game programming framework. However, I am confused about which API to use.
I looked at the Multimedia Joystick API, but this is described as superseded by DirectInput. So I looked at DirectInput, but this is also deprecated in favour of XInput.
However the XInput documentation talks only about Xbox360 controllers, and says it does not support "legacy DirectInput devices".
Have Microsoft consigned the entire HID Joystick usage type to the dustbin and given up on supporting them in favour of their own proprietary controller products, or am I missing something?
The most common solution is to use a combination of XInput and DirectInput so your application can properly access both type of devices. Microsoft even provides instructions on how to do this.
Please note that DirectInput is not available for Windows Store apps so if you intend to distribute through there, that's not an option.
XInput devices like the XBox 360 controller will also work with DirectInput but with some limitations. Notably, the left and right trigger will be mapped to the same axis instead of being independents, and vibration effects will not be available.
In Windows 8/8.1 it's now possible to enable/disable Bluetooth via the OS itself (see image below). This is awesome because it's device/driver-agnostic.
On Android, this is possible via BluetoothAdapter.enable() and BluetoothAdapter.disable(), but I haven't been able to find anything to do this on Windows (even though it seems like it's definitely possible).
So I've tried using:
BluetoothEnableIncomingConnections() - However, this only prevents new incoming connections. It doesn't disable existing ones.
devcon.exe - The problem with this method is that A. it is a non-redistributable binary B. it requires that you know he device ID ahead of time (so it's not device/driver-agnostic). Also, while it's not a dealbreaker, it'd be nice to not require elevation.
UI Automation - Simply launching the PC Settings app and toggling the switch with keyboard events is easy, but it's super ugly, both in terms of proper coding practices and in terms of user experience. That being said, this is the only way I've found to achieve the behavior I'm looking for so far.
I'm writing a native Win32 app in C++, so I'm not constrained to any Windows Store app requirements, although, it would be great if there was an approach that didn't require elevation.
TL;DR
Are there any APIs, WMI interfaces, or anything else available to achieve functionally equivalent results to flipping the Bluetooth toggle switch? If not, are there any alternative methods which yield similar results?
In win8.1 you should be able to call BluetoothEnableRadio to enable/disable the local radio.
Basically the manufacturers should include a method to accomplish this so you don't have to load a dll.
"Beginning with Windows 8.1 vendors are no longer required to implement radio on/off capability (for Bluetooth 4.0 radios) in a software DLL as described in this topic, because the operating system now handles this functionality. Windows 8.1 will ignore any such DLL, even if present."
check out this link which talks about it:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh450832%28v=vs.85%29.aspx
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.
From what I've read online in forums and blogs, Windows Phone 7 has no support for bluetooth serial. There also does not seem to be any support for communication with accessories through USB. Can someone give me a definitive answer as to whether or not Windows Phone 7 can do any sort of command and control for external accessories? I've used bluetooth serial on Android as well as the iOS external accessory framework. I would imagine there would be some level of support for external accessory communication in the Windows Phone 7 platform.
I can confirm that there is no Bluetooth/External Accessory API exposed as part of the SDK. There may be a private API available to select parties (though I'm not familiar with any apps that do so), so it might be worth contacting Microsoft.
Keep in mind that, even if you find a private/internal API you won't be able to call it (even via reflection) and it would be caught during the certification process anyway.
If it's not possible to communicate with the accessory via Sockets/HTTP then I'm afraid you're out of luck for now.