Picking up non-in-card keydowns

[richmond62]

Sorry about that clunky title, but couldn't really work out how to express that otherwise.

So, I thought it would be a nifty thing to have a small standalone that
lurked in the top-right-hand corner of my right-most monitor
(I have 3 connected to my 2018 MacMini)
-

-
that could let me know when I have
the TAB, SHIFT, ALT, CTRL/CMD on both my "main" keyboard and my auxiliary
half-keyboard (T9 Pro / Nostromo) down . . .
-

-
Now, OBVIOUSLY, a stack containing a rawKeyDown command in a cardScript would
"do the magic", but IFF the cursor was focused inwith the stack.

However, I want my stack/standalone to pick up a rawKeyDown while the cursor/pointer is
in LibreOffice, Finder/Thunar (MacOS, XFCE respectively0 or whatever that is NOT the stack/standalone.

[bogs]

You know, I thought the same kind of thing would be possible just tracking the mouses location, as mentioned here, but apparently not so much. The only 'hackey' way I could think of was (for one monitor) to make a substack full screen and blended to 99 (invisible) and sink it below everything else. Problem is, it only works as long as no other application has focus

Craig had an interesting post in that thread, though, and his method did work, so you might modify it to report rawKeyDown events instead possibly...

[richmond62]

It is quite possible I don't entirely understand how computers work, (OK, I don't)
but . . .

I do know that when a USB device (mouse, gamepad, keyboard, trackball, and so on) is activated
by a key being pressed, a button being pressed, a scroll wheel, etc. an electronic signal is sent
"down the wire" from the device to the computer, and, generally, the computer picks up that
signal.

Now there are computer programs that respond in pre-configured ways when a USB device sends
a signal to a computer whether that program has focus or not (think, for instance, of windowless programs
that work in the background while someone is doing other work - how about keyloggers for starters?).

Let's actually be unpleasant and imagine a nasty scenario: I begin to suspect that my cat is sending
offensive messages about me to friends of mine, but is calling herself "Gungadin" and using her
own e-mail account, while I am out of the house. So I want to build a keylogger with LiveCode
so I can catch my cat red-handed (err . . . red-pawed).

Now requirement #1 of my LC keylogger is that it should not be visible (i.e. the cat must not know
it is recording her keyboard activities) and must pickup key presses (and then dump them into a text file).
-

hackCat.jpg (6.7 KiB) Viewed 3846 times

[richmond62]

Unfortunately this chap's website is down (probably pulled because of its contents?):

"Keylogger is a keystroke tracking software which runs in background and records keystrokes and send them to victims email

The algorithm is stated below for keylogger of windows:

1.Hide console

2.Detect keystrokes

3.Store them in a variable

4.When the length of stored variables reached a certain point, send them through email

5.return to method 2

It is a loop which may run until the computer is shut down. The concept is fairly easy . The code and necessary explaination is described shortly in this link. This keylogger is made by me in c++ without using external library for educational purpose. I hope it will clear your idea.

Making a complete full functional keylogger কীলগার তৈরি বেসিক থেকে - Technology Blog"

Now correct me if I'm wrong (cough), but IF that can be done in C++, as LiveCode has been built up from C++ there should be no earthly reason why one cannot build a keylogger in LiveCode.

AND, here, I should make a load disclaimer that I don't want to develop a keylogger, but I do want to develop something that will display various keyDowns onscreen in LiveCode while the LiveCode stack does not have focus.

[bogs]

Now correct me if I'm wrong (cough), but IF that can be done in C++, as LiveCode has been built up from C++ there should be no earthly reason why one cannot build a keylogger in LiveCode.

Heh, while I have no doubt that there are ways to do what you want, I have serious doubts as to that being the reason.

In C++ (or just C for that matter), you could write an entire operating system, the base that Lc runs on. You can rather easily access hardware directly, at the lowest level possible short of assembly or machine language.

In LiveCode, on the other hand, the various 'engine' routines are what is written in C++, and they are limited to what they are able to access. I can't remember the thread I was in at the time, I believe it was about single threaded vs. multi threaded development, but I seem to remember Mark saying that neither multi threading nor lower level access to actual hardware were ever going to be part of Lc.

