Strange problem with TypeText

So the below code does not work when the get function is called. Basically each time it goes in the repeat the \v doesn't work on a menu I am clicking on and then trying to move down it. It's like the \v is not recognized. Don't worry about the else part it is the if part that has the problem.

"RepeatKey".get("\v",2,false)


on get params
set key to item 1 of params
set cnt to item 2 of params

if item 3 of params equals false then
repeat cnt times
Wait 0.5 Seconds
TypeText key
end repeat
TypeText return
else
repeat cnt times
Wait 0.5 Seconds
TypeText key & return
end repeat
end if

end get

Now the wierd thing I have discovered is that it works fine if the function is modified a little bit like below. I think the problem is that a single character code passed in a variable does not function properly in Eggplant.

on get params
set key to item 1 of params
set cnt to item 2 of params

if item 3 of params equals false then


repeat cnt times
set string to string & key

(*Wait 0.5 Seconds
TypeText key*)
end repeat
log string
TypeText string & return
else
repeat cnt times
Wait 0.5 Seconds
TypeText key & return
end repeat
end if

end get

Any ideas of why this is behaving like this?

Comments

  • EggplantMattEggplantMatt ForumAdmin admin
    I'm not sure why this wouldn't be working, but the quick fix is to replace "\v" with downarrow (no quotes -- eggplant keyword for the down arrow key). I'm pretty sure that will fix it.

    Also, have you tried using the debugger to see what the value of key is when you're in the loop? Just set a breakpoint on the TypeText line and then do a "put key" in the AHDB (the Ad Hoc Do Box, aka the text field at the bottom of the run window).
  • EggplantMattEggplantMatt ForumAdmin admin
    I don't think this has anything to do with it, but "get" is a SenseTalk command. It's usually okay to redefine the SenseTalk keywords, but maybe there's a side effect here.
  • EggplantMattEggplantMatt ForumAdmin admin
    So, I've run your code and it works fine for me. It sends a downarrow event to the remote system. Another thing to look for is whether the menu is maintaining focus -- maybe the downarrow event is getting sent, but the menu isn't receiving it. Try putting the focus somewhere else where a downarrow will have an effect and run your code -- I ran it with Mail as the active application and it scrolled through the message list in my inbox.
  • EggplantMattEggplantMatt ForumAdmin admin
    I should have thought of this earlier: I think the problem may lie in Eggplant's behavior when it can't find an image. When Eggplant looks for an image and doesn't find it on its first pass across the screen, by default it moves the mouse to the lower right corner of the screen. This is because, especially with older VNC servers, the cursor can be part of the image, and Eggplant can't find image + cursor if the original capture was just image. You can turn this off either via the preferences (Run Options > Should reposition mouse during image search) or by setting ShouldRepositionMouse to "NO" in your script. I suspect this is why the menu is losing focus as I suggested in a previous post. Please let us know if any of this helps.
  • SenseTalkDougSenseTalkDoug ForumAdmin admin
    Following up on something Matt pointed out earlier, there is a built-in SenseTalk command called "get". It's perfectly possible to write your own get command if you like (as you've done), but there are a couple of reasons why you may want to avoid this.

    First of all, if you wrote a script called "get.script" you would find that you couldn't call it in the usual way, because the built-in command would take precedence. In your case, you've written "get" as a command handler within a script, and are calling it directly in that script, which should avoid this problem.

    Secondly, and possibly more relevant here, if something causes your get handler to not be found (for example, if you mistakenly implemented it as "function get" instead of "on get" or "to get"), you wouldn't be given any sort of error, since your call to get would simply invoke the built-in version of get. I don't really think this is what's happening here, but it's a remote possibility that might help to explain the odd behavior that you're seeing.

    In any case, unless you have a reason to specifically want to override a built-in command or function, it's probably a better idea in general to use a different name for your own functionality.
Sign In or Register to comment.