I was wondering, would it be possible to create a small piece of software that would allow the user to minimize a window by scrolling down on it? (on the top part that can be used to move it via drag and drop, obviously).
Following the same idea, it would be cool to be able to scroll up on the task bar icons to restore a minimized windows. I thought it would be cool (and since the user does not actually click but scrolls instead, it would prevent accidental nearby program openings when trying to restore a window)!
I am a total newbie when it comes to things like these. Could you please indicate me:
if Windows would let me do that (I doubt it wouldn't)?
How to code something like that (what language, and so on...)?
A way of doing this for maximizing the tabs open in the taskbar would be to create a custom taskbar identical to that of the main one. The second taskbar from Dual Monitor Taskbar works this way. There are also libraries in languages such as C++ which can detect scroll wheel movements.
Although this wasn't the most helpful answer, hopefully this could give you some ideas.
It is definitely possible. I found a software that does that 6 years ago and I have been using it ever since. It is called Preme for windows (http://www.premeforwindows.com/)
I have been using the software for about 6 years now and I cannot use windows without it. It also allows closing windows when clicking the mouse scroll key and maximizing a window with scroll up.
I hope this helps you. I am always wondering why Microsoft does have these options built in in the OS!!
Related
I would like to be able to stop windows from being dragged past the border of the screen. For example, open a window that is not maximized, click the top bar with the mouse and drag the window wherever you want. Now drag the window to the left/right/top/bottom of your screen and notice that part of the window goes off screen. I would like the window to bump up against the edge of the screen and go no further.
In the same way the cursor can't go over the edge on the left side, I would like to make a barrier so windows can't move over it either.
The main reason for doing this is because I am making a batch program in which I need it to not go off screen. This is annoying and I was hoping that someone here could be of some help.
Sorry if this is an obvious question, I tried a few searches but had no idea what terms to look up.
Thanks for any help in advance!
Sorry for the late response (I was researching this), but here is the answer:
There is no current way to do this easily. I'm sure you can edit windows src code and add that property, but the language it is made in is not in batch and it would be EXTREMELY hard to edit these files :(
Also, this would affect all windows, not only that specific program, meaning no easy shortcut for split screen. So no, you cannot do this.
On Windows 10 you can simply move a window near the edge of the screen and it will auto-fit on screen. You can also use shortcuts to do this. [Windows key] + [arrow left] or [arrow right]
you were able to change a setting in windows 7 to prevent this. I know that this is a feature if you are using multiple monitors but if using only one monitor there should be a way to change a setting. thank you Microsoft once again for making our lives complicated. the more you guy release a new windows the harder it is to use.
Finally i found real solution for this.
I was searching a real solution for my application.
There are many tricks but using reg we need to restart computer.
You can disable it from powershell. You need to call this file from your code.
Here is link.
Check download file at bottom called "DisableAeroSnap.ps1"
https://michlstechblog.info/blog/windows-disable-aerosnap-automatically-window-arranging-and-resizing-while-dragging/#more-951
I've used ObjectDock in the past to replace the taskbar for a number of reasons. I had to reinstall Windows and apparently now ObjectDock is no longer free. One main reason I liked ObjectDock is because it completley replaces the taskbar, hiding the taskbar completely, not just autohiding it or hiding it till moving my mouse to the bottom, but actually completely removing it.
So clearly there is some way to hide it or move it so it doesn't show up in some way, but I've yet to find anything online that shows a way within Windows 7 or a programmatic way to do so. I've got most of my programs linked to hotkeys through AutoHotkey, and since my resolution is small I'd like the extra space.
Try using either Taskbar Eliminator or The Ultimate Windows Tweaker. They should allow you to remove it, this should remove it for you.
My manager thinks he's seen other people "lock" the windows on screen keyboard to the bottom of their applications, effectively docking it with their window, and wants me to reproduce this. They're using vb6 and occasionally vb.net.
I've done a good amount of googling on the subject and I'm resorting to looking into the windows SDK at the minute, but if someone out there can save me a few days of pain by either confirming that it's not possible or pointing me in the right direction if it is I'd appreciate it.
I find that the keyboard locks if I open it from the taskbar icon. It will stay on the bottom of the screen then, even if I'm not on a text field.
No idea how to achieve that programmatically though
I just used this feature for the first time - in MS One Note 2010, click on the "Dock to Desktop" button.
The application then literally docks itself to the bottom of the screen. If a window is maximized above it, that window will not overlap or underlap it - the One Note window has become similar to the task bar in terms of its fixed usage of screen real estate.
Come to think of it, I've seen this one other place: the Windows 7 magnifier.
I'm curious to know how this is pulled off? Is it a window attribute that can be applied in a WinForms app or might I have to use the Windows API/C++ to do it? Or is it even trickier than that?
It probably uses SHAppBarMessage; example & a vb6 article simply because it has an illustration.
http://msdn.microsoft.com/en-us/library/cc144177(VS.85).aspx
You will probably have a lot of trouble doing this with WinForms, but it might be possible -- probably, you'll have to do a lot of low level WinAPI stuff with PInvoke to make it work.
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.