Messages sent while mouse is down?

Tim Selander selander at tkf.att.ne.jp
Sat Mar 11 20:06:56 EST 2017


Yes, that had occurred to me, but my explanation was too 
simplistic. While it is a Scrabble-esque game with tiles, the 
tiles are hexagons and are staggered on the board. (pic-- 
http://tinyurl.com/jjcqolm)

That still might be calculate-able, but is beyond my math skills!

Thanks,

Tim

On 2017.03.12, 10:00, Mike Bonner via use-livecode wrote:
> If the names of the tiles are numbered in a logical way, and only go
> horizontal, and vertical, then all you need to know is the start spot, and
> the end spot, and can fill in the gaps between.
>
>
> On Sat, Mar 11, 2017 at 4:06 PM, Quentin Long via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> sez Tim Selander <selander at tkf.att.ne.jp>:
>>> I miss the Zynga "Pathwords" game on Facebook, so for my own
>>> amusement I'm trying to recreate it in Livecode.
>>>
>>> For those who don't know the game, it had a solid screenful of
>>> Scrabble-like lettered tiles. Click and drag the mouse through
>>> adjacent letters to make words.
>>>
>>> Without clicking, simply moving the mouse through the tiles
>>> (fields) triggers mouseenter, mouseleave, etc. which makes it
>>> easy to pick up the letters.
>>>
>>> But when the mouse is down, it seems mouseloc() is the only thing
>>> I can get. Using a variable what has all the field rectangles, I
>>> can use the mouseloc() to ultimately identify the field under the
>>> pointer, but it's too slow...
>>>
>>> Does a moving mouse with the button down trigger any other
>>> messages besides mouseloc()?
>> I see that Mike Bonner has already provided a solution which seems to do
>> what you want. But just in case there are other people out there who might
>> need a different solution, here's my stab at it…
>>
>> If you have a "screenful of Scrabble-like lettered tiles", these "tiles"
>> are presumably arranged in a rectangular grid, with neatly aligned rows and
>> columns. If this is the case, the locations of the row-tiles are going to
>> be separated by X number of pixels, such that row-tile 1 has X-coördinate
>> A; row-tile 2 has X-coördinate (A + X); row-tile 3 has X-coordinate (A +
>> 2*X); and so on.
>>
>> Column-tiles will work similarly. Their locations will be separated by Y
>> number of pixels, such that column-tile 1 has Y coördinate B; column-tile 2
>> has Y coördinate (B + Y); column-tile 3 has Y coördinate (B + 2*Y); and so
>> on.
>>
>> If the grid's horizontal spacing is identical to its vertical spacing, the
>> separation-values X and Y will be the same, of course. Given the fact that
>> pixels are not *necessarily* square, it would be imprudent to *assume* that
>> the grid's horizontal and vertical separation-values are identical, and I
>> will not make that assumption here.
>>
>> So.
>>
>> My solution to Tim Selander's problem completely ignores most of the
>> mouse[whatever] messages, depending strictly on mouseLoc. Like so:
>>
>> local dX = 25 -- if the horizontal-spacing value is not 25, put the real
>> value here
>> local dY = 25 -- again, replace 25 with the real value as needed
>> local TimeSlice = 50 -- how often, in milliseconds, the code checks the
>> mouseLoc. adjust as needed for response time
>> local GridLocPulse
>>
>> global GridCell = "1,1"
>>
>> on GridLoc
>>    if (GridLocPulse) then send GridLoc to me in TimeSlice milliseconds
>>    put the mouseLoc into ThisLoc
>>    put (1 + (item 1 of ThisLoc div dX)) into item 1 of GridCell -- may need
>> tweaking to account for edge effects
>>    put (1 + (item 2 of ThisLoc div dY)) into item 2 of GridCell -- ditto
>> end GridLoc
>>
>> on GridLocOn
>>    put true into GridLocPulse
>>    GridLoc
>> end GridLocOn
>>
>> on GridLocOff
>>    put false into GridLocPulse
>> end GridLocOff
>>
>> The above code can go into the script of the card where the tile-grid
>> lives.
>>
>> Once every (TimeSlice) milliseconds, this code looks at the mouseLoc and
>> converts the mouse coördinates into grid coördinates, which are stored in
>> the global variable GridCell. GridCell being a global, its contents should
>> be accessible to any handler in any script which includes the line "global
>> GridCell".
>>
>> It's probably a good idea to *not* have the GridLoc handler burning
>> clock-cycles *all the time*. Thus, the local variable GridLocPulse, and the
>> subsidiary handlers GridLocOn and GridLocOff. GridLocOn activates the
>> GridLoc handler, and GridLocOff turns GridLoc off.
>>
>> Hope this helps…
>>
>>
>> "Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
>>
>> Read the webcomic at [ http://www.atarmslength.net ]!
>>
>> If you like "At Arm's Length", support it at [ http://www.patreon.com/
>> DarkwingDude ].
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>





More information about the use-livecode mailing list