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.
Related
I am developing a virtual desktop application and have been an avid dexpot user for some time. I've been reading the Win32 documentation, specifically the CreateDesktop and SwitchDesktop functions. From what I understand, only one desktop can be viewed at a time, yet dexpot manages to show a real time view of all active desktops in its full screen preview mode. Does anyone know a way of possibly implementing this? My first idea is to rapidly switch desktops, but this would use up far too much processing power.
The most difficult part about what you want to do is application switching. You cannot move an application instance from one Desktop object to another. I would base my implementation off of remote desktop applications. There's plenty of open source clients you can look into for some ideas. I would look into the desktop duplication api as well. One idea that comes to mind is making one large desktop, locking the mouse and view to one particular region, and using desktop duplication to show all the split up regions as separate desktops. That's assuming desktop duplication works as I think it does. I'm not sure as I don't use windows.
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?
I'm actually in charge of a FIP networking c++ application, working for the first time with Embarcadero C++ Builder XE5.
The app is nearly finished, but I can't find how to implement the last feature...
I wanted to open an external Windows HyperTerminal in order to see what happen on a given COM port, for this purpose I'm using ShellExecute() to launch it from my application but it's a bit ugly since there is 2 different windows.
I was wondering if it was possible to integrate this newly opened HyperTerminal into an existing form (Panel for instance). I couldn't find nothing related excepted this =>
Delphi style, but i don't understand a byte of #mghie answer since it's delphi.
If anyone have a clue I'm really interested, even the most basic clue!
For almost all of my projects where COM port interaction is needed I use AsyncPro. The project is very well documented with a ~1000 page reference manual.
Reference Manual
Developer's Guide
For this case, the package provides a VCL terminal that simply drops onto a form. It's quite flexible with a lot of options to configure its behaviour.
I wanted something similar in past but with no success.
1.The only thing I was able to do is the exact opposite.
dock my VCL window inside another (not VCL app) but that solved my problems
If you terminal is console window then I doubt even this can be done.
anyway find handle of desired window
find handle to a dockable subcomponent
set the parent of your subwindow to it / or use manual dock
2.maybe you can do some funny stuff
like hide terminal somewhere
and continuoslly copy its graphics to your window
newer done that hide thing
but copy the contents is doable (although on windows a little unstable sometimes)
done it once to feed my App with IR-camera feed from different App
while 'focus' stays on hidden terminal it should work
also you can try to post messages to it somehow if you need the focus ...
Sorry for a vague answer but at least you see some approaches of mine
maybe someone has a better way to do this
i have my application skeleton working as expected - it might be that somebody has a good solution to what i am trying to achieve within Windows Mobile 6.5 enviroment.
Here's what i am actually trying to do:
Application running in background ( it sends periodically network packets to office server, packets are loaded with statistics data and pushed onto the server via Winsock2 and custom made protocol ).
What 'background' means here - is an application that creates a window of 0,0 size and is minimized - i am thinking about going into the services with this, but the next thing that i require stops me today from doing this.
I need this application to be 'visible' somewhere as an icon - i already know i can't do this in the 'tray' area as stated in this post:
Windows Mobile C++ Tray Icon
Now i was trying to utilize the: SHNotificationAdd - but this is ok for a 'notification' as the name says type of thing. So it popsup and you can click to hide it - this is bad.
What i need to achieve is an icon that is visible during the application run cycle, so it flashes when there is no synchronization possible, it changes the icon when synchronization is done.
I am a bit worried it can't be done - i even tried to go and code the "Home" plug-in for this purpose, but was told that some people have themes installed and it might be that my application won't be even visible to those guys.
Now as we're going to deploy it to few places around ( 3 data centers spread across the country - around 130 people smart phones only ) - i need to be sure this application is visible even when there is a theme applied or customization done.
Any chance this can be done ?
I was kinda sure it can be done with a classic 'tray icon approach' until i found that 'tray icons' are not supported for normal applications.
If there is something i can do - i would really appreciate if somebody could shed a bit of light on this for us all please.
You'll have to move to a Windows Mobile paradigm for your app, as what you're trying to do isn't possible (as you're finding). A home screen plug in has problems if the user customizes it, and you are correct that there is no "tray". The icons in the corner (battery, signal strength, etc) are reserved for OEM use only.
My recommendation would be to actually create a visible Form for your application. Maybe it shows just some simple status info like last upload time, amount of data transferred, etc.
You then use the notifications to place a user notification during "events" such as the inability to connect (replacing your "flashing icon" idea) or when synchronization is complete (replacing your "changed icon" idea).
Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme.
All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.
Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?
I agree with dual monitors or even remote debugging to reduce interfering with the messages.
I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector.
http://www.windows-spy.com/
This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen.
There is still issues with focus doing this way, but at least I can see when it repaints.
Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.
In the message include the values of the variable that you are interested in.
Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.
Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.
I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.
However this is a last resort.
Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.
Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.
If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.