I want to make a control that handles user input, so I want to be able to handle different keyboards, and one of the ways is using IME.
If you don't handle it, there is a floating window that appears when you have IME active (for example japanese writing active). I found the messages that needs to be taken care of, but I don't know how to send the keys I'm trapping to the IME and when do I get a valid converted char.
I'm a Microsoft SDE that used to maintain the (Windows and Office) Korean IME for a while...
Unfortunately the best IME API documentation is provided by non-Microsoft sites:
IME programming sample (very well commented code!) from Google's Chrome browser
ime_input.h
ime_input.cc
Win32 Multilingual IME Overview for IME Development (Archived)
Win32 Multilingual IME Application Programming Interface (Archived)
(To Microsoft's credit, these last two used to be part of the Windows Driver Development Kit)
Here is the official Microsoft documentation: Input Method Manager (MSDN)
There is also a new, more advanced IME based on the Text Services Framework (TSF) that Microsoft would prefer you to use, but it's even more complicated and the old API is emulated pretty well. If you don't need any of the advanced features (like input via tablet/voice recognition/fancier IME/etc) then using the old API is sufficient.
The best documentation on the Text Services Framework is the TSF Aware Blog written by another Microsoft dev. Eric Brown may even personally answer your questions if you go this route.
Here is the official Microsoft documentation for TSF: Text Services Framework (MSDN)
One feature of TSF you may find useful is the ability to suppress rendering of the IME (needed for full screen games that need to render the IME themselves, for example). Simply tell TSF that your app will render the IME GUI, then implement an empty rendering method: UILess Mode Overview (MSDN)
I don't think that you want to supress an IME from being displayed. I've never used one other than for testing, but it's my understanding that an IME is the expected/default way of entering non-English characters using an English keyboard.
If you are writing a control and want to fully support an IME, I think the two options that you have are to respond to the various Windows messages (like WM_IME_START_COMPOSITION, WM_IME_COMPOSITION, etc.) or use Text Services Framework (TSF). It's my understanding that TSF is the future, and in Vista and Windows 7 all of the IME code is based off of TSF, with the Windows messages still there for compatibility with old programs.
Related
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
Some articles point to Windows 8 development being HTML-based instead of primarily using native code like C or C++ (as it has been until now) or .NET (as now, or even more so as it would have been in Longhorn, but never was.)
Is this true? Will the core APIs be accessible from Javascript then? What is the primary API / framework for Windows 8?
This is worth asking. When Windows 8 was demonstrated in June, a couple of comments by the presenter scared quite a few developers - or at least turned the Internet into panic mode. I'm surprised this question hasn't been asked here before.
The best article on the topic I have found is Windows 8 for Software Developers on Ars Technica.
The short answer is: it will remain the same.
The long answer is: it will remain the same, but several things will be added. You may want to pursue using those if you're willing to bet on new Microsoft technologies. One particularly interesting one is WinRT, which is a new object-oriented native code API exposed through COM, which is supposed to be a new version of the old flat Win32 API. Details are in the linked article.
It is very, very, very, very unlikely that anything that already exists, especially based on Win32 or .Net, would be removed. That means your existing programs written in .Net or native C++ or Delphi will continue to work fine. It is also unlikely that the primary development platform will be HTML. More likely is that HTML applications will be encourage for specific scenarios - perhaps touchscreen, kiosks and tablets.
I'd encourage you to read the article I linked to above - it covers this in far more detail than any answer here can.
There are three ways to develop for Windows 8, and they all access the same underlying API, the Windows Runtime.
Use C++ and call WinRT functions much like calling Win32 APIs back in the day (you know, yesterday)
Use C# or VB and call what appear to be .NET methods (but aren't)
Use Javascript and call WinRT functions
The UI is built with XAML using a pretty reasonable designer. More details are still coming out: check http://channel9.msdn.com/Events/BUILD/BUILD2011 for videos with detailed coding demos. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 is not a bad starting point.
There are 3 language/framework combinations that are all equally supported:
C++ and XAML
C#/VB and XAML
JavaScript and CSS/HTML
All are first class ways to write Windows 8 Metro style applications. Windows Runtime provides direct access to each of these languages and so choice of development environment can be based on familiarity or feature set of the language and not on restricted availability.
Update: I forgot one: C++/Direct3D (for games).
The original quote, in the context of writing a tablet desktop weather gadget application, is that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."
The demonstrator never said a gadget is the preferred type for applications (How many Vista sidebar gadget or Windows 7 desktop gadget have you written in your life? Even when you can write them in simple HTML!), or the platform is the preferred platform for desktop weather gadget applications (How many animation control have you add to your application with video playing requirement? It is THE control used by Windows Explorer to display video!).
Today, after spending a few minutes playing with Windows 8 developer preview, I found that you can use Expression Blend 5 to easily auto-generate metro-styled applications in HTML and Javascript. Also in Visual Studio you can create exactly looking applications in Silverlight. :)
I am very excited!!! Go Windows 8! :)
What GUI toolkit does Valve use for Steam? Is it Qt? I am interested in using the same toolkit for a project.
According to Valve itself:
"VGUI is Valve's proprietary Graphical User Interface. All Source and Steam applications use VGUI to draw windows, dialogs and menus. It also handles localization: the displaying of text in the user's preferred language. "
That's interesting, maybe if you guys do some research you can have it working in your programming language. I'll download the SDK to see if I can make it work with Java :)
http://developer.valvesoftware.com/wiki/VGUI_Documentation
Having had experience with the Source engine I know that Valve have an library called VGUI which they use for all their games and many of their tools (when in game the library sits on top of the Source renderer, when in tools it sits on top of the Windows API I believe). Although I can’t answer the question with 100% certainty I suspect that this is what they use for Steam as well (I seem to recall some Steam updates that mentioned VGUI) – I would be surprised if the new beta uses a different library.
Even if it is not using VGUI, given what I know of Valve I would think they will have written something else entirely in-house.
So, it is (almost certainly) proprietary and highly unlikely to ever be available for third party use (unless you have the funds to buy a Source engine license).
Steam only runs on Windows and predates QT for Windows, so I'd have to guess something else.
Since Steam has had the same GUI since 2003, chances are it uses some variant of MFC. It also uses an embedded Internet Explorer web browser for its Store and Community sections.
However, I can't give any guarantees about what the version currently in Beta uses. It looks quite a bit different and includs the Webkit rendering engine instead of using IE. It may use Webkit for everything rather than drawing their own GUIs.
Does this answer the question?
http://games.slashdot.org/story/10/02/25/0640233/Steam-UI-Update-Beta-Drops-IE-Rendering-For-WebKit
OK, so we're writing our MFC application to make use of the built-in localization support with satellite DLL's since MFC 7. Everything seem to be working fine, except that my Windows 7 Enterprise Edition install with MUI support and using a Swedish UI instead of an English UI still displays the English UI in our application.
The application uses Swedish as its default language, with an English localization DLL in the form AppNameENU.dll, so MFC is actually intentionally switching to English language under these circumstances, as if it's not caring for the user choice in the MUI-enabled Windows OS, and only the default shipping language of the Windows install?
From the MSDN page on this (the link above), I read it as MFC should actually take these settings into account though, but I'm not 100% sure. Can someone please clarify?
It's because the MFC support for language selection has a design bug: It will decide to load resources from the exe only if no DLL match user OR system language.
In your case: It sets up its (ordered) list of languages as such:
Swedish (User language)
English (System language)
Then it looks up your DLLs (Bug: only the dlls, not the exe!): No match for Swedish. But there's a match for English!
Solution: Use my CLanguageSupport class. It works fine even in your use case.
Feel free to use it. You'll need only a couple of minutes to incorporate it into your app and it uses the exact same DLL scheme as the one you already implemented. (Hint: Don't forget the step where you must get rid of the CWinApp::InitInstance() call!)
In addition, if you are interested (this is optional), you can get an automatic languages menu to let user pick his own preference in case the default is not what he wants.
And if you're looking for a great tool to help you manage your translations, think appTranslator ;-)
HTH,
my primary language is spanish, but I use all my software in english, including windows; however I'd like to use speech recognition in spanish.
Do you know if there's a way to use vista's speech recognition in other language than the primary os language?
Citation from Vista speech recognition blog:
In Windows Vista, Windows Speech
Recognition works in the current
language of the OS. That means that
in order to use another language for
speech recognition, you have to have
the appropriate language pack
installed. Language packs are
available as free downloads through
Windows Update for the Ultimate and
Enterprise versions of Vista. Once
you have the language installed,
you’ll need to change the display
language of the OS to the language you
want to use. Both of these are
options on the “Regional and Language
Options” control panel. You can look
in help for “Install a display
language” or “Change the display
language”.
To complete aku's answer, you have here different methods to have a "multilingual use in Vista".
Installing a language pack
Switching to a different language (and back)
Creating computer users. Create a user for each language and change the display language for that user to the language of your preference. A new Speech profile will be automatically created for that user. Switch between your languages by the normal procedure of “switching to another user” (Log offà Switch users).
Note: You can create a speech recognition profile for each user with any name you prefer. Change the name, or create a new user, in the Advanced Speech panel.
COMMENTS:
The advantage of the Separate Users method is that you can switch back and forth without changing any computer defaults.
The disadvantages are that it takes more disk space and more attention must be given to user management, and that you may not have access to files opened or saved by your other users unless you know how to give yourself such an access via the new permission dialogues of Windows Vista.
You should look at System.Speech.Recognition.SpeechRecognitionEngine - it's an 'in-proc' recognizer that will let you specify the language you want.
Your next problem is that en-US Vista doesn't ship with the spanish recognition engine. For that, you'll need the Spanish Language Pack. Once you install that, you should be able to instantiate a spanish recognition engine like this:
using System.Speech.Recognition;
SpeechRecognitionEngine recognizer = new SpeechRecognitionEngine(new CultureInfo("es-ES"));
At that point, you can install grammars & do recognitions, etc.
Sure, but I want to do it without
changing the display language... no
way then?
No, not officially, if you believe this KB article: The Windows Speech Recognition language must be the same as the operating system language in Windows Vista.
So try to change it automatically, there some scripts on the internet, I found them via yahoo with Windows Speech Recognition "change language".
This one looks interesting, but it is not tested. I don't know, if it's malware or whatever, so be carefull:
Vistalizator
Good luck!
You can install the language pack, but not apply it on your user. Then you might be able to change the language of the speech recognition, although I haven't tried it since I don't have Vista Ultimate.
It will work fine as I had by changing lanuguage support.