This code works for windows 7
but doesn't work for windows XP (outputs only part of startup folder path)
#include <iostream>
#include <shlobj.h>
using namespace std;
int main()
{
wchar_t startupFolder[1024];
HRESULT hr = SHGetFolderPath(0, CSIDL_STARTUP, 0, 0, startupFolder);
if (SUCCEEDED(hr))
wcout << L"Startup folder = " << startupFolder << endl;
else
cout << "Error when getting startup folder\n";
getchar();
return 0;
}
output is:
Startup folder = C:\Documents and Settings\Admin\ <- cursor is here.
Newline is not provided.
Also I have russian window xp. I think this is unicode issue.
when I use wprintf I got:
C:\Documents and Settings\Admin\???????? .....
Thanks.
The problem is that the font that your XP console uses does not contain glyphs for the Russian characters you are trying to output. The fonts that Windows 7 ships with and uses by default in its console do have a much broader coverage of Unicode code points. You'll need to configure your console to use a font that contains the glyphs you want.
Related
I'm on Windows 7 and I'm trying to change the color balance from code. Specifically, I'm trying to change these sliders that show on the color calibration wizard.
I'm assuming that the correct functions are SetMonitorRedGreenOrBlueGain and SetMonitorRedGreenOrBlueDrive.
Here is my minimal working example:
#pragma comment(lib, "dxva2.lib")
#include <windows.h>
#include <lowlevelmonitorconfigurationapi.h>
#include <physicalmonitorenumerationapi.h>
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <string>
using namespace std;
int main()
{
HWND hWnd = GetDesktopWindow();
HMONITOR hMonitor = MonitorFromWindow(hWnd, MONITOR_DEFAULTTOPRIMARY);
cout << "Monitor: " << hMonitor << endl;
DWORD cPhysicalMonitors;
BOOL bSuccess = GetNumberOfPhysicalMonitorsFromHMONITOR(hMonitor, &cPhysicalMonitors);
cout << "GetNumber: " << bSuccess << ", number of physical monitors: " << cPhysicalMonitors << endl;
LPPHYSICAL_MONITOR pPhysicalMonitors = (LPPHYSICAL_MONITOR)malloc(cPhysicalMonitors * sizeof(PHYSICAL_MONITOR));
bSuccess = GetPhysicalMonitorsFromHMONITOR(hMonitor, cPhysicalMonitors, pPhysicalMonitors);
cout << "GetPhysicalMonitor: " << bSuccess << endl
<< "Handle: " << pPhysicalMonitors[0].hPhysicalMonitor << endl
<< "Description: ";
wcout << (WCHAR*)(pPhysicalMonitors[0].szPhysicalMonitorDescription);
DestroyPhysicalMonitors(cPhysicalMonitors, pPhysicalMonitors);
free(pPhysicalMonitors);
}
The output is:
Monitor: 00010001
GetNumber: 1, number of physical monitors: 1
GetPhysicalMonitor: 1
Handle: 00000000
Description: Generic PnP Monitor
All the functions for brightness and color gains require HANDLE hPhysicalMonitor which is always null for my display (laptop screen). But, I know it must be possible to change the color balance since the color calibration window can do that.
What am I doing wrong?
EDIT 1:
As mentioned in the comments, it seems that the hPhysicalMonitor is correct. My issue is that calling functions like GetMonitorBrightness returns FALSE with an error code of ERROR_GRAPHICS_I2C_ERROR_TRANSMITTING_DATA (An error occurred while transmitting data to the device on the I2C bus.)
EDIT 2:
My monitor does support setting brightness and has 11 levels. Windows itself and some programs are able to adjust the brightness (the back-light of the monitor directly). So the issue must be software related.
My issue is that calling functions like GetMonitorBrightness returns
FALSE with an error code of ERROR_GRAPHICS_I2C_ERROR_TRANSMITTING_DATA
(An error occurred while transmitting data to the device on the I2C
bus.)
GetMonitorBrightness works for me. I tested it on i.e desktop. Some similar cases point out that GetMonitorBrightness does not work on some laptops.
GetMonitorCapabilities returns false
How to control system brightness using windows api ?
I think your laptop does not support DDC/CI.
GetMonitorCapabilities： The function fails if the monitor does not
support DDC/CI.
You may first check if your laptop supports DDC/Cl.
I'm trying to retrieve the complete list of the user's preferred languages from a C++/Qt application, as configured in the "Region & language" page in the user's preferences:
For that, I am trying with the WinAPI function GetUserPreferredUILanguages(), on an up-to-date Windows 10 Pro system.
However, the function always only returns the first entry (the main Windows display language), and "en-US". If English is configured as the main language, then only "en-US" is returned. E.g., if I have (German, French, English) configured, ["de-de", "en-US"] is returned, French is omitted. If I add more languages to the list, they are omitted as well.
I also looked at User Interface Language Management, but to no avail. GetSystemPreferredUILanguages() for example only returns "en-US". GetUILanguageFallbackList() returns ["de-de", "de", "en-US", "en"].
The code I use:
// calling GetUserPreferredUILanguages() twice, once to get number of
// languages and required buffer size, then to get the actual data
ULONG numberOfLanguages = 0;
DWORD bufferLength = 0;
const auto result1 = GetUserPreferredUILanguages(MUI_LANGUAGE_NAME,
&numberOfLanguages,
nullptr,
&bufferLength);
// result1 is true, numberOfLanguages=2
QVector<wchar_t> languagesBuffer(static_cast<int>(bufferLength));
const auto result2 = GetUserPreferredUILanguages(MUI_LANGUAGE_NAME,
&numberOfLanguages,
languagesBuffer.data(),
&bufferLength);
// result2 is true, languageBuffer contains "de-de", "en-US"
Is this not the right function to use, or am I misunderstanding something about the language configuration in Windows 10? How can I get the complete list of preferred languages? I see UWP API that might do the job, but if possible, I'd like to use C API, as it integrated more easily with the C++ codebase at hand. (unmanaged C++, that is)
GlobalizationPreferences.Languages is usable from unmanaged C++ because GlobalizationPreferences has DualApiPartitionAttribute.
Here is a C++/WinRT example of using GlobalizationPreferences.Languages:
#pragma once
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.System.UserProfile.h>
#include <iostream>
#pragma comment(lib, "windowsapp")
using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::System::UserProfile;
int main()
{
winrt::init_apartment();
for (const auto& lang : GlobalizationPreferences::Languages()) {
std::wcout << lang.c_str() << std::endl;
}
}
And a WRL example for those who cannot migrate to C++ 17:
#include <roapi.h>
#include <wrl.h>
#include <Windows.System.UserProfile.h>
#include <iostream>
#include <stdint.h>
#pragma comment(lib, "runtimeobject.lib")
using namespace Microsoft::WRL;
using namespace Microsoft::WRL::Wrappers;
using namespace ABI::Windows::Foundation::Collections;
using namespace ABI::Windows::System::UserProfile;
int main()
{
RoInitializeWrapper initialize(RO_INIT_MULTITHREADED);
if (FAILED(initialize)) {
std::cerr << "RoInitialize failed" << std::endl;
return 1;
}
ComPtr<IGlobalizationPreferencesStatics> gps;
HRESULT hr = RoGetActivationFactory(
HStringReference(
RuntimeClass_Windows_System_UserProfile_GlobalizationPreferences)
.Get(),
IID_PPV_ARGS(&gps));
if (FAILED(hr)) {
std::cerr << "RoGetActivationFactory failed" << std::endl;
return 1;
}
ComPtr<IVectorView<HSTRING>> langs;
hr = gps->get_Languages(&langs);
if (FAILED(hr)) {
std::cerr << "Could not get Languages" << std::endl;
return 1;
}
uint32_t size;
hr = langs->get_Size(&size);
if (FAILED(hr)) {
std::cerr << "Could not get Size" << std::endl;
return 1;
}
for (uint32_t i = 0; i < size; ++i) {
HString lang;
hr = langs->GetAt(i, lang.GetAddressOf());
if (FAILED(hr)) {
std::cerr << "Could not get Languages[" << i << "]" << std::endl;
continue;
}
std::wcout << lang.GetRawBuffer(nullptr) << std::endl;
}
}
I found out that language list returned by GetUserPreferredUILanguages() matters with your "Windows UI language" setting, and nothing to do with "Input method list order".
For example, in following screenshot from Win10.21H2,
I can see GetUserPreferredUILanguages() return a list of three langtags:
fr-CA\0fr-FR\0en-US\0\0
In summary, for GetUserPreferredUILanguages() and GetUILanguageFallbackList() their returned langtag list is determined solely by current user's "Windows display language" selection. It is a user-wide single-selection setting. And, for a specific display-language selection, the list-items within and the order of the list-items are hard-coded by Windows itself. Yes, it is even unrelated to what "input methods(IME)" you have added to the control panel -- for example, you add "fr-CA" but not "fr-FR", and the fallback list will still be fr-CA\0fr-FR\0en-US\0\0.
The difference of the two APIs, according to my experiment, is that GetUILanguageFallbackList() returns neutral langtags("fr", "en" etc) as well, so it produces a superset of GetUserPreferredUILanguages().
I am trying to do some simple box drawing in the terminal using unicode characters. However I noticed that wcout wouldn't output anything for the box drawing characters, not even a place holder. So I decided to write the program below and find out which unicode characters were supported and found that wcout refused to output anything above 255. Is there something i have to do to make wcout work properly? Why can't access any of the extended unicode characters?
#include <wchar.h>
#include <locale>
#include <iostream>
using namespace std;
int main()
{
for (wchar_t c = 0; c < 0xFFFF; c++)
{
cout << "Iteration " << (int)c << endl;
wcout << c << endl << endl;
}
return 0;
}
I don't recommend using wcout because it is non-portable, inefficient (always performs transcoding) and doesn't support all of Unicode (e.g. surrogate pairs).
Instead you can use the open-source {fmt} library to portably print Unicode text including box drawing characters, for example:
#include <fmt/core.h>
int main() {
fmt::print("┌────────────────────┐\n"
"│ Hello, world! │\n"
"└────────────────────┘\n");
}
prints (https://godbolt.org/z/4EP6Yo):
┌────────────────────┐
│ Hello, world! │
└────────────────────┘
Disclaimer: I'm the author of {fmt}.
I'm working on a means of installing a driver. Because of the multiple platforms on which this must work, I'm shelling-out to both devcon and dpinst to do the work of driver install/update/removal when needed. While testing, I'm having problems with the shelling out to devcon. To isolate, I wrote a small app to do what devcon does in update see here, using the devcon source from the WinDDK for reference. I'm having some problems with UpdateDriverForPlugAndPlayDevices() from Setup API (actually part of Newdev.dll) see here. The source code is here:
#include <iostream>
#include <Windows.h>
#include <newdev.h>
int main(int argc, char** argv) {
// Go through the same steps as does dev con for this update crap
char infFile[MAX_PATH];
if(3 > argc) {
std::cerr << "an INF and HW ID must be specified" << std::endl;
return 1;
}
DWORD result(GetFullPathName(argv[1], MAX_PATH, infFile, NULL));
if((result >= MAX_PATH) || (0 == result)) {
std::cerr << "path is too long for buffer" << std::endl;
return 1;
}
if(GetFileAttributes(infFile) == -1) {
std::cerr << "file doesn't exist" << std::endl;
return 1;
}
BOOL reboot(FALSE);
if(!UpdateDriverForPlugAndPlayDevices(NULL, argv[2], infFile, INSTALLFLAG_FORCE, &reboot)) {
std::cerr << "Failed to install the driver. Code: "
<< GetLastError()
<< std::endl;
return 2;
}
if(reboot) {
std::cout << "A reboot is needed to complete driver install"
<< std::endl;
}
return 0;
}
The program fails when UpdateDriverForPlugAndPlayDevices() returns false. This then prints the error code, returned by GetLastError(), so I'd know what went wrong. The error code returned: 259. According to this resource says this is ERROR_NO_MORE_ITEMS. According to the link for UpdateDriverForPlugAndPlayDevices(), this function returns this error code when, "The function found a match for the HardwareId value, but the specified driver was not a better match than the current driver and the caller did not specify the INSTALLFLAG_FORCE flag." You'll notice from my code that I did specify this flag.
I do not know where to go from here. Can someone please identify from this code what it is I'm missing? This just has the "feel" of something simple, but I'm totally missing it.
Thank you,
Andy
The problem appeared to be not with the code but with the INF file. Interesting that the documentation for the function said that using that flag will force the install but didn't when the INF file didn't "list" any device classes in the models section. This is how I was able to install eventually. I added the correct device class to the models section in the INF.
EDIT Sep. 17, 2020
It was requested by someone just today (of the edit) to add an example from the INF. It's been 8 years since I had this issue and I no longer work for this team. However, as best as I can recall, and drawing heavily upon the docs for INF Models Section and INF Manufacturers Section, I hope this helps.
Essentially, the class is specified by the Models Section and the model is specified by the Manufacturer Section.
[Manufacturer]
%MfgName%=Standard,NTamd64
[Standard.NTamd64]
%DeviceString%=<class path or GUID>\<device>
[Strings]
MfgName=ACME
DeviceString="Device Type"
I have a 32 bit program that has been installed by a customer on 64 bit windows.
There appears to be a problem with using ShellExecute and the print verb in that configuration. First my test program.
// printme.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "objbase.h"
#include <windows.h>
#include <shellapi.h>
int main(int argc, char* argv[])
{
if (argc != 2)
{
printf("Usage: %s file_to_print", argv[0]);
return 0;
}
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) ; //| COINIT_DISABLE_OLE1DDE);
HINSTANCE retVal = ::ShellExecute(NULL, "print", argv[1], NULL, NULL, 0); // don't ask, as the user can always cancel...
printf("RetVal = %08x\n", retVal);
printf("LastError = %08x\n", GetLastError());
return 0;
}
This program works correctly on 32 bit windows version up to Windows 7. The program simply runs the print verb on the first argument passed on the command line.
printme Page1.htm
On the system in question, the registry is set up as follows:
HKEY_CLASSES_ROOT\htmlfile\shell\print\command
contains a default value of type REG_EXPAND_SZ containing
rundll32.exe %windir%\system32\mshtml.dll,PrintHTML "%1"
If I run the following command
rundll32 c:\windows\system32\mshtml.dll,PrintHTML “Page1.htm”
the print dialog is successfully shown.
However running my program blinks, but the print dialog never appears, and a stalled copy of
C:\Windows\sysWow64\rundll32.exe is in process manager, which never completes.
Is there a workaround, or is ShellExecute permanently broken for common verbs on common file types from 32 bit programs on 64 bit windows?
It turns out the problem is the last parameter of ShellExecute. While 0 worked for years, it now requires SW_SHOW to function correctly for the print verb in this case. Perhaps a recent windows update changed the behavior?