I hope this isn't too confusing but I have the following situation:
SDI Application that dynamically loads DLLs.
These DLLs perform various tasks, spawn dialogs, etc.
Normally these dialogs that the DLLs create are fairly simple. However I have many controls and need the features of an MDI application. I can't separate this window into a new project, so I'm looking for a way to create it within the DLL and then initialize it as if it were a simple dialog. I'm not particularly sure if this is possible but if so can someone point me in the correct direction.
Thanks!
Related
I have a problem. I am using C++ to develop an application in Win32 that among other scopes automatize some user input process in an external app in order for the user to be ready to operate.
Particularly I would like to use Win32 API to fill some text in a Qt QWidget control. I wrote a DLL in pure C to get this task done. I tested it on a MFC application and it works very well.
Anyway I could not get it to work for Qt QWidget controls.
I was able to get the right handle via the EnumChildWindows function (stored in the struct Field).
SendMessage(Field.hFound,WM_SETTEXT,(WPARAM)NULL,(LPARAM)_T("bla bla bla"));
But the SendMessage doesn't seem to work because maybe the control (most probably a QLineedit) supports other messages to get this job done.
Is there any specification for these events, I googled a lot but I could not find anything suitable.
What is the most straightforward way to get this code working? Is there an Event table mapping for Qt I could use? Do I have to use some Qt headers and link it against a DLL (this could be a problem because of licensing)?
Thanks in advance.
Qt, at least 4.8 and 5.x, uses foreign controls. None of the widgets, beyond the window, have native handles. Your EnumChildWindows is most likely not finding what you think it's finding.
If you don't have access to the Qt application's source code, there's nothing else you can do, short of injecting your own code into the running application. If the application is dynamically linked, you can figure out what version of Qt it's using, and what compiler it was compiled with, and the likely set of Qt configuration options. You can then compile your own code with the same compiler and using same Qt version, and inject it into the running application. You can then enumerate visible windows, and their children, and find the control you're after.
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 am trying to replace all Windows Common (Open/Save) filedialog calls with my own custom dialog. From what I read so far, I could do this with a hook on the calls either by writing my own or by using libraries like detours or easyhook. But someone told me recently that such an approach is only possible pre-Vista, because of the change in sessions architecture and it is impossible to do such a switch in Win 7/8. Now, I am not a guy who likes the word 'impossible' :) So if you have any advice on the matter, any at all, please do tell and I will appreciate your kindness.
For what I what to do, my application will be run by the user, it will reside in the tray, and when the user calls for Open/Save dialog from any application, it should replace the default common dialog with a custom dialog.
The newer style Common Item dialogs are implemented as standard COM objects, so you could just implement your own DLL that exposes the same COM interfaces (IFileOpenDialog, IFileSaveDialog, etc) and then override the default registrations in the Registry with your own. That way, every app that uses the dialogs will load your DLL instead of Microsoft's.
I have been playing with Qt for a week or so, with the aim of integrating Qt dialogs into an existing application. I've figured out use a basic Qt Message box from my MFC application, eg:
extern "C" __declspec(dllexport) bool showDialog( HWND parent )
{
QWinWidget win( parent );
win.showCentered();
QMessageBox::about( &win, "About QtMfc", "QtMfc Version 1.0\nCopyright (C) 2003" );
return TRUE;
}
I've used Qt Designer to create dialog boxes. What I haven't figured out is how to bring all of these pieces together. Qt Designer leaves me with a .ui file. I've seen that I can use uic to compile that to a .h file, but where are the other parts, like .cpp files? Further, if I want to compile the Qt parts to a dll, which are loaded on demand, what is the process for that? To put it into context, the existing application has 1000's of dialogs that the user may want to use, hence they all live in dll's that are loaded as needed and the dialogs come as additional downloads, kind of a plugin if you will, separately from the main program.
This is probably missing a lot, so please bring on the questions.
thanks,
Daniel
Get the VS plugin, it makes Qt work seamlessly with VS.
It complies ui files into classes which you then call from your code. You can also write dialogs, menus, etc in your C code. Since it uses sizers for layout there isn't a lot of X-Y coords to manage to place every component.
Although if you can I would go for a big-bang approach of replacing the MFC main with a Qt main and moving the functionality over. AFAIK MFC dialogs should work perfectly well in a Qt app.
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.