On Tue, 17 Feb 2009, Szak�ts Viktor wrote:
Hi Viktor,
> K_MDBCLK is randomly generated while keeping the middle button
> pressed and moving the mouse, with GTXWC. This may count as a bug.
I've just tested it using tests/gtkeys and it works correctly just
like LEFT and RIGHT buttons. I tested it with GTXWC and GTTRM and
PTerm (XTerm emulator from PuTTY for *nixes).
If it does not work for you then probably it's a problem with mouse
driver or side effect of some features like enabled middle button
emulation in 3 button mouse. It does not look for me as Harbour
problem.
> 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.
Yes it should. To be compatible with Clipper we should have:
INKEY_MUP
INKEY_MDOWN
but to be honest I do not find it very useful. INKEY_MMIDDLE is 99.9%
enough. Just like single mask INKEY_MWHEEL.
Both middle and wheel button support does not change original CL53
values so code written for CL53 can work with then without modifications.
The problem is only with K_MM*DOWN. If they are not designed for extended
mouse keys but used for normal keys then it breaks existing code.
I do not understand why we have it. Such event reporting system does
not give full information about mouse events and it's necessary to
use additionally MCOL() and MROW() to extract mouse position.
So I do not see why programmer cannot call MLEFTDOWN()/MRIGHTDOWN()
to check button state two.
This extension does not give anything new and still keep the problem
Clipper API problem: it's not possible to check where an event happen
because MCOL() and MROW() returns the current mouse position not the
place where event appeared.
If we want to add any extensions then we should make it well and
resolve this problem so mouse events can be reported with cursor
position state and all button states.
The K_MM*DOW extensions does not give anything more then implementing
INKEY() wraper like:
FUNC MY_INKEY( nDelay, nMask )
LOCAL nKey
nKey := INKEY( nDelay, nMask )
IF nKey == K_MOUSEMOVE
IF MLEFTDOWN()
nKey := 1011
ELSEIF MRIGHTDOWN()
nKey := 1012
ELSEIF MMIDDLEDOWN() // it does not exist yet but can be easy added
nKey := 1013
ENDIF
ENDIF
RETURN nKey
So anyone who does not need original Clipper INKEY mouse codes can use it.
We can also enable HB_SETINKEYBEFOREBLOCK()/HB_SETINKEYAFTERBLOCK()
functions (I've never enabled them in Harbour) so user can make such
translation for pure INKEY() function by:
HB_setInketAfterBlock( ;
{ |nKey| IIF( nKey == K_MOUSEMOVE, ;
IIF( MLEFTDOWN(), 1011, ;
IIF( MRIGHTDOWN(), 1012, ;
IIF( MMIDDLEDOWN(), 1013, nKey ) ) ), nKey ) } )
> We have an incompatibility here, and this might solve it.
> What do you think?
See above. Personally I do not find any reason to introduce trivial
to implement by user things which does not give any new functionality
as exceptions to core code. I will not be surprised if M*DOWN() was
not working in xHarbour when it was introduce so it's some type of
workaround for other problems. Pritpal?
> 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.
The only one reasonable extension for me is introducing extended
mouse and keyboard events so programmer can try to detect difference
between CTRL+S and LEFT cursor key and extract mouse events with
the exact position when the even appeared (f.e. the button was pressed)
and full button and key modifiers (SHIFT,CTRL,ALT) state in this moment.
For this we will probably have to use some more complex data then number
or encode this information in bits for: MROW, MCOL, MLEFT, MRIGHT, MMIDDLE,
SHIFT, CTRL, ALT.
> [ This is one reason why it's wiser to mark extensions as such...
> Now I've found and extension the hard way. ]
As opposite marking all harbour extension by HB_ prefix is a nightmare for
people who does not know Clipper wants to use Harbour and cannot understand
why some things have HB_ prefix but other don't and they belong to the same
function group, f.e. we can add:
HB_FUNC( MMIDDLEDOWN )
{
hb_retl( hb_mouseButtonState( M_BUTTON_MIDDLE ) );
}
but it should not be called HB_MMIDDLEDOWN() because we should have:
MLEFTDOWN(), MMIDDLEDOWN(), MRIGHTDOWN()
not:
MLEFTDOWN(), HB_MMIDDLEDOWN(), MRIGHTDOWN()
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
