Cursor position finding

I’m having some ‘fun’ working out why Scratch on the Pi misses a ot of clicks and double-clicks. I’ve run event  debugging and discovered that all the events seem to get into the vm and then into the image ok, but right now it looks a lot like the legacy io code still in the system is flushing a lot of events when it (mis)uses
Sensor cursorPoint etc.

I *think* I need to change the code to use ‘ActiveHand cursorPoint’ etc. Is that the proper api? I’d go for passing events around more of the time but that looks like a huge change I can’t do any time soon.

There’s also a problem with uses of 'Sensor shiftPressed’ sending a flush, but I don’t see anything like a ‘ActiveHand shiftPressed’ method.

Surely we have a non-destructive way of finding current state on the cursor position, modifier state etc somewhere in there?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Brain fried; core dumped.

On 12-08-2014, at 11:38 AM, tim Rowledge <[hidden email]> wrote:
> There’s also a problem with uses of 'Sensor shiftPressed’ sending a flush, but I don’t see anything like a ‘ActiveHand shiftPressed’ method.

I don’t seem to get sensible looking answers if I do
  (Delay forMilliseconds: 1500) wait. ActiveHand anyButtonPressed
and move the mouse around with a button pressed. I’d expect to get ‘true’ but don’t.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The less time planning, the more time programming.

On 2014-08-12, at 21:20, tim Rowledge <[hidden email]> wrote:

>
> On 12-08-2014, at 11:38 AM, tim Rowledge <[hidden email]> wrote:
>> There’s also a problem with uses of 'Sensor shiftPressed’ sending a flush, but I don’t see anything like a ‘ActiveHand shiftPressed’ method.
>
> I don’t seem to get sensible looking answers if I do
>  (Delay forMilliseconds: 1500) wait. ActiveHand anyButtonPressed
> and move the mouse around with a button pressed. I’d expect to get ‘true’ but don’t.

You wont, because you don't let Morphic process events if you block the UI process with a delay. This should work fine, however, in an actual method (invoked e.g. by the stepping mechanism).

You can also type "ActiveHand anyButtonPressed", press and hold a mouse button, then do cmd-p, to get true.

- Bert -

On 2014-08-12, at 20:38, tim Rowledge <[hidden email]> wrote:

> I’m having some ‘fun’ working out why Scratch on the Pi misses a ot of clicks and double-clicks. I’ve run event  debugging and discovered that all the events seem to get into the vm and then into the image ok, but right now it looks a lot like the legacy io code still in the system is flushing a lot of events when it (mis)uses
> Sensor cursorPoint etc.

Yep.

> I *think* I need to change the code to use ‘ActiveHand cursorPoint’ etc. Is that the proper api? I’d go for passing events around more of the time but that looks like a huge change I can’t do any time soon.
>
> There’s also a problem with uses of 'Sensor shiftPressed’ sending a flush, but I don’t see anything like a ‘ActiveHand shiftPressed’ method.
>
> Surely we have a non-destructive way of finding current state on the cursor position, modifier state etc somewhere in there?

Try

        self currentEvent shiftPressed

or

        self currentEvent position

- Bert -

On 12-08-2014, at 12:26 PM, Bert Freudenberg <[hidden email]> wrote:
> You wont, because you don't let Morphic process events if you block the UI process with a delay. This should work fine, however, in an actual method (invoked e.g. by the stepping mechanism).

Oh, well duh. There was me thinking the delay would let the event processing carry on underneath…

>
> You can also type "ActiveHand anyButtonPressed", press and hold a mouse button, then do cmd-p, to get true.

That works. Hooray!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DC: Divide and Conquer

On 12-08-2014, at 12:28 PM, Bert Freudenberg <[hidden email]> wrote:
>> Surely we have a non-destructive way of finding current state on the cursor position, modifier state etc somewhere in there?
>
> Try
>
> self currentEvent shiftPressed
>
> or
>
> self currentEvent position

Excellent; these are definitely making it work much better.

It seems odd that all UserInputEvents understand shiftPressed but not anyButtonPressed. It’s easy enough to put a null method up there so it doesn’t dNU:, but does it make sense to actually pay attention to the buttons value for key events?

Another irritating idiom from the old days is exemplified in this code -
        Cursor eyeDropper showWhile: [
                Sensor waitButton.
                [Sensor anyButtonPressed] whileTrue: [
                        self color: (Display colorAt: Sensor cursorPoint).
                        w displayWorldSafely]].

What’s our least awful way of handling this? I guess I should point out that it’s in a mouseUp: method and probably needs to be completely restructured.

Modernising old code is *such* fun….

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: EROS: Erase Read-Only Storage

There is color-picking in Morphic too, but I can't look right now.

- Bert -

Hi Tim,

snip...

>It seems odd that all UserInputEvents understand shiftPressed but not anyButtonPressed. It’s easy enough to put a null method up there so it doesn’t dNU:, but does it make sense to actually pay attention to the buttons value for key events?

I have a program called WordWeb http://wordweb.info/.  I use it all the
time because I am a terrible speller.  One of a few ways in which it will
pop open it's window is to hold the mouse over a word, press Ctrl and right
click.  Ctrl isn't a "regular" key but the more we developers look for new
ways to indicate what a program should do, the more we will run into these
odd combinations.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

Thanks for the advice Bert; this has made a huge improvement to the click response.

It’s kinda depressing to see how many places are still using Sensor and old code. So much clean up to do.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Objects are closer than they appear.