What that essentially means is that although it would be possible to modify the engine to do these things through scripting, it is not going to happen. Oh yah, that was in another thread you started

[richmond62]

neither multi threading nor lower level access to actual hardware were ever going to be part of Lc.

My emphasis.

Was that a random decision, like so many others, taken without any justification or explanation being offered?
-

movie.png (44.76 KiB) Viewed 3708 times

-
It does seem 'Funny' when LiveCode lays claims to being "a proper programming language" and gets offended when
programmers who use other programming languages (c.f. C++) poo-poo LiveCode and its claims.

[bogs]

Was that a random decision, like so many others, taken without any justification or explanation being offered?

Well, if you read that thread, I think plenty of justification and explanation were given. Aside from that, I actually agree with the decision. You read the threads on this forum at least, people get into plenty of trouble just with the easy stuff {myself included!!}, how would you like to try trouble shooting a problem where they accidentally say, bricked their usb keyboard/game pad/mouse/etc, because you offered them low level access to the hardware itself ? Sounds like a nightmare that, having been in tech support myself, I don't even want to think about

If you want C/C++ power, start using C/C++.

Having said that, though, as I said above I believe that to do what you want to do *can* be done within Lc. I haven't personally started messing around with it, and so don't have an exact formula to give you, but you do have access through Lc to the OS shell, and the OS is going to know when anything like what your talking about happens.

You just need to figure out which commands to issue in a timed event to get that information. It doesn't require accessing the hardware.

[richmond62]

I think plenty of justification and explanation were given.

Would be grateful if you could direct me to that.

[richmond62]

would you like to try trouble shooting a problem where they accidentally say, bricked their usb keyboard/game pad/mouse/etc

NO, I wouldn't want to try to troubleshoot that sort of problem: I've caused so many problems
myself that I have to take responsibility for
that I have no time to worry about others' problems.

Now, LiveCode should not be held in any way responsible if you, me, or Uncle Tom Cobbly
screw up a program, a stack or a whole computer using LiveCode: any more than the Hoover
company should be held responsible because their super-sucker vacuum cleaner sucked my cat to an early death.

I have some quite groovy knives in my kitchen drawer: if I am so stupid as to stick one of them into another person
and kill them, it is, quite rightly, me who is going to be hanged and not the cutler who made the knife.

So, were LiveCode to retract the "never" and allow access lower level access, if someone bricks their whatever that is in
no way Kevin or Mark's responsibility.

The other day I was messing around with LiveCode to such an extent that it froze my laptop running LXLE: I did NOT go
running to Kevin or Mark frothing at the mouth: it was my own stupid fault, and with about 60 minutes of cursing and
swearing I got the thing sorted out.

[bogs]

Well, it starts here --> https://forums.livecode.com/viewtopic.p ... 15#p169987

Remember that LiveCode is a very high-level language and as low-level 'threading primitives' would be wholly, and entirely, inappropriate.

I'm pretty sure that 99% of all use-cases that people might have for threading could be gained by ensuring that most things you could want to do don't block, and use a callback system (e.g. database requests being done in a non-blocking fashion, similar to how tsNet operates to great effect).

I noticed some mention of GUI and threading here - I should point out that Windows pretty much remains the *only* OS which allows GUI stuff to run on different threads within one process (and that has all kinds of issues meaning its best avoided) - Mac does not, Android does not, iOS does not, Linux does not (unless you create two entirely separate connections to the Xserver - which essentially means you are running two separate applications in one process from a GUI point of view). All UI stuff needs to always happen on the main thread.

Surely you don't expect me to link to each and every post there after through the 7+ pages, right?

The other day I was messing around with LiveCode to such an extent that it froze my laptop running LXLE: I did NOT go
running to Kevin or Mark frothing at the mouth: it was my own stupid fault, and with about 60 minutes of cursing and
swearing I got the thing sorted out.

You didn't and probably wouldn't, but take my word for it there are plenty that would. True work experience from my sorted background ~

Customer: My internet is down.
Me: What do you see on your screen?
Customer: NOTHING, I JUST TOLD YOU MY INTERNET IS DOWN !!!!!!!!!!!!!!!!!!!!!!
Me: Um...