I would like to create a Windows application (for Windows 10) using the C++ and the Windows API. I already have some basic knowledge of using the built-in windows controls to create a basic application, but would now like to expand into custom controls . Since I have no need for my application to be compatible with anything but Windows 10, and would like to use a reliable API which supports transparency and anti-aliasing but is also fast enough to render a GUI, I have chosen to use Direct2D.
The MSDN documentation says:
'Your application should create render targets once'
Bearing this in mind, should each child window use one ID2D1HwndRenderTarget which renders only to the parent window (and doesn't respond to the child windows' WM_PAINT messages), or should there be a single ID2D1DCRenderTarget which would draw to each control using the device context from the WM_PAINT message (using bindDC() - although I would still like to be able to use transparency, and am not interested in GDI interoperability)? Should I even be using Direct2D at all?
I would like to use the Windows API, so a solution involving QT or MFC wouldn't work. I haven't got a specific application in mind, but would eventually like to create a simple library that would enable me to quickly produce GUI applications that have a custom look.
I have spent hours scouring the web for answers, but have found nothing conclusive. MSDN itself seems particularly unhelpful, it just teaches you to draw an ellipse and stops there. Please forgive me if I have accidentally broken the rules of asking questions - as you can probably tell I am new to Stack Overflow - and if any other information is needed, I will of course include it (I am using C++ with Visual Studio Community 2019).
Related
I am trying to add text input functionality into existing DirectX application that was being ported to Windows Store / Phone 8.1. The problem is that I can't even get the sample code provided by microsoft in this article to compile:
http://msdn.microsoft.com/en-us/library/windows/apps/jj247546%28v=vs.105%29.aspx
I am using Universal App project as a base and I have no acces to Windows::Phone::UI::Core (there is no Core namespace at all!)
I was trying to add dummy textbox and hid it somewhere but without luck as to appear the software keyboard you need to focus the textbox - the moment it receives focus it appears on the screen (we draw our own controls so I don't want the system one) despite the fact being set to Transparent, both foreground and background and width to 0.
How can I manipulate SIP to show/hide and retrieve input from the keyboard without having to hack my way through XAML and stuff?
On Windows Phone (but not Windows) apps can request the InputPane hide and show programmatically by calling InputPane.TryShow and TryHide.
If you want the InputPane to show automatically then you need to set focus to a control which identifies itself as a text control to the automation system (see the Touch Keyboard documentation on MSDN. Windows Phone works essentially the same as Windows 8 here).
There are two ways to do this in a DirectX app:
As the other thread describes and as you've tried, you can use a Xaml TextBox on top of your DirectX surface. This has the advantage of being easy as the Xaml controls already implement the accessibility and IME interfaces needed for full text support. It has the disadvantage of being external to the DX scene so it can require some care to place it nicely. You can't really hide the TextBox and divert the input, but need to use the TextBox for input. I prefer to do the full interactive form in Xaml rather than trying to merge a single TextBox into a full scene.
The other option is to implement a text control in DirectX. Windows uses the UI Automation API to identify and interact with text controls. If you implement the TextPattern and focus for your control within DirectX then the keyboad will automatically invoke when the user sets focus to it. There's a sample at Input: Touch keyboard sample which demonstrates the necessary interfaces within a custom Xaml control context. It won't apply directly to DX, but will give the general idea. The UI Automation Provider Programmer's Guide has more in depth information on implementing UI Automation interfaces. Again, while these docs target Windows they will also apply to Windows Phone.
I'm not sure exactly which code didn't compile for you. The linked pages are a bit out of date (SwapChainPanel is now preferred over SwapChainBackgroundPanel), but the classes and techniques involved should be valid for Windows Phone Runtime apps.
In our project we have three independent applications, and we have to develop a QT control application that controls these three applications. The main window will be seperated to three sub windows - each one display another one application.
I thought to use QX11EmbedWidget and QX11EmbedContainer widgets, but two problems with that:
The QX11Embed* is based on X11 protocol and I dont know if it's supported on non-x11 systems like Windows OS.
Since QT 5 these classes are not existing, and the QT documentation doesn't mention why.
So that I dont know whether to use it or not - I'll be happy to get an answers.
In addition, I see that the QT 5.1 contains QWidget::createWindowContainer(); function that in some posts it looks like this should be the replacement to the X11Embed. Can anyone please explian me more how can I use this function to create a QT widget that will run another application (a Calculator for example) inside its?
I have searched a lot in Google, and didn't find answers to my Qs.
Can anyone please help me? Am I on the right way?
Thanks!
If all three independent applications are written with Qt, and you have their source, you should be able to unify them just through the parenting of GUI objects in Qt.
http://qt-project.org/doc/qt-4.8/objecttrees.html
http://qt-project.org/doc/qt-4.8/widgets-and-layouts.html
http://qt-project.org/doc/qt-4.8/mainwindows-mdi.html
If you don't have access to them in that way, what you are talking about is like 3rd party window management. It is kind of like writing a shell, like Windows Explorer, that manipulates the state and the size of other window applications.
Use a program like Spy++ or AutoIt Spy for Windows and the similar ones for other OS's, and learn the identifying markings of your windows you want to control, like the class, the window title, etc. Or you can launch the exe yourself in a QProcess::startDetached() sort of thing.
http://qt-project.org/doc/qt-5.1/qtcore/qprocess.html#startDetached
Then using the OS dependent calls control the windows. The Qt library doesn't have this stuff built in for third party windows, only for ones under the QApplication that you launched. There are a lot of examples of doing things like this by AutoHotKey, or AHK. It is a scripting language that is made for automating a lot of things in the windows environment, and there is port for Mac as well (though I haven't tried the mac port myself).
So in the end you are looking at finding your window probably with a call like this:
#include <windows.h>
HWND hwnd_1 = ::FindWindow("Window_Class", "Window Name");
LONG retVal = GetWindowLongA(hwnd_1, GWL_STYLE); // to query the state of the window
Then manipulate the position and state of the window like so:
::MoveWindow(hwnd_1, x, y, width, height, TRUE);
::ShowWindow(hwnd_1, SW_SHOWMAXIMIZED);
You can even draw widgets on top of the windows you are controlling if you set your window flags correctly for the windows you are manipulating.
transparent QLabel with a pixmap
Cannot get QSystemTrayIcon to work correctly with activation reason
Some gotchas that come up in Windows when doing all of this, is finding out the quirks of the Windows UI when they set the Display scaling different from what you expect, and if you want to play nice with the Task bar, and handling all the modal windows of your programs you are manipulating.
So overall, it is do-able. Qt will make a nice interface for performing these commands, but in the end you are looking at a lot of work and debugging to get it in a beautiful, reliable, window manager.
Hope that helps.
I never tried it myself, but from the docs in Qt 5.1 I would try QWindow::fromId(WId id), which gives you a QWindow, which should be embeddable with createWindowContainer:
QWindow * QWindow::fromWinId(WId id) [static] Creates a local
representation of a window created by another process or by using
native libraries below Qt.
Given the handle id to a native window, this method creates a QWindow
object which can be used to represent the window when invoking methods
like setParent() and setTransientParent(). This can be used, on
platforms which support it, to embed a window inside a container or to
make a window stick on top of a window created by another process.
But no guarantee. :-)
I have a large C++ application with a mostly homegrown layer for GUI Abstraction etc. The application is plain C/C++ on Win32 API.
So far the application only supports a static horizontal toolbar which can not be modified in any way at runtime (besides enabling/hoovering visualization).
We thought about switching to a ribbon interface but nobody we asked liked that idea.
So we want to add some sort of toolbar with the following capabilities:
Movable and resizeable (acting as floating windows/palettes)
Use Bitmaps of any Size
Supports User configured Toolbars Supports
Enabling/Disabling/Checked State
Preferably create disabled/checked/hoovering state bitmaps automatically
How can this be done with the least effort?
I looked at rebars and the TOOLBAR API. Rebars seem not to be resizeable and i was unable to find a working sample for toolbars.
Working sample: here's what I could find: tutorial with link to full example code, part-3 covers toolbars
I am writing a C++ application and I have a Login Box that's shown in a regular Dialog Box Frame. I see that some people can SKIN the entire dialog box and makes it look really nice. I was wondering if anyone can give me some pointers as to how to do that.
I'd need more details to give you a good answer.
The answer very much depends on which OS you're using and how you're programming your GUI (for example on Windows - plain Win32, MFC, ATL, Qt, Windows Forms, WPF etc etc).
If you're just using the Windows API here's a link to get you started.
http://www.codeproject.com/KB/dialog/skinstyle.aspx
Beware: custom skinning dialog boxes can be a very large task if you want to customise the look of every control as you end up writing very complicated custom controls.
Alternatively do you just want to make sure that your dialogs appear with Windows XP visual style rather than pre-XP style? This will require changes to your application to use the new common controls and visual style. Note that this changes the behaviour of some Windows APIs and can potentially have side effects (see ISOLATION_AWARE_ENABLED).
I always wondered how software such as iTunes, Winamp etc is able to create its own UI.
How is this accomplished under the Windows platform? Is there any code on the web explaining how one would create their own custom GUI?
WinAmp doesn't usually supply its own GUI at all -- it delegates that to a "skin". You can download dozens of examples and unless memory fails me particularly badly, documentation is pretty easily available as well.
From the looks of things, I'd guess iTunes uses some sort of translation layer to let what's basically written as a native Mac UI run on Windows (the same kind of thing that Apple recently decided was so evil that they're now forbidden on the iPhone and apparently the iPad).
Since saying anything that could possibly be construed as negative about Apple is often treated as heresy, I'll point to all the .xib files that are included with iTunes for Windows. An .XIB file (at least normally) is produced by Apple's Interface Builder to hold resources for OS/X programs, and compiled to a .NIB file prior to deployment. Windows doesn't normally use either .XIB or .NIB files at all, and it appears likely to me that Apple includes a compatibility layer to use them on Windows (though I've never spent any time looking to figure out what file it's stored in or anything like that).
Edit: (response to Mattias's latest comment). Rendering it is tedious but fairly straightforward. You basically take the input from the skin (for example) and create an owner draw control (e.g. a button) and render the button based on that input.
The easiest way to do this is to have fixed positions for your controls, and require the user to draw/include bitmaps for the background and controls. In this case, you just load the background bitmap and display it covering the entire client area of your application (and you'll probably use a borderless window, so that's all that shows). You'll specify all your controls as owner-drawn, and for each you'll load their bitmap and blit it to the screen for that control. Since there won't (usually) be a visible title bar, you'll often need to handle WM_NCHITTEST (or equivalent on other systems) to let the user drag the window around.
If you want to get a bit more complex, you can add things like allowing them to also specify a size and position for each control, as well as possibly specifying that some controls won't show up at all. Again, this isn't really terribly difficult to manage -- under Windows, for example, most controls are windows, and you can specify a size and position when you create a window. If the user loads a different skin at run-time, you can call MoveWindow to move/resize each control as needed.
I'm assuming that you mean creating a GUI application as opposed to a GUI framework.
There are lots of GUI frameworks available for Windows.
Some are
wxWidgets (www.wxwidgets.org)
Qt (http://qt.nokia.com/products)
And of course the venerable MFC framework (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx)
If you want a more complete list, look at the Wikipedia article for MFC (http://msdn.microsoft.com/en-us/library/d06h2x6e%28VS.90%29.aspx) and scroll to the bottom.
Each of these GUI frameworks is amply documented on the web.