Change default audio device on Windows 7 - c#

I want to be able to change the default audio output device on Windows 7 programatically using C# (and probably some underlying Win32 API calls, as well). I've already done my homework, and I've heard a lot of mixed comments from different sources, so I wanted to ask this question again to get a straight answer. Is this actually possible (through any means)? If so, how would I go about doing this?
And please do not suggest a solution with "AutoIt" or some other similar program... this is a C#/.NET-specific question.

A little up-to-date answer, which is compatible with Windows 10.
This program is able to do it in a beautiful manner (hotkey to switch between pre-selected devices) and is written on C# :
SoundSwitch on GitHub
Some reverse engineering should get you there (for my use this program was just perfect as it is).
It makes use of that library (same author) which is in C++ :
AudioEndpointLibrary on GitHub
So if you know C++ (which I don't enough), you might go further in the analysis of how it works. Or just use the library like SoundSwitch does.

Just in case anyone stumbles across this thread in the future... here's some C++ code that'll do it by calling some undocumented Win32 APIs. This can be compiled into an EXE and then called silently from a .NET application, so you could build a .NET program around this code.
http://web.archive.org/web/20190317012739/http://www.daveamenta.com/2011-05/programmatically-or-command-line-change-the-default-sound-playback-device-in-windows-7/

Related

Experience/Examples using Nordic nRF52840 (BLE) with C#?

Does anyone have experience using the Nordic NRF52840 with a C# app to act as a receiver?
I'm trying to communicate with an Onset InTemp thermometer and although I've had quite a bit of success with the native Windows 10 BLE, I'm having some problems. See: C#, BLE. Why does GetGattServicesAsync hang forever? Is there a work around such as turning off/on BLE? for details.
Nordic advertises that they only have C++, Python and Node.js libraries. See https://devzone.nordicsemi.com/f/nordic-q-a/65516/using-nrf52840-dongle-as-receiver-client-for-onset-thermometer for example. I need either a C# library OR perhaps some hints on how to build the C++ library with Visual Studio (there are no instructions that I can see) and setup the interop layer (method signature etc.). I think this would go much faster if I saw an example :). And I'm guessing this type of work has been done before.
Another possibility is to call the Node.js libraries from C# which I understand is possible but again, I'd need some initial examples. Probably more so as I've never used Node.js either on its own or from C#.
Thanks, Dave

GetVersionEx() is deprecated: should I use Environment.OSVersion?

I am intending to write code to determine if the OS is Windows XP, so I can set the LOCALAPPDATA environment variable to work-around a whole load of code which uses ExpandEnvironmentVariables() heavily.
To make it even more fun, some code is written in VB6, and some code is written in C# 4.0 . Looking at the documentation for GetVersionEx(), there are strong suggestions that this API call will be deprecated from Windows 8.1 onwards. But no problem, there is a different set of API calls (VerifyVersionInfo / VerSetConditionMask) I can use. With VB6, there is no choice - I have to use the API call.
However, with my C# code, there appears to be no obvious equivalent. There is Environment.OSVersion, but this seems to be a hacked together set of data from disparate sources, and there isn't anything with the subtlety of the VerifyVersionInfo() API.
Is there a wrapper for this API call. If not, should I bother implementating it myself?
[Added]
Or otherwise, maybe someone might have some internal information about how the Environment.OSVersion is implemented?
First of all it is important to understand what Deprecated means. It means that the function either is critically broken (such as some early threading), or that it's been superseded (replaced) with new functionality. In this case it is the latter.
From the documentation on GetVersionEx function there is a link suggesting to use Version Helper APIs instead.
One part of this page is specifically important:
Note These APIs are defined by versionhelper.h, which is included in
the Windows 8.1 Preview software development kit (SDK). This file can
be used with other Microsoft Visual Studio releases to implement the
same functionality for Windows versions prior to Windows 8.1 Preview.
It's perfectly fine to use GetVersionEx. It won't be removed from Windows for a very long time, if ever. Microsoft has a long track record of maintaining compatibility with old programs. For example, you can still call the Win16 APIs that were deprecated 20 years ago.
I added an additional part to my original question about whether anybody knew about the internals of the Environment.OSVersion object. After searching around this site for a few minutes, I found this question:
How to detect Windows 64-bit platform with .NET?
Now, the "official" answer itself wasn't very interesting to me, but the second answer from Phil Devaney mentioned an application called "Reflector" that appeared to do some sort of magic. So I downloaded it, and blow me down, I was able to decompile the P-Code for the Environment.OSVersion object's constructor:
Win32Native.OSVERSIONINFO osVer = new Win32Native.OSVERSIONINFO();
if (!GetVersion(osVer))
{
throw new InvalidOperationException(GetResourceString("InvalidOperation_GetVersion"));
}
So that's it: Environment.OSVersion internally uses GetVersion, a function which might not behave itself in future days. Looks as if VerifyVersionInfo and P/Invoke is the way to go on this one.
I will now have to download .NET 4.5 on a different machine and see if that implementation is any different.
Mark)
Maybe it will interesting for you GetVersionExEx
But please note that VerifyVersionInfo may also be deprecated in later releases of Windows OS (as stated by ms tech guy in msdn social forum).
This code depends on VerifyVersionInfo and provides same usage experience. Also bisection algo was used in code.
Version Helper API for requests to API, this code for exact values.
Thanks)

