I have a Win32 console app that is showing this behavior.
1) Using VC 2005 cl to compile and link, the application works fine. What I mean by working fine is that characters above 128 display correctly according to Code Page 437.
2) When I use QT qmake to construct a project (QT += console) and SOURCES = main.c, the build goes fine and my main.exe is created. But the characters above 128, using WriteConsoleOuput function display differently (some weird characters). I have the felling that this has to do with the Code Page not being set up correctly. I did not call any QT functions, neither have I created QApplication, or QCoreApplication object. When I created QApplication Object or QCoreApplication Object, the results where the same (Not displaying the correct characters).
Is there anyway to display the characters above 128 correctly using Win32 console and QT ?
I certainly wouldn't recommend using WriteConsoleOuput if that's a Windows specific API. Qt provides an easy way to write out strings using QTextStream:
// setup
QFile f;
f.open(stdout, QIODevice::WriteOnly);
QTextStream qout(&f);
// usage
qout << tr("translate this text");
I would recommend you use UTF-8 for everything, if possible. Then you don't have to worry about the different encodings, etc. If you are required to output in your local encoding for some reason, then consider QString::fromLocal8bit().
I solved the problem by using WriteConsoleA functions.
Related
I'm trying to develop C++ code in VS Code on a mac. I have no problems building and debugging. However, my editor is full of red ink. Is there a way to fix my editor so it is as smart as the compiler?
Here's a simple example: https://github.com/TradeIdeasPhilip/compress/tree/master/mac-os/eight. I can open this folder in VS code and build and run, but the editor is ugly.
One of the first error messages is on line 22 of EightShared.C:
const std::string preloadContents = "\xdc\xe4\xeb\xf1\xf6\xfa\xfd\xff";
This should be very straightforward. It's a string constant. I'm importing <string> through another header file. (And adding directly to the top of this file did not make a difference.) But VS code marks the first : in red and when I hover over it I see expected a ; and when I ask it to help me, it offers to disable the red squiggles.
The editor also complains about the class keyword on line 31 even though it accepts classes in other files.
The editor also complains about most (but not all) references to types like uint32_t even though I #include <stdint.h> and that works without any red ink. Here's an example from EightShared.h
Those are just a couple of samples. My editor is filled with red marks.
I'm using Microsoft's C++ extensions for VS Code. I'm guessing that one of these needs to be configured better.
Any thoughts on how to get rid of all of these red marks? Maybe a sample of a working config file or a suggestion of what I'm doing wrong? Thanks.
I eventually found a problem in my .vscode/c_cpp_properties.json file. I removed "/Library/Developer/CommandLineTools/usr/include/c++/v1" from the "includePath". Then intellisense started working again.
I have no idea how that line got into that file. I certainly didn't type it.
The change in GitHub.
I got filedialog called inside my main window with this code:
QAction *actionWithShortcut = new QAction();
actionWithShortcut->setShortcut(Qt::CTRL + Qt::Key_9);
actionWithShortcut->setShortcutContext(Qt::ShortcutContext::WidgetWithChildrenShortcut);
// added this comment to check does it work at list outside filedialog
// addAction(actionWithShortcut);
QFileDialog *fd = new QFileDialog(this);
fd->addAction(actionWithShortcut);
connect(actionWithShortcut, &QAction::triggered, fd, &QFileDialog::reject);
fd->show();
But looks like I can't add any actions to QFileDialog or they are somehow omitted. Any suggestions?
Already tried window flags, options and etc. Can't find any solutions.
By default, a QFileDialog is a thin wrapper around the native dialog. Qt didn't go to the lengths needed to wrap actions around the native dialog. So this is a case of a missing implementation. You could patch Qt to make it work on a platform of your choice, and contribute the change back, of course.
The action would presumably work if you were to switch to a non-native file dialog.
Im trying to make a simple OSX-like dock application using Haxe 3.1.3. I cant seem to work out how to make the main application window transparent (no titlebars, borders etc), as well as ignoring mouse events except on the icons themselves. Ideally no taskbar item either, just a system tray item.
I believe Haxe Windows target uses SDL, and am pretty sure that SDL can support this kind of behaviour? Im not sure how Neko target is compiled, or handles this... Is there some flags I can set in the Haxe application.xml or something like that? Or is this just not possible with the Haxe Windows or Neko targets?
EDIT
I Discovered that the Waxe haxelib, which can be compiled with Neko, has a bunch of flags in the Window.hx file - https://github.com/nmehost/waxe/blob/cd9739e007ed10918166588faf2339d623b22fc4/wx/Window.hx
These include such options as FRAME_NO_TASKBAR and BORDER_DOUBLE, which both work when passed as arguments to the wx.Frame.create() function in the Simple.hx Waxe sample project.
It also includes the flag TRANSPARENT_WINDOW, but this appears to do nothing. No idea why the other flags are working, but the TRANSPARENT_WINDOW flag doesnt.
In Openfl (it's openfl which uses sdl and a xml project), you can remove the window border with this in your application.xml:
<window borderless="true"/>
But I don't know a way to move the window without borders.
relevant discussion:
http://www.openfl.org/forums/#!/general:moving-borderless-windows
I have an MFC application developed with Visual Studio 2008 where I use Adobe ActiveX control (I have Adobe Reader X installed). I try to set the zooming rectangle using the setViewRect function and it works perfectly.
Now the problem appears when in my Windows Regional Settings, the decimal symbol is set to comma instead of dot (such as in the German Regional Settings). The parameters of the zooming rectangle seem to be interpreted incorrectly.
I used ProcessMonitor and discovered that when Adobe ActiveX Control is created and its DLL is loaded in my process, it calls setlocale, and hence the application is using the current Windows Regional Settings instead of the default "C" locale. Therefore, the application interprets the numbers in a wrong way.
I tried to reset the locale to "C" right after loading Adobe and this workaround fixed the problem.
Now the problem happened again when I migrated my application to Visual Studio 2010. Apparently Adobe DLL ("c:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll") is developed using Visual Studio 2008. So when it sets the locale, it is done in MSVCR90.dll. When I reset the locale, I did so using the same DLL.
Now as my application is in VS2010, calling setlocale is done in MSVCR100.dll, so it does not affect the locale already set in MSVCR90.dll.
Is there a way to set the locale of the COM object that I am hosting inside my application?
Thank you so much in advance :)
This is just a shot in the dark, but you could try loading MSVCR90.dll with LoadLibrary (since the DLL is already loaded, it'll just give you a HANDLE to it, it won't load it twice), then finding the pointer to its setlocale function with GetProcAddress. Then you will be able to call the setlocale function for this DLL. It's an ugly hack, but it might work.
Using C++/CLI, How to display a managed control (eg. System::Windows::Forms::Panel^) on a window created in native code?
An external program calls my native method where i can access it's window via
SubclassWindow(hNativeWindow, MyNativeWindowProc);
Then I create control with something similar to:
MyNameSpace::MyControl^ ctrl = osozKomunikator = gcnew MyControl("SomeText", hNativeWindow);
ctrl->Show();
MyControl is derived from System::Windows::Forms::UserControl and has overriden CreateParams to set Parent to hNativeWindow.
As the result the control flashes and dissapears, does not show at all or shows only after I slow down the execution with the debugger.
Please help.
Windows Forms supports being hosted like ActiveX in native windows since .Net 1.1. The host needs to implement some interfaces, though. MFC 8.0 wrapped around the necessary code in CWinFormsDialog and CWinFormsView. Use MFC's support classes if you can. If you can not, install MFC from Visual C++ 2005 or higher and check the source code of MFC's OLE support classes, like COleControlContainer, COleControlSite, etc.