quickbuttons plain text entry

Post by **Marcus Tettmar** » Mon Oct 09, 2006 10:52 am

Actually this is different to the quickbuttons issue. QuickButtons sends the text as all lower case - it is ignoring case. Macro Scheduler does NOT ignore case but what is sent will be effected by the caps lock. This is because Macro Scheduler simulates sending keystrokes and therefore it must do what would happen if a user typed those keys. Therefore if caps lock is OFF the text would be sent exactly as it is shown. If ON it would reverse case. So all you actually need to do is ensure you have a CapsOff statement at the start of the script. Then what is sent will appear exactly as written in the script.

Me_again · Post by **Me_again** » Mon Oct 09, 2006 1:39 pm

mtettmar wrote:Actually this is different to the quickbuttons issue. QuickButtons sends the text as all lower case - it is ignoring case.

That's not my exactly experience, it appears to respect the caps key, and sends either all upper, or all lower case. Here are two pushes of the qbutton into notepad, one with caps lock off, one with caps lock on:

Macro Scheduler does NOT ignore case but what is sent will be effected by the caps lock. This is because Macro Scheduler simulates sending keystrokes and therefore it must do what would happen if a user typed those keys.

But hasn't the coder already simulated exactly what would happen if the user typed those keys by storing the text in the macro in the correct case?

Post by **Marcus Tettmar** » Mon Oct 09, 2006 1:54 pm

Me_again wrote:That's not my exactly experience, it appears to respect the caps key, and sends either all upper, or all lower case. Here are two pushes of the qbutton into notepad, one with caps lock off, one with caps lock on:

Yes, that's what I meant - either all lower or all caps.

But hasn't the coder already simulated exactly what would happen if the user typed those keys by storing the text in the macro in the correct case?

Only if he/she has also considered the caps state and the status of the modifier keys.

Me_again · Post by **Me_again** » Mon Oct 09, 2006 2:37 pm

OK, clearly you have something in mind from your global view of the use of the program that I've not run across in my personal use of it.

As a minumum could I suggest that the Help be updated to reflect this behavior and to include the full* work around code?

*By full I mean checking the caps status, and returning to that status at the end of the macro.

Bob Hansen · Post by **Bob Hansen** » Mon Oct 09, 2006 4:27 pm

Maybe I am missing something, but I believe no change is needed in Macro Scheduler. It does exactly as expected, it simulates a keyboard operator.

If you press CapsLock or release it, then you get UPPERCASE or lowercase characters.

If you PRESS SHIFT key then you get UPPERCASE until you RELEASE SHIFT, then you will get lowercase.

And if you have pressed CAPSLOCK and forgot to check the status, then you will get UPPERCASE, you can then PRESS BACKSPACE, release capslock and reenter the text, just as an operator at the keyboard would do.

I see no need to modify Help, and don't understand why a "work around" is needed for a non-existent problem.

Me_again · Post by **Me_again** » Mon Oct 09, 2006 6:27 pm

OK, what am I doing wrong in this case?

I wrote and compiled a very simple macro to sign into a VPN connection. The password is mixed case/case sensitive. If the user happens to have the caps lock set it fails.

Post by **Marcus Tettmar** » Mon Oct 09, 2006 6:46 pm

Use BlockInput and set the caps state in the script so that you know the outcome and can prevent the user interfering.

Or use the Ascii command. With the Ascii command you are outputting specific characters based on their ascii value, rather than sending keystrokes. Therefore you have complete control over the output. E.g. the following will always output "aAbYtT".

Ascii>97,65,98,89,116,84

Or use SetControlText to set the text of the control _directly_ and avoid mimicing user input altogether.

Me_again · Post by **Me_again** » Mon Oct 09, 2006 7:28 pm

Thanks for the suggestions.

#1 I don't like because I would also need to determine the state of the caps lock and return it. It also seems kinda rude to be messing with the user's keyboard

#2 would work.

#3 looks like the best, I'll have to learn how to do that.

Post by **Marcus Tettmar** » Mon Oct 09, 2006 7:34 pm

I'm looking into the possibility of adding the suggested "SK_IGNORECAPS" option. I think we may have to briefly toggle shift state if caps is on and it must be ignored. BlockInput is still sensible since someone could hold down the shift key while the macro is running and effect the case.

Me_again · Post by **Me_again** » Mon Oct 09, 2006 7:44 pm

SetControlText> is working well, thanks for the idea

jpuziano · Post by **jpuziano** » Wed Oct 11, 2006 7:20 am

