Cannot resize or move SpaceMonger window

[ppass]

I use a small software called Gridmove (available at donationcoder.com) that is very useful to resize-move the active window on the screen, based on a pre-defined grid. This is very useful especially using dual monitors.

However, SpaceMonger is the only piece of software that I know of that refuses to resize or to be moved around. Could you remove this limitation? What exactly do you fear that leads you to lock free resize/move actions?

[seanw]

I use a small software called Gridmove (available at donationcoder.com) that is very useful to resize-move the active window on the screen, based on a pre-defined grid. This is very useful especially using dual monitors.

However, SpaceMonger is the only piece of software that I know of that refuses to resize or to be moved around. Could you remove this limitation? What exactly do you fear that leads you to lock free resize/move actions?

It's not that there's anything that the code fears.

There were several issues that I ran into that the current code addresses. On Windows 95/98/ME, there are major problems with the functioning of the USER subsystem, which manages windows and window layouts. I ran into bug after bug after bug on those systems. And the implementation of the WM_NC* messages --- everything related to the window frame --- was surprisingly unreliable too:

• For example, SpaceMonger implements a specialized message-processing loop to allow it to perform timed activities more reliably than Windows' timers normally allow; this lets it not only do animation, but provides much of the inter-thread communication model as well. But Win9x expects applications to use a standard message loop, and on Win98 and WinME, the early SpaceMonger 2.1 alphas would crash the entire system as soon as you moused over the X button in the upper corner of the window: Windows would send through messages to display a tooltip over the X button, and those messages wouldn't arrive as fast as Windows expected them, and it would simply crash USER, locking the system, or in some cases, yield a full BSOD.
• On Windows XP, they added WM_MOUSELEAVE, but previous versions of Windows don't have it or anything like it, and it's incredibly difficult to simulate without using mouse capturing. This message is incredibly useful for UI code, and should have been added in Windows 2.0 (X-Windows has had it since 1986). Problem is: Mouse capturing doesn't work with nonclient areas of the window, so the standard Windows window borders would cause the enter/leave simulation code to fail.

There was no way to get around these problems and still use the standard window borders ("nonclient area"), so it uses a custom window-border that tries to look similar enough to the standard window paint to fool you into thinking it's the real thing, but it isn't.

I've never been 100% satisfied with the solution, and on WinXP and later it's at least theoretically possible to do it without the ugly Win9x solution, but it takes a lot of code to swap out window-management depending on which OS we're running. It's possible to make SM use the native borders, but it's a hell of a lot of code. I'd like to add it to a future version, but it's a lot of time and energy that's fairly low-priority right now.

_______________________________________


TL;DR version: SM uses its own window borders for solid technical reasons, and those currently aren't compatible with third-party applications.

[ppass]

I understand your detailed explanation. I will try to live with it. It just feels strange that of all my programs, only SpaceMonger has this peculiar behaviour. But nothing serious enough to rewrite code...

[CobraA1]

Is the 9x platform still popular enough to warrant support for it? It seems these days, it's all about XP and Vista, with some Windows 2000 stragglers. I know most of the software I use simply has no support for the 9x platform anymore. I wouldn't be surprised if many of the reasons you've listed are reasons they stopped supporting the 9x platform.

I have no idea what your customer base is, but if 9x usage is less than 1%, perhaps it's time to consider dropping support?

[seanw]

I would characterize Win9x (mostly Win98) as about 5%, about the same amount as Vista, based largely on the visitors to our web site (we have no way of knowing for sure what OS you're running SM on, but the web site hits are a decent indicator). Most people have moved up to (or stuck to) WinXP, and a lot more software is dropping Win9x support these days, so you make a passable argument. (Certainly ensuring Win9x compatibility is a pain in a system-level app like this, and you wouldn't believe what I had to do in some places to make it run acceptably.)

But still, five percent is five percent; some people are using Win9x, and I don't know if I can completely justify dropping Win9x support altogether. But maybe by the time the next version of SM is ready, that'll be a moot point.