CAD Forum

Someone on the Swamp was complaining recently about multiple monitor support for SW. Basically (as far as I know) the only real "support" there is for multiple monitors is the "span" button that will spread the main SW application across two monitors and the little left and right buttons on the individual windows. Both of these things really only support 2 monitors. Additionally, clicking on the little left and right buttons actually activates the window, taking extra processing time.

Attached is a macro that uses Windows API to move the window under the mouse cursor to the left or right. It moves any window, not just the active one. It reads the size of your SW window and determines which monitors SW is actually displayed on. If SW is spanned across more than two monitors (there's no upper limit) it will divide the space up and move windows left or right. If SW is only displayed on a single monitor, it will split the working area in half (or more, depending on a constant at the top of the code). If the window is already as far as it can go in the chosen direction, it will instead maximize the window across the whole working space. It is super fast because it just uses Windows API, it does NOT activate the window.

I have used a version of this for years because it's so much faster and easier to use, both from the actual speed of execution and the ease of activating it. No clicky-clicky on a tiny button.

This also gives you a leeetle more modeling space, because it intentionally oversizes each window by a small amount (9px I believe) so that the window border is outside the working space.

This macro has to be mapped to a shortcut key. If you try to map it to a toolbar button then your mouse will not be over a window, so nothing will move. If you try to map it to a mouse gesture it will sort-of work, except that mouse gestures only work if the mouse is over the active window. This negates a main benefit of this macro which is that it works on active or inactive windows.

I have found that the most useful thing is to map the macro to my fwd and back mouse buttons. This is easy to do if you have a Logitech or other type of mouse that has application-specific settings. Since SW doesn't use the fwd and back buttons for anything, you can use the mouse driver to map them to shortcut keys for SW only.

However, this is a little limiting if you have multiple different mice, or if your mouse (like my ergonomic mouse) doesn't have software for mapping those buttons. So, I've attached another file. This one is an EXE file that was made using AutoHotKey. All it does is re-map the fwd and back buttons for SW only to Ctrl+Shift+L and Ctrl+Shift+R. You can drop this EXE file into your Startup folder and it will load up whenever you start Windows. If you already use AHK, here is the entire script that generated the .exe:

Just got this configured on my machine and it works just as described. It doesn't seem to re-draw the border when a full-size window is moved left or right, but besides that slight graphical oddity this is likely something I'll use in my modeling.

Thanks Josh, you continually provide some cool stuff!

I tried setting up SW across multiple windows when I first started using it, but gave up quickly because it didn't do what I wanted it to do. I will have to give your macro a try.

AlexB wrote: ↑Mon Aug 08, 2022 9:47 am Just got this configured on my machine and it works just as described. It doesn't seem to re-draw the border when a full-size window is moved left or right, but besides that slight graphical oddity this is likely something I'll use in my modeling.

Thanks Josh, you continually provide some cool stuff!

Ah yes, I forgot to mention that. If a window is in the true maximized state (where it doesn't have its own title bar or any border), then using the Win API to force it to a new location makes it a little glitchy graphically. Due to that, I just always work in the non-maximized state and I forgot to mention that. If you maximize by sending a window all the way left or right and then sending once more instead of hitting the maximize button on the window then it will not glitch. I should probably dig more into the Win API to figure out if the window is in the true maximized state and then properly tell it to Restore before moving the window.

I had also looked into the possibility of un-docking the Command Manager and/or other toolbars and moving those along with the window so that you could model exactly the same no matter where you are on the SW interface. However, (1) it was a little tricky and (2) I don't use the Command Manager at all and rarely use the toolbars (almost all keyboard shortcuts and S-key menu) so I didn't feel like it was worth the effort. If there are a lot of folks that would benefit from that I may look into it some more.

josh wrote: ↑Mon Aug 08, 2022 10:37 am ....(2) I don't use the Command Manager at all and rarely use the toolbars (almost all keyboard shortcuts and S-key menu)...

Off topic, but I would like to see/hear more about this. I try to keyboard my way around the command managers but I'm not doing very good. For example, in the selection boxes, sometimes pressing delete key will remove the selected object from the list, sometimes I have to right click and delete/remove.

josh wrote: ↑Mon Aug 08, 2022 10:37 am Ah yes, I forgot to mention that. If a window is in the true maximized state (where it doesn't have its own title bar or any border), then using the Win API to force it to a new location makes it a little glitchy graphically. Due to that, I just always work in the non-maximized state and I forgot to mention that. If you maximize by sending a window all the way left or right and then sending once more instead of hitting the maximize button on the window then it will not glitch. I should probably dig more into the Win API to figure out if the window is in the true maximized state and then properly tell it to Restore before moving the window.

I had also looked into the possibility of un-docking the Command Manager and/or other toolbars and moving those along with the window so that you could model exactly the same no matter where you are on the SW interface. However, (1) it was a little tricky and (2) I don't use the Command Manager at all and rarely use the toolbars (almost all keyboard shortcuts and S-key menu) so I didn't feel like it was worth the effort. If there are a lot of folks that would benefit from that I may look into it some more.

I don't have a need for you to dig further into it, not sure about others though. I appreciate the work you put in to get this much figured out.

bnemec wrote: ↑Mon Aug 08, 2022 10:59 am Off topic, but I would like to see/hear more about this. I try to keyboard my way around the command managers but I'm not doing very good. For example, in the selection boxes, sometimes pressing delete key will remove the selected object from the list, sometimes I have to right click and delete/remove.

I think you may be getting the Command manager and Property Manager mixed up...
Property Managers are the "feature edit" type things that pop up on top of the Feature Manager. It is indeed un-dockable as below, but I have never seen any purpose at all in doing that.
The Command Manager is a sort of context-sensitive toolbar grouping thing that has customizable tabs on it: Un-docked Command Manager: As I said, I don't use the command manager at all, or really much of any toolbars, but any toolbar can be un-docked and moved around the screen.

josh wrote: ↑Mon Aug 08, 2022 11:36 am I think you may be getting the Command manager and Property Manager mixed up...

My mistake. Thanks for clarifying.

I'm still learning the names for things; it seems every system has variations of the same things but gives them different names.

Here's an updated version. Changes:
It supports differently-sized or aligned monitors in the vertical direction, or any portion of the SW window off the viewable area. If some of the SW window is off the viewable area of the target monitor, the macro will compensate for that and not re-size the document window outside the viewable area. This is useful if your secondary monitor is not the same size as your primary.

It supports sending windows directly to up to 5 different monitors instead of having to send left/right multiple times. If you try to send to a monitor that doesn't exist, it just sends to the last monitor. Here's how you set up to send directly to certain monitors: Fixes the glitch with maximized document windows.

Again, this has to be set up with keyboard shortcuts rather than SW's built in mouse gestures because it operates on the window that's currently under the mouse, not the active window. This is intentional to avoid the performance hit of activating windows you don't want as you toss them back and forth.

Dropping by to say a big thanks!
I had the macro downloaded months ago but dint manage to try it until recently...

The oversize window really make a huge difference to me