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
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.
I'm trying to find a good GUI library I could use to create a program on the computer that connects to a microcontroller by USB. I've never done any GUI work before but I have done a lot of webpage design/tools. We are going to program the microcontroller with C but I don't think the GUI will need to be C. It needs to work on Windows, so probably compile on Windows too. I've also never done any USB transmission but I'm hoping to take it one step at a time.
Right now I'm looking at using GTK but it needs a bunch of other things to download with it. I'm also going to look at QT and someone else suggested making a Windows Forms Application. There's a lot of options out there so I'm having trouble figuring it out.
As for my requirement, it just needs to be a very simple GUI that has a few control buttons, a display area (info from microcontroller), a notification area (basically error messages go here), and maybe a graph. I've included a prototype GUI help give you an idea of what I'm doing.
Edit: It needs to run and compile on Windows. We don't really have a budget for it, free open source is preferred. I don't need something elaborate and fancy, I just want to get it done as fast as possible.
We are using a TTL-232R cable, UART interface. I know nothing about USB transmission, school has crushed me.
From what you've specified, I would set base-camp up at Java.
Java in Eclipse to write the code.
Java Swing libraries (helped by the WindowBuilder plugin for Eclipse) to "draw" the GUI. It is very easy to create "Windowsy" GUIs using these.
JFreeGraph libaries to allow you to create graphs very easily, again from within Eclipse.
RXTX library for "virtual COM port" serial communication within Java (it doesn't sound like you're using proper USB, but just RS232 with a USB adapter).
Your created GUI would run on any machine with Java installed, which is not a big ask for the end user. You can even create a Windows executable/installer from the resulting Java files if you wanted it to be a (apparently) native Windows application.
And - bonus - all the tools mentioned are free as a bird.
It will kind of depend on what kind of compiler, IDE, etc you will settle on. If you are going to windows cold, and
money is an issue, then open source is always a good thing to look at. I have enjoyed using eclipse and Code::Blocks IDEs. For C/C++, I use minGW. In terms of GUI plug-ins, HERE are some conversation with GUI recommendations specifically for use with Code::Blocks.
If money is not an issue, I have use National Instruments LabWindows/CVI full dev kit forever. It is one of the easiest ANSI C compilers/IDE I have ever used. It is only ANSI C, but has extensions to make using instrumentation easy. I have written a little USB stuff (not much), sockets, instrumentation, and many GUI apps.
Please comment what tools you currently prefer, I may have other suggestions.
Lazarus CodeTyphon has cross platform native compiler with GUI working on every supported platform. It supports 8 OS-CPU host layers (Win32, Win64, Linux32, Linux64, FreeBSD32, FreeBSD64, Solaris32 and Solaris64), and 25+ OS-CPU target layers. It also incorporates many graphical widgets and SCADA like behaviour with PascalSCADA and other components. There are wrappers for LibUSB.
I would use Microsoft Visual Studio to develop the GUI. They offer a free version called Express. I would use the C# language but MSVS supports other languages as well so just choose whichever you're most comfortable with. The best thing about MSVS is that there are millions of developers out there, which means that you will be able to search for and find lots of examples for how to use an RS-232 COM port or USB interface. I'm guessing that you'll be able to find GUI objects for graphing and other objects as well. (The basic stuff like buttons and edit boxes is all built into MSVS.)
BTW, you need to sort out whether you're using an RS-232 COM port or a USB interface. They're both serial interfaces but they're not the same thing. Either could work.
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.
I have some ideas for improvements on my touchpad, ranging from the run of the mill scroll horizontally at the bottom, tapzones for right click, to more complicated ones. But I have no idea where to get started? I'm working on Windows 7 Home Premium, its an Asus laptop, and I have none of these options natively available to me. Regardless, I want to write something that anyone can use.
Where would I start?
(it'd be nice to write in c++? is that possible? what are the requirements here? what language would be recommended?)
This is dependent on the hardware and driver for the touchpad. Just because Windows 7 supports gestures and multitouch doesn't mean that your touchpad does automatically; assuming that the hardware supports it (doubtful), the driver has to be specifically updated to support it as well.
If you have none of the options available natively, you won't automagically get them just by upgrading to Windows 7.
If you plan on writing software that supports gestures or multitouch, you have no real option other than investing in the hardware as well. After all, how will you test your software without it?
Scrolling functionality such as you describe is handled in touchpad drivers, which are hardware specific. However, you may be able to accomplish what you want by using a hook. This is a mechanism by which you intercept and pre-process system messages before they're sent to applications. This could allow you to designate some areas of the touchpad for extra functionality without having to write a driver. But you're probably better off seeing if there is an existing driver with the functionality you want available from the ASUS site. If your laptop didn't come with Windows 7 originally, you're probably just running a generic driver and an actual touchpad specific driver might fix your problem.