I have a WIN32/C++ app and I want to create child windows in it that cannot be dragged out of the parent window. I want these windows to be owner-drawn, if it matters anyway. Should be simple enough; I'm looking for some basic guidance and tips regarding the subject.
It seems that you want to make an MDI app. This is much easier using a higher level framework such as MFC, WinForms, VCL etc., but can, of course, be done with plain Win32.
The MSDN documentation can be found here: Multiple Document Interface.
What you are looking for is called Multiple Document Interface (MDI).
Related
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 an MFC app that uses AfxMessageBox to display message boxes. The app itself lets an end-user to change the user interface language. On the inside it does so by loading resources using LCIDs (or FindResourceEx API.) My issue is that I can't seem to make AfxMessageBox to take LCID to change the language for OK, Cancel buttons, etc. This also affects File and Folder Open dialog windows.
Any ideas how to do this?
PS. This approach must work under Windows XP and up.
According to this SO article, there are no standard functions for this, there's a link to a CodeProject article "Localizing System MessageBox" with source code for a DLL (it's in c# but seems simple enough to be rewritten in C++) which uses Windows Hook so that you can supply your own text for the MessageBox buttons; there's even a suggestion for sizing buttons to the text in the discussion part of the same article.
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 am new to MFC well not entirely new but wanted to ask experts on this forum as why one would choose one project over the other. I hope this is not a stupid question as I am relatively new to MFC.
Thanks so much
Chose based on what template your application fits best into:
Single Document Interface (SDI) - if your application needs to work with only 1 document or data object or data set at a time
Example: notepad.exe
Multiple Document Interface (MDI) - if your applicaiton needs to work with multiple documents or data objects or data set at a time
Example: Visual Studio
Dialog Based - for anything else.
Example: Calculator
No matter what you chose, you still have the same functionality available to you in the end and you can cusotmize it in any way. So you aren't limiting yourself to anything you start with.
All variants come with CWinApp which is the base class for which you derive your MFC applications.
With a dialog based application you start with a CDialog as well. With an SDI application you start with CMainFrame, CDocument, and CView as well.
If you select an SDI project you get a whole Model-View-Controller framework included.
You get a document class (inheriting from CDocument) which ideally should hold all of the data, and a view class (inheriting from CView) to do with the display.
You get given a hosting frame with a menu already attached, and there are functions you can override to save and load to file.
If you have a dialog based application, then you get one dialog. That's it. Of course, this dialog can spawn off others, but the application essentially consists of a dialog.
If you're developing a small application that just does one task, a dialog application is appropriate, because you don't need the overhead.
If you are developing an application where the user will be loading, editing and saving data, then the SDI path would be more appropriate.
Having answered your question, I'd politely ask if there was a compelling reason why you were choosing MFC over Windows Forms. I believe that MFC was an excellent technology for its day, but the Visual Studio suite offers more advanced tools (if you're prepared to go down the .NET path).
If a "document" is the right metaphor for your application, use SDI or MDI. (Single of only one document can be open at a time, Multiple if more than one.) When you think about it, the document metaphor really isn't appropriate for most applications.
I'm developing an application in C++ that's partially driven by touch-screen on Windows XP Embedded. Some text entry will be necessary for the user. So far we've been using the standard Windows On-Screen Keyboard (osk.exe), but there are two main problems:
It's rather small on a higher resolution screen which will probably make it hard for users to hit the right keys
It's too "ugly" for the customer, who'd like a slicker on-screen keyboard that integrates better with the custom look-and-feel of the application so far.
Therefore I'm looking for alternatives for the Windows On-Screen Keyboard (osk.exe) that allow a larger size of buttons and can be skinned. Ideally it would have a BSD-like license for unburdened integration into a commercial app, but a royalty-free commercial solution could work.
Do you know of any such applications, or have you had a similar project where you solved the issue in another way?
We are using Click-N-Type for our systems. It is completely resizable. It has some customization possibilities, but I never tried them. We use it on "normal" Windows XP, but it should work on Windows XP embedded also.
I know this question is tagged 'c++', but here's an option for .Net that I found and integrated with less than 5 minutes work. (I've looked, and there isn't a .Net flavour of this question, and I guess it could be ported to C++ with very little effort too).
It uses the standard Windows On-Screen Keyboard (osk.exe), resizes it, docks it to the bottom of the screen and removes the title and menu bars, all from one call in your application.
The Code Project - Manage Windows XP On Screen Keyboard
The download is a single VB.Net class.
please check WPF Component(http://fpscomponents.com/Product.aspx?id=8) that is fully customizable by inbuilt editor. So programmer can fill it with own language and define layout!
Check johngnazzo code:
http://www.daniweb.com/forums/thread4548.html#
Why not write your own keyboard UI? This would (should) be relatively trivial and give you complete control over its look and feel.
I programmed a On Screen Keyboard in Java.
This is working very fine when you want to tip into Java components and Java frames.
When you want to tip in every open window you have to send the key event by implementing Robot sender. The problem i have is that the focus owner get the sended key and when you open the keyboard the keyboard has the focus.
You can not realy implement a global Java keyboard, as far as i know.
When you only want to use the Keyboard for Java, use Java.
Otherwise you should use another language.
You should use a native language where you can handle the OS focus owner or a language where you can completly disable the keyboard focus but also can bring the keyboard to the front of the screen
Take a look at chessware virtual keyboard.
http://hot-virtual-keyboard.com/