Programmatically duplicating the desktop on Windows 10 - c++

I've been looking into ways to programmatically manage my monitors using C++.
It looks like functions like EnumDisplayDevices, EnumDisplaySettings and ChangeDisplaySettings can be used to, e.g., change the resolution of individual display devices and attaching/detaching said devices to/from the desktop.
In addition to these operations, I want to be able to duplicate my desktop to multiple monitors.
A concrete example would be to go from this setup where the desktop spans two devices...
...to this setup, where the desktop is instead duplicated to said devices.
I have tried investigating the APIs on MSDN, and looking for similar questions, but cannot seem to find any indication as to whether or not this is possible to do.
Is it possible to use C++ to duplicate my desktop to multiple display devices, and if so, how? If not, is it then possible to do it some other way, e.g. using another programming language, or am I forced to use options like the Windows Control Panel to change such settings?

SetDisplayConfig and DISPLAYCONFIG_TOPOLOGY_CLONE
Here's a PAQ w/code using this function to switch to extended mode.

Related

Container for precompiled GUI Blocks

so here's my problem. I have a (large and growing) set of single-window applications written in C++ with a QT GUI. Basically each of these programs is used to connect with a different hardware device and consists of a couple of input parameters and a "Connect Button" and is around 300x400px in size.
Note: I can access, modify and compile these applications.
What I want now is another (QT) application that allows me combine multiple of those applications above into a single window. I'm thinking like an "Add new Device"-button where I can select one of the existing applications and then it's added to the 'container'.
I don't want to have duplicate code, so I don't want to copy the code from all the applications and include it to one large application. All the application logic should remain within those little programs. Then I want to compile them and only provide those compiled files to the Container-Applications.
Is there a design pattern for something like that? Is there a way to have a common base ui-class (implementing QWindow or something like that) to achieve this behavior with QT?
Thanks in advance. Kind regards

How to Skin an Win32 Application

Win32 look nasty, how to make it look better by custom skins?
I mean something like Adobe products, iTunes, Autodesk 3dsmax and Softimage XSI, Windows media player, Blender, Comodo firewall, Winamp, Babylon client, and few download managers etc.;
there are many similar applications out there but I can't find any proper tutorial or guideline, it looks like secret recipe!
only -two- tutorials available online:
old and useless: http://www.codeproject.com/Articles/20497/Draw-Skin-Window-Using-Pure-Win32-API
only cover opaque background (and this is what I avoid, I need more about GUI components):
http://www.flipcode.com/archives/Win32_Window_Skinning.shtml
Is there any book or proper guideline to learn how to build skins for Win32api?
Edit: I accept David Rodríguez comment, down there ↓↓
I have done this before using C++ Builder. The approach I took was to create a form, set it to be borderless and color the entire form the same color. Then I set the form transparency to this color. I then add images to the form which create the desired skin.
I'm sure this can all be done through standard win APIs, but I can't describe (or advise) doing it solely through API calls.
The operating system handles "skinning" for you automatically.
In "classic" mode (or Windows 2000 and earlier versions), this gets you a, well classic-looking interface. The windows are drawn just like they always were since Windows 95. Presumably, this is what you are referring to when you say that "Win32 look nasty". However, you need to realize that many people like this look and specifically choose to enable it on their machines. [WARNING: Personal opinion coming up!] I'm one of those people, and judging from the screenshots that get posted here from developers' machines, I'm definitely not the only one.
Windows XP actually introducing the "skinning" or theming engine, which lives in a set of Windows DLLs. By explicitly linking to version 6 of ComCtl32.dll, your application would automatically get these visual effects. Some people said this version of Windows looked "Fisher-Price", while others were perfectly happy with the term "gaudy". The option was retained to allow the user to switch to the "classic" theme (as described above), if desired.
Windows Vista completely overhauled Windows's theming engine and introduced a new UI known as "Aero". This provides flashy-looking windows and controls, complete with transparency effects—that is, as long as your graphics card supports it. Again, by explicitly linking to version 6 of ComCtl32.dll, your application would automatically get all of these styles applied.
It's worth noting that through all of this, Microsoft has provided users with the ability to customize the colors (and fonts and other things) used in the user interface. For example, Aero defaults to blue. If you don't like blue, you can change it. I change my UI colors periodically for fun and to re-energize myself. If you can't read or don't like the font, you change it, too.
Thus, if you choose to do something different with your application, defining your own custom color palette and ignoring the options chosen by the user through the provided customization interface, your app is going to look broken and stick out like a sore thumb on the user's desktop. When designing a UI, the last thing you want to do is to be or look different.
In short, upgrade your computer to Windows Vista or later and enable the Aero interface if you want flashy. Don't override the user or try to custom draw all of your controls. You'll just end up with an application that is hard to use, doesn't work as expected, is a pain in the rear to maintain, and just generally looks worse than if you'd simply left it alone.

