Hi Przemek,
> I do not know what is K_MMLEFTDOWN, K_MMRIGHTDOWN, K_MMMIDDLEDOWN > and K_NCMOUSEMOVE. It's Harbour extension and I've never seen any > description for this inkey mouse value. I thought that the first 3 ones describes some extended mouse buttons but I do not have it. > Clipper does not support such values. > The behavior of K_MBUTTONDOWN, K_MBUTTONUP, K_MDBLCLK is exactly > as it should be and it's the same as K_[LR]BUTTONDOWN, K_[LR]BUTTONUP > and K_[LR]DBLCLK in GTXWC and CL53. If you used some GT dirver which > does not work like CL53 then it should be fixed. To be honest I started using the mouse with Harbour, so I didn't even check if these aren't C5.3 events. I should have. Thanks for the clarification. K_MDBCLK is randomly generated while keeping the middle button pressed and moving the mouse, with GTXWC. This may count as a bug. The uglier thing is that these ones: #define K_MMLEFTDOWN 1011 /* Mouse Move Left Down */ #define K_MMRIGHTDOWN 1012 /* Mouse Move Right Down */ #define K_MMMIDDLEDOWN 1013 /* Mouse Move Middle Down */ will be generated instead of K_MOUSEMOVE, which makes it impossible to write portable code between GTs, and it also breaks C5.3 compatibility I believe. At least there should be a way to mask these out, just like the other 2 x 3 events: INKEY_MMIDDLE and INKEY_MWHEEL, with "INKEY_MMDOWN" or similar. We have an incompatibility here, and this might solve it. What do you think? On the other hand, it would nice to add proper support for these extensions where possible, and if enabled. GTWIN also don't support these, but that's less important. [ This is one reason why it's wiser to mark extensions as such... Now I've found and extension the hard way. ] Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
