Keystrokes Mod 1.8.9

[Myra Krallman]

Oneof the most influential (to me personally) posts Jon Udell has written was his classic "count your keystrokes." I've mentioned this post in a number of my talks, including my talk on "Tips to make your blog suck less" at Blogging While Brown this last weekend. This point, in particular always seems to resonate with people, so here's my own take, before you read the original.

Let break it down. I'm 36 and change. I'll live to be 80, let's say, and I can type 100 words a minute (but 50 of that is errors and the backspace key) so let's say 50WPM. If I type for 6 hours a day, 5 days a week, 50 weeks a year, for the next 44 years, that means there are 198M keystrokes left in my hands. Max. Period. And that's generous; it's likely 10% of that.

Let's assume the average length of an English word is 5, plus a space, so six. That's a ceiling of 168M more words I can type in my lifetime. Nothing I can do, short of dictation, or some new brain invention is going to create more keystrokes. I am I/O bound by my hands. The keystrokes they contain are finite. And this assuming my hands don't give out.

Drink that in. OK. So now, next time someone emails you ask yourself "is emailing this person back the best use of my remaining keystrokes?" That includes both 1:1 and 1:many emails. You could even add a little hubris to it and say: "Does this person deserve the gift of my keystrokes?"

Instead, consider writing a blog post or adding to a wiki with your keystrokes, then emailing the link to the original emailer. (Like this email, er, blog post, for this example.) Send them to or and teach them to fish.

UPDATE: This is about reach and effectiveness vs. efficiency. If you email someone one on one, you're reaching that one person. If you blog about it (or update a wiki, or whatever) you get the message out on the web itself and your keystrokes travel farther and reach more people. Assuming you want your message to reach as many people as possible, blog it. You only have so many hours in the day.

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

I have 1 user who reported today that they could no longer log in to their computer through LMI. They could still hit the control-alt-delete button to log in, but after doing that, they were unable to type anything through LMI. But everything worked perfectly fine for me to remote control their computer using my user account.

The way that the permission descriptions are written (link), it's actually not clear to me whether checking the checkbox of these new permissions enables or disables the ability to use these functions. For example the description for the new Keystrokes permission says "Disable all keystrokes from the client sent to the remote host during remote control". So if I check that checkbox, am I enabling or disabling the user to send keystrokes? When I examine a user that has "full control", these checkboxes are all checked, so for example that makes it seem like checking the checkbox allows the user to send keystrokes.

I only really just discovered this a bit ago, so I haven't fully tested yet. But, if these new permissions could effectively default to locking out all non-admin users from using LMI, that might constitute a semi-emergency that should be raised sooner than later. That said, apologies if this winds up being a false alarm.

If I uncheck the "Keystrokes" permission, I am no longer able to type through LMI. (Although I can still access the on-screen keyboard.) Once I re-check the permission, I can type again.

So...yeah. Unless my experience is somehow unique, you probably won't want 15512 until maybe these new permissions can default to being enabled for users who already have remote control permissions.

Good to know that the rollout has been paused! This new option is easily overlooked and also caused me a bit of frustration today until I'd noticed the version difference. If I've already granted a user remote desktop access, maybe the default keystroke option should be enabled in this instance?

I had a somewhat of disaster of a morning because of this update. Many of my users were able to connect, but not type after connecting. After a fairly long tech support call the solution they offered was to give the users "full control" permissions which fixes the problem.

Same issue here today and yesterday. Two LogMeIn Central hosts had updated themselves, and the default permissions for BUILTIN\Users do not allow Keystrokes which means users cannot type when they connect via LogMeIn, nor Blank Screen because that's also been added.

Per Glenn's post above, hosts should have stopped getting updated to 15512 as of June 21st. But I checked the release notes again today, and I see that new version 15530 was released June 27th (today), and it is indicated for 15530 that this issue should be fixed. None of my hosts have been automatically updated to 15530 yet, so I don't know, but I'm just looking to plan accordingly as needed.

For your purposes, please don't take my word for it because I'm just a random guy, but maybe a workable solution could be to force the affected hosts to update to 15530? We can trigger hosts to update from the Central admin control web interface.

A solution I had in the works was to export the registry key from the BUILTIN\Users group that had the permissions for Blank Screen and Keystrokes granted, then to deploy that via group policy to affected machines.

The registry key is in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\LogMeIn\V5\Permissions and it's called AccessMask. One subkey is created for each user being granted permission, so as long as I was targeting a group all users were in, it should apply fine.

Thank you very much for your response. I'm actually utilizing keystrokes on the login page because some applications do not support Capture Action: Set Text. Also, I'm saving files from the browser using the Save As Popup, thus it's not working in unattended mode.

I am also facing the same issue - the keystrokes are not working in unattended mode. It is not possible for me to use Object Cloning as it is not recognizing individual objects in application window. Object Cloning only recognizes the entire window.

My apologies if this question has already been asked. I have searched the Captivate help forum for related posts and have yet to find what I need. I am very new to Captivate (just installed it several hours ago), so my question might sound a bit simplistic.

My goal is to create an educational video that teaches the viewer how to build a 3D model. The modelling process (done in a program called "Sketchup Make 2017") is very hotkey-intensive. In order for my video to be effective, I need Captivate to record and show each of my keystrokes (e.g., displaying "ctrl + Q" when I hold the control button down and press the "Q" key) and mouse clicks (i.e., R-click, L-click, and M-click).

I have tried several ways to accomplish this. I tried recording a software simulation, but this did not capture all of my keystrokes, and it did not show different mouse clicks. I tried recording a demo video, but I could not figure out how to make my video display my keystrokes, much less my mouse clicks.

I have searched through forum posts for the past hour, and I have yet to find a solution that a) I can understand, and b) fixes my problem. I'm not looking to do anything fancy - no virtual keyboards, no interactive features, just a simple video with keystrokes and mouse clicks shown as a text overlay. Does anyone have recommendations for how I can do this?

But for actions invoked by keystroke you need to be aware of the fact that when you capture a simulation recording with Captivate (as slide-by-slide demo) it is always going to be playing in a web browser environment after publishing. That means that the web browser gets first pick of which keystrokes it wants to reserve for its own use. The content playing in the browser doesn't have the ability to over-ride the browser's reserved keystrokes.

So, there are usually lots of keystrokes which would work in the original application that you cannot really replicate in the Captivate simulation. You usually need to explain this in the tutorial and provide some other way the learner can indicate a keystroke action.

I've had issues recording software simulations when the application I'm recording is not located on my primary monitor in a two monitor situation. Keystrokes and mouse clicks fail to register resulting in the software simulations being useless. It may not be your issue but double check that your 3D Modeling application isn't located on a secondary monitor when recording.

I think I may have been a little unclear on what my overall goal is. I want to make a non-interactive demo video, to be published on youtube or saved as a video file that I can share with my immediate colleagues. I tried recording my project as a software simulation to see if the different format would allow me to display keystrokes.

Your advice is definitely helpful, as far as software simulations go, but I am not trying to account for my viewer's keystrokes. I only want to display the keys I press while Captivate is recording. Is my understanding too simplistic? Let me know if you want me to clarify my question.

Do you mean that for each keystroke I want to display, I need to manually place a text caption, manually type the keystroke information into the text caption, and then manually change the appear/disappear timing for the text caption? If this is what you mean, I'm trying to find a way to do this automatically. My tutorials will have anywhere from a dozen to hundreds of keystrokes in them, and it would prohibitively time-consuming to do all this for each one.

3a8082e126