Apologies if this isn't the right place to ask about LibreOffice, but I didn't see another site more appropriate.
If I have two LibreOffice documents open simultaneously with one overlapping the other, I find that floating my mouse pointer over the toolbar buttons in the background window (without clicking) brings that window to the foreground, covering the document I was trying to work with. But the focus doesn't change. If I type, those characters are typed into the now-in-back document window, not the one on front. It's super-annoying.
Is this a setting that I can disable? Usually, it's the window-manager that is in charge of raising windows, but LO seems to be doing it by itself.
When neither of the two document-windows has the focus (e.g. a web browser or whatever is in the foreground), the LO windows still behave the same way, but they do not come to the foreground... they just swap their foreground/background position relative to each other.
This is on LibreOffice 7.4.5.1, but it was happening with whatever version I just upgraded from as well (I upgraded to see if this was "fixed"). It was probably 7.2.something. I'm on x86-84 MacOS Ventura.
Related
I get list of windows with Win32.EnumWindows and then filter them to keep the ones I want. I want to keep the normal, visible Skype window and skip the hidden Microsoft Edge window. (I use Chrome, and no accessible instances of Edge are visible in my Alt-TAB output or on my screen.)
I already filter out a few Edge windows that are of class Windows.UI.Core.CoreWindow but there is one Edge window still in the list. Maybe it is a main or parent window or something? Maybe the Task Manager window or the Settings windows that I have open are Edge underneath the hood?
I dumped the properties of both Skype and Edge windows, and they are the same for the items that I looked at. (I recognize that having WS_VISIBLE set does not mean that I get to see the window.) Here are the items that are identical for both windows.
Skype window: (Identical to the output for the Edge window that I can't see.)
Is visible.
Has no owner.
Has no parent.
Is not APPWIN.
Is not a toolwindow.
Is not a cloaked store window.
Class is ApplicationFrameWindow
Could anyone give me an answer on how to identify the Edge window (other than by using its name as a special case in the code) as distinct from the Skype window? Or maybe point me to a web article that I haven't seen yet? (I have looked at a dozen or so, without success.) Thank you.
Thank you everyone for your help. I ended up using the window titles because I found that there were several windows on my list that did not show up in the normal Alt-TAB display. Special cases were always required (on the net examples) to remove them from the list to help match the normal Alt-TAB display. Once I accepted the need for special cases, then using the title was the easiest way for these two windows.
I also learned that Microsoft Edge (and probably other apps too) start-up some background processes and windows even if you are not using them. Someone on the net said that you could disable these background processes in Settings, so I did that to get rid of some unwanted windows on my Alt-TAB (or nearly Alt-TAB) list.
I am currently researching how to spot windows (like Edge and Settings) that have IS_VISIBLE windows (that you can't see, but that have all the attributes mentioned earlier in the original question) attached to background processes that don't show up in the Apps list in the Task Manager.
Very strange. The OS obviously knows how to spot those windows and keep them out of the Task Manager Apps list and the Alt-TAB display. I wish I knew how to do it. Maybe the answer lies with processes, as Rita said earlier (but I didn't see any example of that method in my net research). Even Raymond Chen's famous method of walking ancestors does not produce the right answer that matches the Alt-TAB display.
I recently upgraded to a dual monitor setup at work, and while the extra real estate is very nice, there's one annoyance: my intuitive reaction is that there are two "active" windows now, namely the topmost window in each monitor -- and I frequently get surprised when keyboard events go to the actual active window, rather than the one I've moused over and am looking at.
There's a setting in the control panel that gives this effect (ease of access -> make the mouse easier to use -> activate a window by hovering over it with the mouse) but it also acts on windows within the same monitor, which I don't want.
I frequently use my ThinkPad's scrolling function on unfocused windows which I don't want to receive focus, which come to think of it probably adds to my confusion, since I can scroll my email in the other window but my keyboard shortcuts don't go there.
Is there any way to achieve this effect or am I just wishing?
Thanks,
Ryan
Yeah, get a Mac :-p
In all seriousness OS X does provide this functionality. It might be worth searching for an add on that does the same sort of thing. I know of Wizmouse -- http://antibody-software.com/web/software/software/wizmouse-makes-your-mouse-wheel-work-on-the-window-under-the-mouse/
There might be more though.
AT LAST!!! Windows 10 has this support :-)
SM
You can change the settings to use classic windows appearance etc. and try to focus on the border color of the window. The board changes on the active window.
I use two monitors and there really isn't much you can do besides change your behavior.
Select things from the taskbar, drag active windows to the same screen and always refer to inactive windows by moving them to the inactive windows monitor and remember to go back to the window you want to be active.
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.
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.
I'm a fairly recent convert to Xcode and OS X. Even though I have two large monitors it feels likes I spend far to much time hunting for windows.
I typically have at least the following windows open:
The file I'm editing.
A matching header file.
Another source file.
API Documentation.
A browser window.
It seems like whatever I want next is always underneath something else. There are lots of ways to switch windows (e.g., Exposé, Spaces, OS X hotkeys, Xcode hotkeys), but that's part of the problem. There are so many different approaches, I can't blindly use one; I have to think about which is the right one for each situation.
How do you organize your Xcode windows so you aren't switching all the time?
Or, how do you effectively switch between windows?
I prefer all-in-one layout (Xcode's preferences->General). If I need to look at several files simultaneously, I split the editor view (the little button above the vertical scroller). I also constantly use Cmd-Option-UpArrow to switch between .h and .m files. The only other window I have is the documentation browser.
I have a dedicated Space for Xcode so that I can switch between Xcode and Safari with a shortcut.
Xcode is unbelievably customizable, though many options are well hidden.
I keep the main XCode window open and the documentation open slightly askew from each other horizontally so i can click one while the other is on top. I use the button (right next to the lock icon) which opens the associated file to toggle in-betweeen the h and m files.
I use expose and keep safari in another panel.