Hi Przemek,
> > 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.
Okay, might be it's an Ubuntu running under VirtualBox.
Anyhow this isn't really causing headaches for me.
> 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.
I didn't know about these functions, but in the shade of them
these event are absolutely pointless.
I've a patch to add a new mask for them, but it'd be better
to just remove them. The other is K_NCMOUSEMOVE which
would better get a mask, but it doesn't cause that big problems.
> 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.
Good point. I've observed strange things because of that, now
that you mention.
> 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 ) } )
In any case, not with these horrible names,
for me personally such extensions always seems
forced and unnatural, and looks like a hack to
workaround app problems. If the group think we
can add them if course, but let's give them slightly
better names:
hb_inkeySetPreBlock()
hb_inkeySetPostBlock()
> 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 would be great. I always wanted to differentiate between
<Ins> and <Ctrl+V>, maybe that would make this possible,
plus a lot of combinations I forgot in the meantime.
> 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:
Well, I'm still saying that _all_ extensions should have a prefix, and
a few things may happen from here, either I don't feel like spending
a week trying to defend this rule for every occasions, or I wasn't here,
or the feature wasn't discussed before commit. Every decision is a
compromise for some group of people (this one for new users), in
Harbour we opted to favour compatibility.
>From the current situation where every (well almost) extensions are
properly marked there is an easy way to flat everything into a
generic namespace and make newcomers happy. It's a matter of
a translation table. Try this the other way round...
Let's find out what to do with these incompatible events. In the
mean time I had to modify my code to check for ( key == K_MOUSEMOVE
.OR. key == K_MMLEFTDOWN ).
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
