I have created an MDI app based on the MFC DocView architecture in the latest version of Visual-Studio, which is working well.
However, when the application is running, and its minimised icon is displayed on the desktop TaskBar, all the open documents are displayed along side one-another. Is there a way I can get only the Document having the current Focus show on the minimised list.
(In case I am not explaining my problem properly, try opening Microsoft Word, and creating a few empty documents. Now click on the minimised Word Icon on the taskbar and you see all open documents displayed alongside each other. This is exactly what I am trying to solve. I only want one document to show up in this list. Is there a way ?)
Thanks you for your help.
Hello those Who have read or are interested in a solution to this dilemma:
I found it at:
How do you make your MDI MFC app show one instance in the TaskBar?
And it works. best wishes all.
Related
In some conditions the Windows 10's game bar opens up with my application (made with Delphi, VCL). Thats not a game and i don't directly use DirectX or OpenGL, but it opens up.
To be specific, when i reduce to tray my app and a popup is opened the Game Bar appears.
I found a numbers of sites with tutorial for totally disable the Windows 10 game bar (like this) but i want to disable for my application only, i don't think users will be happy to have a windows feature silently disabled by my app
Is this possible? I cannot find any documentation about it
You can disable it following this solution :
Press Win+G, click the Gear icon (Settings) and uncheck "Remember this is a game" (https://superuser.com/questions/1086248/windows-10-xbox-dvr-app-thinks-chrome-is-a-game).
Note that if the name of the application is Main.exe, this checkbox is not visible.
If the name of the app is main.exe or anything else, it is visible.
It seems it is stored in the registry : HKEY_CURRENT_USER\System\GameConfigStore\ in the Children and Parents directories.
You can try to find your app using the ExeParentDirectory key.
https://www.reddit.com/r/ffxiv/comments/3fbu0x/win_10_game_bardvr_anyone_having_issues/
I don't know if it applies to an executable where Windows decides it is a game (like Main.exe)
I have a confusion that MSWord is a MDI or SDI application. Looking at the Application, I do believe that it is a SDI application but there are people who strongly "believe" that its an example of MDI. After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Since all the documents have same process, it make me feel its an MDI. But at the same time, the Applications tab lists all the documents opened make methink its an SDI. What do you people think about this? Please give your valuable and detailed answers.
If you uncheck Show all documents in the taskbar in Options, Word is a classical MDI application (even Word 2010).
If you leave it checked, it's an SDI application with multiple root windows.
According to Microsoft, it is an MDI application: http://msdn.microsoft.com/en-us/library/aa263481(v=vs.60).aspx
Depending on your settings and version, it could be MDI or SDI. It is MDI in older versions and if you use the "Show all documents in taskbar" option; otherwise, it is SDI.
Honestly, I didn't realize this part myself, until I tested:
After using the Taskmanager in windows, the Applications tab list all all the instances of the Documents currently opened. However there is only one process in the Processes tab.
Thank you and +1 on the post. On exploring further, I found something that might shed light further. I am using 2007, but I guess it would apply for 2010 as well. I clicked on the Control Menu (the small menu that pops up when you click on the Icon on the top left corner - used to be called Control Menu, before Microsoft decided to redraw its interface). You would find a "Word Options" button. Click on it, in the dialog that pops up after that, go to "Advanced" tab. Scroll down to the "Display" section. Locate the "Show all windows in the Taskbar" check box, I guess it will be checked. Uncheck it. You would see that there are no multiple windows (corresponding to each document) anymore. Also, in Task Manager, you will see only one instance even in the Applications Tab.
With this, I strongly believe Word is still an MDI. Oh by the way, if you want to see every document opened after you change these "Advanced" options, you might want to go to View menu and and chose "View side by side" option.
I came across some more info regarding this from Chris Ryan which I am sharing here:
It depends on what you mean by MDI.
MS-Word does have multiple documents and an interface but it does not fit the classic definition of an MDI application because it does not use an MDICLIENT window class to manage the child frames.
For an example of an MDICLIENT, see:
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/MDIDemo.c .
ftp://ftp.charlespetzold.com/ProgWin5/Chap19/MDIDemo/Release/MDIDemo.exe
Even the older versions of Word and Excel that had the child windows inside the main frame, were technically not MDI. They looked like it but they did not use MDICLIENT. MS used a proprietary windowing library called Software Dialog Manager. SDM was used so a common application code base could be used on multiple platforms: Windows, OS/2, & Mac. All they had to do was recompile for that platform and link a platform specific SDM library.
This link talks a little about SDM but does not mention MDICLIENT
http://msdn.microsoft.com/en-us/library/windows/desktop/dd317997(v=vs.85).aspx
I'm wondering if there's a way to reliably retrieve all open VALID windows in all spaces?
The problem I'm encountering now is that on programs like Microsoft Word for Mac there are lots of child windows, resulting in my list being muddied by blank windows with no title, or windows that just don't lead anywhere. For example, for Word I'm getting these 3 windows when I only have 1 document open:
Document 1
Microsoft Word
Desktop
All are from Microsoft Word, and same goes for Excel and Powerpoint, the problem seems to be pretty exclusive to the Microsoft Office suite. Any ideas on how to deal with windows that don't actually have anything?
You can try to correlate with Accessibility (you don't mention how you're getting the window list right now), or just use some heuristics (ignore windows with no title, no workspace number, look at the window tag bits, etc.). Pull up the window list in Quartz Debug, browse around and you'll see some differences. If the window is visible, you can also hold down Control-Option with Quartz Debug in the background to get a pop up HUD with some more detailed information about the window underneath the cursor.
If you're really desperate you could grab the window contents and see if they're all transparent or white.
I have a desktop application written in Ruby that is using GTK2. It's just a small test application to play with GTK2, but I'm having problems achieving what I want to do. Is there any way using GTK2 to get at the titlebar (apart from setting the title), specifically to either add a button to it (beside the min/max/etc, B in the below diagram) or to add an option to the menu that pops up when you click the icon on the titlebar (A in the below diagram)?
I'm thinking there might not be because GTK is meant to work with many many different window managers, but I just wondered if there was. As a side question, what event does clicking the 'cross' button fire? At the moment if the user clicks that the window disappears but the program doesn't end - I need to capture that event and quit the program.
Thanks for any help, including hitting me over the head and telling me how silly I am.
Note that this is possible in GTK 3.10 and up, by using gtk_window_set_titlebar(). It replaces the window manager's title bar with a custom one. GtkHeaderBar is a good custom title bar class to use.
You can't, however, make it look just like the window manager would, because you won't know which window manager the user is running.
No, the title bar is owned by the window manager and you will typically not have direct access to it.
When the user tries to close the window by clicking the window manager's button, the window will receive the delete event.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.