mtettmar wrote:I'm looking into the possibility of adding the suggested "SK_IGNORECAPS" option. I think we may have to briefly toggle shift state if caps is on and it must be ignored. BlockInput is still sensible since someone could hold down the shift key while the macro is running and effect the case.

Hi Marcus,

Just wondering what you found with the "SK_IGNORECAPS" option? Was it workable? Did you go with briefly toggling shift state if caps is on and it must be ignored? Or did you do the equivalent, send the opposite case of the character instead? (advantage being that no toggling is required)

I'm quite hopeful on this one; we have lots of users that tend to leave their Caps Lock on so this would really simplify things.

Thanks

P.S. Greatly enjoying testing beta 9.0.023

Post by **Marcus Tettmar** » Wed Oct 11, 2006 7:31 am

It transparently toggles shift case if caps is on - which is the same thing as sending opposite case. Seems to work. Will be in beta 024 to try.

jpuziano · Post by **jpuziano** » Wed Oct 11, 2006 8:11 am

mtettmar wrote:It transparently toggles shift case if caps is on - which is the same thing as sending opposite case. Seems to work. Will be in beta 024 to try.

That's great, thanks....

jpuziano · Post by **jpuziano** » Thu Oct 12, 2006 9:59 am

Hi Marcus and everyone,

I installed 9.0.024 beta to test the new SK_IGNORECAPS system variable. The new Help text for "Send Character/Text (Send)" says:

Note that this command sends keystrokes and therefore any keys sent will be subject to the current state of modifier keys and the caps lock key. To ignore the caps lock state and send the text as entered set SK_IGNORECAPS to 1. (Let>SK_IGNORECAPS=1).

So I added...

Let>SK_IGNORECAPS=1

...to several of my existing macros and the state of the Caps Lock key didn't affect the output any more. This is great, no more having to:

- check Caps Lock state
- save Caps Lock state
- then before macro ends, restoring Caps Lock state

I know that...

BlockInput>1

can be used to block user input and still allow Macro Scheduler to send input (under XP at least)... but I decided to ToRtUrE tEsT this anyway with no blocking. What if the user did press shift or caps lock while the macro was running? How fast would the macro "sense" this and correct the output?

I used this simple macro to output a continuous string of capital I's:

Let>SK_IGNORECAPS=1

Send Character/Text>IIIIIIIIIIIIIIIIIII

Note: There are actually hundreds of I's in that one line but I shortened it here to avoid horizontal scrolling on this forum post.

I set the macro to trigger on Hot Hey F11, opened up Notepad, hit F11 and while the I's streamed out, manually pressed and released the Shift and Caps Lock keys. I found out two interesting things:

1) When Caps Lock was manually switched from Off to On, some i's were produced, averaging between 20 to 30 on my system, then it compensated and the rest were all proper capital I's.

However, going the other way, when Caps Lock was manually switched from On to Off, it compensated instantly! All proper capital I's every time, I couldn't make it fail. I'm wondering if the routine could be tweaked to compensate for Off-to-On just as fast as On-to-Off seems to work?

2) The SHIFT key actually makes no difference. I removed the Let>SK_IGNORECAPS=1 line, ran the macro and manually pressed and released SHIFT while it ran. It always produced I's, rock solid. It seems that (under XP anyway) the output of the Send> command is unaffected by SHIFT so the Help text for Send>...

Note that this command sends keystrokes and therefore any keys sent will be subject to the current state of modifier keys and the caps lock key.

...may be missleading if SHIFT is considered a "modifier key" here.

Also, I tried the free version of QuickButtons and I now see what webber123456 means. Its currently not possible to program a "QuickButton" to send mixed case text, just ALL UPPER or all lower depending on the current state of Caps Lock. This is too bad bad since players may want to send mixed case text in certain games, text containing Proper Names for instance. Ideally, it would output the text exactly as intended regardless of the state of Caps Lock; we all know that's possible, just look at what we can now do with Macro Scheduler and SK_IGNORECAPS.

Thanks again Marcus for providing the great new SK_IGNORECAPS solution so quickly and all the other helpful forum contributors.

jpuziano · Post by **jpuziano** » Thu Nov 09, 2006 1:08 am

Hi Marcus,

I noticed a new version of QuickButtons, version 1.6, came out some time after the above post so I just tried it.

I was curious to see if it could now send MiXeD cAsE tExT and was glad to see it could.

If you add the following lines to a button...

{shift+upper}
lower

...when you click that button, it will type UPPERlower. If the CAPSLOCK key happens to be on, you'll get upperLOWER instead, but with a tool like this, the operator is a real person so I suppose the person could just make sure the CAPSLOCK key is off and everything would be fine from there.

Thanks for this new version Marcus.