What's the easiest way to find a given control in a external program's window?

What is the best way for, using WinApi, find a given control in a external program window?
For example, I'm trying to change Internet Explorer's url text box. I am having trouble getting programatically the handle to the text box. I know its type is "Edit" but I'd like to avoid having to search through all the child windows for the "Edit" control (that's how I'm currently doing).
Is there any kind of unique identifier for a given control on a window? I tried using "Control ID" but it doesn't seem to be working.
Thanks
When you're delving into the windows of another application that wasn't designed to give you any particular special access to its windows, then you don't really have any simple solution. Functions like FindWindowEx, GetWindow, EnumChildWindows, and the rest are what you have to work with.
However, it's often not a great idea to even do this. Internet Explorer may have certain types of windows in a certain hierarchy in the particular version that you're developing against right now. But those windows and hierarchy may be different in previous versions and could be considerably different in future versions. You have no guarantee about these things.
In some cases, you might do well to investigate if there are alternative and more official ways to control the other program. For instance, Internet Explorer exposes a COM object that can be used for many purposes. Because this is an official interface, you have better guarantees about what previous versions this will be supported on and that it won't break for future versions.
The best way to do it is find it step by step.. E.g. Find the IE window with FindWindow, then find the child of that with FindWindowEx, then find the child of that with FindWindowEx ... until you get down to the textbox.
There is 1 program I can think of that will generate VB code from dragging a icon from the application to any part of any other application.. VB is way old but it'll give you a very good idea how to do it!
It's called API Spy, found under 'Downloadable Applications (Windows Only)' on http://patorjk.com/blog/software/

File preview component (C++/MFC)

Is anyone aware of a good, general purpose file preview component for MFC/C++ desktop applications?
Specifically, I'm looking for a component that I could embed in my application that would allow a broad range of file types (text files, multimedia, etc.) to be previewed without the need for original applications (such as MS Word, etc.) to be installed.
I could only find one, via Google:
http://www.file-viewer-sdk.com/
Unfortunately, these folks want $60k for unlimited redistribution, which is outside of our budget.
Anyone have any recommendations? If not a component, is anyone using another general-purpose strategy that works well for them?
You can write your own shell preview host once you know the interfaces.
You might want to check out Autovue, originally made by Cimmetry since acquired by Oracle
.
Our product makes limited use of their SDK to do some document conversions (Mostly RTF->PS) and that works well enough for us.

Map plugin for an MFC application

I want to display a map in a MFC application (Visual Studo 2008 with MFC Feature Pack).
Off the top of my head I have the following requirements:
I have to be able to add my own markers (plain lat/lon positions), preferrably with different colors/icons so one can distinguish between different types of markers.
If the map data is fetched from an online source, it has to be cache-able, i.e. I can pre-load maps for an area at a certain (or several) zoom-level(s) and then switch to "offline mode". Alternatively all map data is installed together with the application.
The standard operations like zoom in/out and pan should be possible for the user.
The user has to be able to select my markers, preferably by dragging a rectangle around them.
Since the whole app is written in C++/MFC I don't want to have to use the .NET runtime for this plugin.
It shouldn't cost a fortune.
I am currently using an ActiveX plugin called "ESRI MapObjects LT2" which can do all that in some way but it's very tedious to implement, the development seems to have stopped around the time when Visual Studio 6 was available and map material is either very basic or very expensive.
I thought about using Google Maps or Google Earth but I think they don't really support being used by non-web based applications.
I found ArcView to be some sort of successor of the plugin I use currently but I don't think I belong to the target audience since the functionality it offers is way more than what I need. Also I didn't find any information on pricing.
I have written an open-source Geocaching app ( it's in c++ ) that renders maps, the source is at:
http://code.google.com/p/gpsturbo/
It uses my own custom rendering but you could rip out the map parsing if you want. It renders map using google tiles ( and caches the tiles for offline use), as well as Garmin format GPS maps, there is also an Openstreetmap format renderer as well.
Reconsider google if you have internet access. You can make an instance of the IE browser appear in a frame within your application. I believe you can use an ActiveX control. Also Google Earth has a way to embed itself into a web page, and possibly an application as well.
Another option is Global Mapper which is not anywhere near as nice as Google Maps or Google Earth.
We used ESRI for a long time before abandoning it due to a lack of performance and lack of support. It was such a big pain to pay $10k for a license, and then be told they need $2k more so that we can actually use the thing. Oh, and then $2k more to add some extra functionality. Even when it didn't work, their support was dismal to lack-luster.
If you are not bound to Google Maps, you could choose OpenStreetMap.
There are couple of known applications for rendering OSM maps:
http://wiki.openstreetmap.org/wiki/Cobra
Kosmos
osmclient (on SourceForge)
First two render map directly, last one uses OpenStreetMap.org tiles.
You can cache as many tiles or data as you want, you are not restricted to do so.