DAY 012: _MOUSEMOVE

[mnrvovrfc]

It's just a PITA to have to remember to swap over from row, column coordinates to width, height coordinates.  Honestly, I think this may have been some sort of oversight when the code was originally written, but it's too late to change it now.  Who knows how much old code might be broken by the swap?   For better or worse, _MOUSEMOVE now will always run in width, height coordinates -- even in SCREEN 0 screens where we normally think in terms of row, column.

Be aware of this backwards coordinate system and don't like it bit you on the hiney, if you're ever coding in SCREEN 0.  It's just one small aspect of an otherwise simple command to always keep in the back of your mind when working with it. 

Whoever created this statement, if not Galleon belonged to the "old school" of being "married" to SCREEN 0 and being less keen about graphics screen on their very slow 16-bit systems. I'm still seeing "SCREEN 9" and such around here, that's what I mean. Because "LOCATE" enforces so much by character position, in SCREEN 0 then any other command is expected to be limited along those guidelines. In fact, the order of (X,Y) coordinates is wrong for "_MOUSEMOVE", it should be row then column, like "LOCATE".

If "_MOUSEMOVE" is to be fixed then you guys would have to fix "_NEWIMAGE()" as well; I think this is the real barrier.

Remember in the 1980's that "mouse support" had to be enabled through a driver that M$ wrote, and a version of it was supplied for Borland language products. The mouse was an afterthought until people caught on to Macintosh OS and Windows being slicker than MS-DOS and learning as many keystroke shortcuts as possible LOL like it had to be done with Wordstar, WordPerfect, Lotus123 and many other office apps back in the day.