Code in C# and build into cross platform binaries? (iOS and Android)

As the question states, I am wondering if anyone is familiar with the ability to code in C#, and compile into IOS or Android native app-compatible binaries.
I know that Mono might be the answer here, but have never used it, and haven't seen anything around that allows me to take c# code and spit out seperate binaries, one of which would be compatible with IOS and on one with Android. Any thoughts?
I also know of Xamerin.iOS and Xamerin.Android, however these solutions look to be end to end solutions. I only want to code similar 'backend-ish' logic once, and give it to app developers to implement their native apps and just use the binary when necessary. I do not want the App to be cross platform built, just a simple logic binary in the back :)
Let me know if this is unclear, and I will try to be more clear :)
--EDIT: This is resolved as can't be done, as per the marked answer (and comments). Thanks!
You could have a look at MonoCross. But Xamarin's offerings really are second to none if you want to write Android/iOS apps in C#.

Interoperation and CRL Activity

I hope that question would not mess with StackOverFlow FAQ rules
So ,when using Libraries which are written in C++ for example ,and that means we have some Code in these DLL's which is going to be executed ,when Software execution cames in that case ,will this Portion of code be executed by CLR ?
I need that because we plan to develop a Software and some Angry Algorithms i think will be better to program them in C++ ,but Visual C# serves us some tools that we cant find in c++ (Linq ,Anonymous etc) .
You can use DLLs created in C++ inside your C# project, and as you already know you have to make an interop call. This switches context to unsafe, so the code is probably executed outside the CLR. This means that you lose the portability options the CLR gives you. For example a C# based app would run on Windows and Windows Phone, but adding interop calls will only make it work on Windows (or whatever system the DLL was compiled for).
But normally this isn't much of an issue.
Also see this thread: http://forums.devshed.com/net-development-87/using-a-c-dll-in-c-107829.html

Writing my own custom command line "wrapper" for windows

I have never been a fan of the windows command line. I have tried tools like powercmd and liked them, but most are not distributed for free and I don't relish the thought of paying for something that I think I could write myself. I want to write my own command line wrapper similar to powercmd that allows for these properties:
Custom fonts and colors
Opacity of windows
Multiple windows opened at same time in a panel (maybe like tabbed browsing)
Ability to resize windows
I am reaching out to you guys now to help me decide on whether I should attempt this with C# in visual studio or whether I should do it in Java with Swing. I am comfortable with both. Has anyone ever done a command line wrapper like this? If so what language did you use and what was your experience? Thanks for any feedback.
Grant-
If you want to do a windows command line, I would recommend C#. Java's enforced platform independence will make you fight too much to pass along commands to the underlying OS.
There's already Console2 that hits the big bullet points - resizable, opacity, tabs, modifiable fonts.
It's written in C++ and under the hood it wraps cmd.exe (or whichever command shell you tell it to use) so those may be two strikes against it if you're really interested in developing your own shell in a managed language.
Since you asked, I wrote one myself in C# - the Process class is just too useful. The main thing here is I/O redirection. While I never managed it fully myself, you need this so that subprocess output doesn't appear in another console window. You can also kill programs, find existing ones, etc.
Also, C#'s Console manipulation is very handy.
While I am not a Java programmer, I can imagine that both of those important features would be quite hard to use, considering that Java is platform-independent.
C# has several benefits over Java for this type of project, not the least of which is better integration with Windows, which is (presumably) the only platform you're developing this for. The Java Swing library is not nearly as fine-tuned looking on windows machines as C# forms tend to be, and with the ability to use WPF, C# seems the clear winner to me.
I would not use Java and Swing for this. C# will let you communicate directly with the .Net framework and allow you the ability to build a more powerful command line tool. IT will be a hassle to get Java access to some Windows System calls.
Just wanted to let you all know that I did end up writing a command line wrapper with C#. It turned out really well. I have a couple more little things I want to add and then I will put up the source code as well as a place to download the .exe. I posted a video of it in action in case anyone wanted to provide feedback or ideas. Thanks for the help.
http://www.youtube.com/watch?v=-NM-XcYwLDc

Categories

Resources