No human being can know the heart of another.

Whatever your intentions, I think your posts may be triggering warning bells because in each and every one, you seem to want to control/intercept things outside of a specific application, particularly the user interface used by other applications. Here is a summary of your questions:

• In checking mouse events on desktop you want to monitor mouse activity for the desktop and all windows, not just the one's controlled by your application. Why? An application should only be concerned about its own inputs. I can't think of a "white hat" reason for such broad-based mouse capture other than a window manager or window manager extension.
• In Manipulate Desktop-Windows with Perl you want to manipulate all desktop windows, not just the one's used by your application.
• In Fast way to compare two picture-files you tell us that you want a rapid way to compare two picture files so you can compare before and after snapshots of desktop areas. Apparently, you decided to do this on your own: Alternate for GetPixel asks for a faster GetPixel routine.
• In use the return code of another program you want to write a process monitor that will run in parallel with program X, and capture its output to stdout and its return code. stop pipe apparently concerns a problem with getting said process monitor to stop.
• In Capture Keystroke, the current post wants all keyboard input, not just that destined for a specific widget. And you want to send the key strokes out to the "system", rather than to the application that owns the widget.

Now, of course, Perl is often used for system level programs. But the system level programs written in Perl normally concern themselves with the non-interactive portions of the computer ecosystem. The kind of cross-application GUI monitoring you seem to want to do is normally done by windowing systems and desktop managers. Desktop managers are generally written in a language that has rapid direct access to system APIs - for example C/C++ or C#

That isn't to say Perl is never used for desktop-wide GUI programs. tye recently used Perl to fake mouse movements so that he could listen to music as he biked to work. He wasn't trying to hurt anyone, but this is the exception that proves the point. He was doing this to subvert a screen saver time-out that the previous IT administration at his work had instituted as a "security" feature.

System level programs with GUI access has been such a common vector for black-hat software that Vista essentially put an iron wall between the two. In Vista, system and desktop processes run in different "sessions". Even if a remote process logs in as user X it gets its own (non-GUI) session and cannot get access to X's desktop enabled session without a fair bit of fancy systems and permissions footwork.

Perhaps the other issue that raises red flags is the level of expertise suggested by your posting style. The white hats that do these kind of system wide GUI things are usually, like tye, pretty experienced programmers. Usually experienced programmers do a fair amount of research before they post. They don't want superficial answers, so they make it clear they've read the manuals and searched the expert forums. They ask focused questions about alternatives, not "Does anybody have a clue?".

Now I'm not saying that a learner won't want to do some cool GUI wide programming. A successful program can be fun to write and very empowering, BUT, if you are a learner, I wonder, given the security issues and level of expertise, if this really is the best project to start on.

Best, beth

Will I tell you? No.

You have been in the Monastery for over half a year. By now you should know the position on helping the Bad Guys create illegal software. If you have a justification for this bit of chicanery, let's hear it.

By now you should know the position on helping the Bad Guys create illegal software.

Software which captures key strokes and sends them off to another system is not illegal. If it was, the X Windows system, or Citrix, or NoMachine would be illegal, even OpenSSH. The OP does ring your alarm bell - but what does tell you they are Bad Guys?

For what it's worth, my alarm bells were ringing too. Especially after this post prompted me to go through michbach's previous posts.

That's not to say I assumed the worst. It just meant that something smelled slightly fishy.

something smelled slightly fishy

What is it that smells fishy? Getting mouse events, manipulating window size and stacking order, recording key strokes - all that are things we do all day long (the latter, for instance: saving those key strokes to a file, e.g. Unnamed.doc). Fishy? Is there more to it than a Pawlow's dog reaction?

Do you have any grounds on which to insinuate criminal energy? Do you know of the OP's purposes?

For myself, I'm capturing all output to any terminal I open, to a file, named after 'begin-end-terminal', via script(1) on UNIX. That way I have a log of all I am doing. Does that sound evil to you?

God in heaven! Let your alarm bell rings! I guess u are feeling great when your bells ring. But i call this a little bit paranoid. I dont know exactly how much keyloggers and all that hacker-waste u can download in the internet but im sure more then hundreds. You can get such software on every corner and there is no need to write one (not for me lol). There are a lot of other reasons to control mouseevent or keyevents then only hack hack hack. Its not my problem if you cant imagine that, but let it be to imply me i have a bad tendency. Every question here could be help anybody to write a scripts for hacking or other abuse. But i understand also that on such a public board a certain security must be. I try to respekt the board-rules as i know (i dont read the rules every day!) but please avoid suspicions from your side. This is not Quantanamo (evidences no need it). As i already wrote i know how to get a value (Term::ReadKey, bind etc.) of a keystroke but my core intention was to make it not circumstantial with hundred of script-lines. At the end i wanna say i solved the problem with another help so the problemm dont exist anymore. Sorry for my bad english but im to old to learn english really good. My time is limited :-) and i need ofte a long time to write my questions in this language. But i try my best and i like this board cause you get often quick and professional help. tx to all, regard michbach

Omg, Old_Gray_Bear ur fantasie is not good. The world is full of bad guys but may be not so much as u imagine! Im writing a programm with a gui frontend (Tk) where users can store their own keystroke and later in this program they can use this keystroke to control their own desktop functions. Thats all! Nothing bad. But its ok i will do it by myself. I know modules like Term::ReadKey and the function like SendKeys("BlahBlah")will help me but the Problem is under Term::ReadKey i cant get all special keys like F1-F12, Del, Pageup, Pagedown, Arrows, Print etc. to store this value in a scalar to give out later the same keyvalue with SendKeys.. By the way another possibility were to bind a keystroke to a Tk-element like:

$textbox->bind("<Return>", sub{$Entryfiel->delete('0.0','end');$Entryf
+ield->insert("end", "Return");});
[download]

but dont wanna do it in this way for every key. Thats really circuitous, so i try to find a better/smart way. Ok many thanks i will try it by myself and im sure i find a way may be in a week but i will find it.. Best regard, michbach

Your trend of questioning and research into your program's implementation does overlap the blackhat domain, at a quick glance.

It's fine to continue asking, but next time, it would be good to state your intentions like you did here to avoid further (superficial) suspicions. Besides, stating your intentions also help you more in that other monks can suggest better solutions to your actual main problem.

With that said, there's lots of third-party tools that already do what you want to do. Search the web. Why not leverage them? If you're writing it for your own education, then it's best to say so, so that other monks can decide whether to help, given that more info is provided.