I've been making a simple application which is able to launch a variety of other applications through QT5 (using QProcess class) but I've been running into a few key issues with the design. Specifically, it seems that Qprocess cannot set focus to windows that have been created via QProcess' start() function. This means that once a user opens more than one window, it can never return to the previous window that has been opened. After looking further into this dilemma, it has become clear that my program will need to be able to handle basic window management in order to fulfill my specifications.
I've decided that the best example to study for my program is Docky, which is capable of opening, closing and switching windows. Looking at the source code for that project was helpful, but there were many C# system calls that were used for fetching the list of client-windows which aren't available for my C++ program.
How can I get a list of all the X11 Windows that the client is running and provide basic window management (Switch To/ Open / Close Window) using C++? Is there a cross platform way of doing this through QT? Can I get this information directly using XServer?
Related
I have a simple C++ console application and wondered if there would be any way to add a GUI without having to remake the application.
I am using a MinGW compiler, the Eclipse CDT IDE and standard and boost libraries.
(without knowing much of the console application)
You will have to remake the application.
If the console application is "well made", user interaction disconnected from actual functional code, then it should be a straightforward conversion.
Just create the appropriate UI and call the necessary functions.
For example if your console application contained a textual menu and asked answers, then you will have buttons and/or menu and/or edit box in the GUI that you will need to patch up to the code.
Max.
If you don't want to rewrite the application you could trying using a separated engine and interface pattern where the GUI and console apps are separate executables where the GUI spawn an instance of the console app and communicates with it to drive the application through some mechanism, e.g. Stdin
If your console application cannot be driven this way you nay need to change / rewrite the app
You should detail your question in order to get more precise answers.
What is the level of interactivity your console application provide ?
- It's just like a simple command with input parameters that produce output at end of the program
in this case, you can just code a gui front end that will get the parameters from a form or whatever you need and then your gui application will launch the console command, parse the result and display it in the gui.
- the console application is very interactive (takes input from the user during all the execution)
the console application code very big and very coupled to console interaction :
Maybe you can write a gui wrapper that takes std::in and std::out and render the two streams in gui widgets but that can be tricky. This is not a very pleasant solution, it should be used only if you really don't want to get inside the console application code.
the console application code is not that big or its easy to split the console input/ouput part from the rest of the program :
In this case, you should make a library from your app and then write a gui for it.
I may be approaching this in completely the wrong way as I am pretty new to the C++ language and the overall way this kind of application should be structured, but I hope to confirm the correct method here.
Essentially, I have one cpp file which operates as a console application & a separate cpp file which runs as a windowed application. I want to be able to launch the windowed application when a certain point is reached within the console application. Is this possible? If so, how would I go about doing this?
Some more detail - The console application acts as a 'server' using winsock to communicate with another console application (the client). When the console server application reaches a certain point (a client connects with it) I wish to then launch the other windowed application I have created which will render certain graphics onscreen using Directx. Currently I have both these cpp files as separate projects in a single C++ 2010 Express solution. Currently, there are no links between the two cpp files and they both operate correctly when run separately.
If any more specifics are required, I can provide them but I really want to find out if this approach in general will work.
Thanks.
If you are not running a managed C++ application, then CreateProcess is the canonical WIN32 system call to use.
Do you just want to run the exe from another exe?
System::Diagnostics::Process::Start("C:\\Folder\\file.exe");
I need to customize right click so that I can scan a directory with my anti-virus. I know how to do that using registry keys, but the problem is that I don't want to start a new instance of my program every time I want to scan a directory. My anti-virus needs to load some signature databases so it will take around 15 seconds for the program to load those. I need to use the instance of the program which I have already opened and is running for scanning the directory. How can I do that?
I am using C++Builder.
Thanks.
Considering you already know how to add the item to the right click contextual menu, I suggest implementing a client/server set of applications:
A server that loads up when you turn your computer on and does the scanning, and
The client that tells it what to do using IPC - inter-process communication.
You then add the client application to various contextual menus, passing it arguments that indicate what it should get the server to do depending on what you right-clicked on.
IPC is a bit of a pain in the butt, the easiest way is to use TCP/IP to and do local networking using a network library. There are many out there, however given you'll likely want to have other features such as UI elements and a tray icon, I suggest you look at Qt, namely the following components:
QtNetwork: For performing communication between the client and the server executable.
QSystemTrayIcon: For displaying a small icon on the tray.
There are quite a few other little bits of Qt you'll no doubt encounter (like all the fabulous UI stuff), and fortunately Qt is well documented and help is always available here, and from the Qt Developer Network. You can get started with Qt by downloading and installing the SDK:
http://qt.nokia.com/downloads/
Best of luck :).
Implement a DDE server in your anti-virus, and then add a ddeexec subkey to your Registry key. Alternatively, add an OLE Automation object to your app that implements the IDropTarget interface, and then add a DropTarget subkey to your Registry key that specifies the object's CLSID.
Either way, whenever your menu item is then invoked, Windows will call into your existing app instance if it is already running, otherwise it will launch a new instance and then call into it. Either way, Windows is handling all of that for you. All you are doing is providing an entry point for Windows to call into.
I would suggest the IDropTarget method, because DDE is deprecated, and because IDropTarget is more flexible. While your app is running, you could re-use the same IDropTarget object to handle OLE Drag&Drop operations on your app's UI window and Taskbar button, and support automated invokations of your scanner by other apps.
I have a GUI C++ application (Visual Studio 2008) that needs to be converted to a console one.
I don't have any experience in C programming. Mostly I use .NET. Where do I start?
Down-converting a GUI app is major surgery. The programming model is entirely different, a GUI app is event driven. Relying on a message loop to deliver events, processed in message handlers. And typically a bunch of controls that take care of the grunge work of taking input.
Given that you have to completely redesign the app to make it work as a console mode app and that you don't have experience with the language, writing this in a .NET language you have experience with is the best way to get it completed quickly.
Start with refactoring. Make sure that GUI is separated from business logic. Then add another interface to access this business logic: one that uses console, rather than GUI widgets.
Check out ncurses and readline to help you build a rich console application. You can't use them both at once, as I found out, so try ncurses if your application is more oriented toward output/display or will implement single-key interactions (hotkeys), and readline if it's more of a line-at-a-time user input situation.
Create a new project with a main
add your files
here you got a console application doing nothing. It may still create windows, or if you like, hidden windows.
Now it's up to your creativity to tie interface to existing code.
Don't forget to download and use boost::program_options to access command line parameters properly.
I am building a C++ (Qt) based application for controlling a flash based UI. Because the flash runtime leaks spectatular amounts of memory, we execute the UI as a .swf loaded in the standalone flash player separate from the command-and-control app written i C++.
The C++ starts the flash player as an external process with appropriate parameters, and communicates with it over a TCP socket connected to localhost.
The application runs primarily on Windows XP and above.
The unfortunate side effect of running the flash player standalone is that two applications are shown in the Alt+tab list as well as in the task bar on windows (one being our application, the other being the flash player). Additionally, as the application runs full screen, flash must manage the entire screen. Allowing the C++ app to draw parts of the screen would be a massive improvement.
We would like to somehow merge the two, while leaving our own application in control. I am thinking something along the lines of Google Chrome, which appears to be running each browser tab in a separate process while displaying all output in a single window.
I've been reading up in the Win32 API (and google) in order to determine if accomplishing this is even possible. Althogh so far I've come up with dll injection as the only semi-viable solution, but I would very much like to consider that plan B.
Any suggestions would be appreciated.
The Alt+Tab list shows top-level (no parent) windows that are visible and don't have the WS_EX_TOOLWINDOW extended style. So if you have two windows from two processes but you only want to see one in the Alt-Tab list (and on the task bar), then you have a few options:
Add the WS_EX_TOOLWINDOW to one of the windows.
Re-parent one of the windows to a hidden top-level window.
Re-parent one of the windows (probably the Flash player) to the other window. This is tricky, but it's probably how Chrome and many other multi-process single-window apps work. What makes it tricky is handling the lifetimes of the windows and inadvertently serializing the message queues.
I guess this question and its answers are related to your question:
Embedding Flash Player in a C++ or Java application?
DLL injection won't get you anywhere, the memory would still be allocated in your main process if you're instantiating the flash player as an in-process server.
If you want to keep control over the memory leaks you have to keep the flash player in a seperate process.
Your current approach sounds viable, your only problem seems to be that the process is still visible in something like the Alt+Tab list... as far as i recall, setting the extended window style to WS_EX_TOOLWINDOW should help you with that.
For hiding the process from the taskbar see e.g. here.