Move cursor with batch file

[gsnidow]

Greetings.  I'm not sure this is the correct forum to ask something like this, but I've got to start somewhere, right?  We've got an IBM mainframe, with 3270 on our machines to access the data.  We can write VB script to automate the completion of repetitive tasks, and it actually saves countless hours of what would otherwise be manual work.  The problem is that when running a script, the speed is strangly dependent upon whether or not the mouse cursor is moving over the VB file.  For example, say my VB script can perform a transaction in 5 seconds when the mouse is not moving over the VB file that is running.  I can then move the mouse cursor in any direction or distance, as long as it is moving somewhere over the VB script file, and the script can all of the sudden perform the same transactions in 2 seconds.  My first thought was to get one of those things people have on their desks that rock back and forth, producing a repetitive blue wave, and simply sit my mouse on it.  My next thought was to have a program that would just move the cursor around.  I'm not even sure that is possible, let alone how I would go about doing it.  Any ideas or thoughts?  Thanks.

Greg

[Geek-9pm]

Apparently this is how VB scrip is helping the unemployment issue.

Now the IT department shave to hire somebody to rock the mouse back and forth to speed up the process. Just think of how this will help he  under skilled people who can not otherwise hold a job.

Put an ad in the local newspaper:
mouse rocker wanted,
no experience needed.,
 mouse provided..   

[gsnidow]

Well, I can't tell you how many times I have sat there, racing the clock to a deadline, doing nothing but just what you suggested.

[Sidewinder]

I was unaware VBScript even ran on IBM mainframes. There is no native way in VBScript to do this, but if you have a VB compiler, you can build a class wrapper using the Windows API and use it within VBScript to move the cursor:

Class Wrapper:

Code: [Select]

Public Class SetCursorPos
  Private Declare Function SetCursorPos Lib "user32" Alias "SetCursorPos" _
    (ByVal x As Long, ByVal y As Long) As Long

  Public Sub MoveTheCursor(ByVal xPos As Integer, ByVal yPos As Integer)
    SetCursorPos(xPos, yPos)
  End Sub
End Class

The above is for VB6; replace every occurrence of long to integer if using VB.Net

In your VBScript, add the following code:

Code: [Select]

Set pointer = CreateObject("vbWrappers.SetCursorPos")
pointer.MoveTheCursor 100, 80

The 100 and 80 coordinates are arbitrary. Change as needed to hover in the correct spot.

Good luck. 

[Salmon Trout]

I was unaware VBScript even ran on IBM mainframes.

It doesn't. He wrote

We've got an IBM mainframe, with 3270 on our machines to access the data.

By "3270" I think he means a terminal emulator program that mimics an IBM 3270 terminal. I would be interested to know how the PC or PCs running this communicate with the mainframe (serial link, modem and phone line, ethernet?) and also how this is set up (priority, serial port interrupts, etc) and whether the mouse is serial or PS/2, and (whichever one it is) if it has been swapped for the other type, and most of all, since they are using a mainframe, and presumably would have some kind of support available, why they are not consulting with support personnel instead of dreaming up an almighty kludge! I presume the VBscript is running in a command window.

[Salmon Trout]

Also there is a great deal we don't know about the Visual Basic Scripts, what the "repetitive tasks" are that they automate, how the scripts were written, etc.

[gsnidow]

Salmon

You hit the nail on the head, the 3270 application is a terminal emulator that opens up a window that looks like something from 1980.  There is no mouse activity at all, with the exception of copy and paste.  There is a macro feature built into the application that lets us program the keys that would normally be keyed, but it is very old VB.  The script runs in another window, as you guessed, and when the mouse is moving over it it screams.  When the mouse is not moving over it, it is like a cold turtle swimming in frozen molassas in Alaska in the middle of January.  As for how it connects to the mainframe, I couldn't tell you, since it comes pre-installed on all of our machines, and the only connection we have is our ethernet.  In any event, I found the answer in AutoHotKey.  Nifty little program that will simply move the cursor back and forth.  I know it sounds strange, but I tested it this morning on 100 identical transactions.  The time it took without the mouse moving was 0:06:32.  The time it took with the cursor moving back and forth via the AutoHotKey program...0:00:26.  As for IT helping us with an issue like that?  Forget it.

Greg

[Geek-9pm]

AutoHotkey - Free Mouse and Keyboard Macro Program with Hotkeys ...
 Introduction. AutoHotkey is a free, open-source utility for Windows. With it, you can: Automate almost anything by sending keystrokes and mouse clicks.
www.autohotkey.com

Good solution.

[patio]

Good solution.

Wow...

[Salmon Trout]

Good solution.

Ridiculous.

[Salmon Trout]

I knew this reminded me of something... I found a reference to what was niggling at the back of my mind. Good old Old New Thing.

http://blogs.msdn.com/b/oldnewthing/archive/2006/02/20/535440.aspx

Sometimes, people discover that a long-running task runs faster if you hold down the mouse. How can that be?

This strange state of affairs typically results when a program is spending too much time updating its progress status and not enough time actually doing work. (In other words, the programmer messed up badly.) When you click and hold the mouse over the caption bar, the window manager waits for the next mouse message so it can determine whether you are clicking on the caption or attempting to drag. During this waiting, window painting is momentarily suppressed.

I notice that gsnidow mentioned "VB Script" and later on changed this to "but it is very old VB". Visual Basic and Visual Basic Script are very different things. I also notice that in the responses to the above quote article, it was mentioned that Gnome-Terminal in Linux had been prone to a similar problem, subsequently solved.

Also the related problem "why does my application run faster when I wiggle the mouse over the main window?"

http://blogs.msdn.com/b/oldnewthing/archive/2005/02/17/375307.aspx