Hey, the "put true into tSame" line needs to be above the "repeat for reach
key tKey in tClipA" line. DOH.
On Wed, May 27, 2015 at 8:12 PM, Mike Bonner wrote:
> Skip,
>
> Here is a simple but working example of a clipboard listener.
> To test I just placed the code in a button so that I could e
Skip,
Here is a simple but working example of a clipboard listener.
To test I just placed the code in a button so that I could easily toggle it
on and off.
Its an very quick draft, but hey. It works.
#
local sRunning,sLastClipA
-- mouseup toggles the loop on and off
on mouseUp
The code I posted still would not have worked as it was. To do the
comparison and see if there is a change, you would indeed have to cycle
through the keys and look for the difference. There are definitely some
quirks involved here. Headed out the door, but it might be fun to mess with
the clipboa
No, you're right. I just posted a correction and then saw this reply.
When testing, "is an array" returns false on the retrieved content, but
when asking for each key type the values are still there. That must be
why the dictionary calls it a "false array".
On 5/27/2015 12:31 PM, Mike Bonner
Oops. I said:
You'll have to walk through all the keys when both retrieving and
setting the array. The default when getting or setting the clipboarddata
without specifying a key is to return only the plain text. The array is
lost.
That's wrong. Mike's right. The default is to assume text only,
Ah k, thx! Sorry for steering you slightly wrong skip. The basic premise
should still work, but you'll have to jump through the extra hoops of
checking the keys each time through. Should still be plenty fast. (game
loops do the same thing, and do considerably more than what you're looking
at whil
You'll have to walk through all the keys when both retrieving and
setting the array. The default when getting or setting the clipboarddata
without specifying a key is to return only the plain text. The array is
lost.
On 5/26/2015 9:58 PM, Magicgate Software - Skip Kimpel wrote:
Oooo... I will
Hmm. If you're watching for the keypress itself so that you can act, and
your send loop is tight enough (without causing too much lag) You could
just check the keysdown() each loop and see if alt-f is being pressed.
If the purpose is to use control keys to run another app, I'd say it
depends. On
Oooo... I will try that tomorrow!
Is there any way to save an alt+f keystroke to the clipboard data? I am
trying to automate some tasks during this entire exercise and this is also
one of my hurdles.
Thanks again,
SKIP
On Tue, May 26, 2015 at 5:59 PM, Mike Bonner wrote:
> One way would be to
One way would be to use a send in time loop. Check to see if the data in
the clipboard array is different, if so, act. Some untested quick and
dirty code follows.
command checkClipboard
if sLastClipA is empty then
put the clipboarddata into sLastClipA
-- do something with the data in sLastClipA
Is there a way to have LC sitting in the background (not hidden, just not
in focus) and keep track of items put in the clipboard? I want to simplify
some complex cutting and pasting of multiple fields. I can get the
mechanics of it to work if I can get LC to sit in the background and record
clipb
11 matches
Mail list logo