Ghosting input

[Fran D]

I tried searching, but it was difficult to come up with the terms to quickly find a relevant post, so, at the risk of covering old ground, I'll just ask it here. I am using Scheduler Pro version 7.4.

What I want to do is automate several Windows programs that run some laboratory instrumentation. I want to use the SPACE bar as the trigger to run through all of the programs and take a datapoint at that time. In the simplest sense, it would look like:

Label>MeasureLoop
WaitKeyDown>VK 32
do the measurement stuff here
Goto>MeasureLoop

This works OK, but my problem is whatever window I have focus on still takes the SPACE bar input either as text or, for some of the programs, a tab.

Is there anyway that I can still use SPACE as my trigger, but ignore the actual character it returns?

[gdyvig]

Hi Fran,

You want to manually press the SPACE bar, then the script navigates to each of the programs one-by-one and takes the data points? Then if you press the SPACE bar again it takes another set of data points?

Or do you want to manually press the SPACE bar to navigate from one program to the next, taking only one datapoint at a time?

Any particular reason the trigger has to be the SPACE bar?


Gale

[JRL]

Is there anyway that I can still use SPACE as my trigger, but ignore the actual character it returns?

The simple answer is no.

There are several things you can do to get around this. Depending on what you are trying to accomplish. My favorite is to create a dialog that is the focused window when I want the keystroke to be accepted by my program. The first line after the WaitKeyDown> is a GetActiveWindow>. If the Active window is not my dialog, then the script loops back up to (in your case) Label>MeasureLoop. Hope this makes sense.

Code: Select all

Dialog>Dialog1
   Caption=Measure
   Width=231
   Height=112
   Top=135
   Left=66
   Button=Ok,70,40,75,25,0
EndDialog>Dialog1

Show>Dialog1

Label>MeasureLoop
WaitKeyDown>VK 32
GetActiveWindow>WinTitle,WinX,WinY
If>WinTitle=Measure
Else
  Goto>MeasureLoop
EndIF
Setfocus>Window to be measured
do the measurement stuff here
Goto>MeasureLoop

[Fran D]

Thank you for the replies.

Gale, in answer to your question, it's the first condition that I am trying to build. Hitting the SPACE bar allows me to enter the measurement loop, where the script will then navigate to each program and take data. After it's done, it loops back and waits for the next SPACE bar press to acquire another round of data.

There's really no magic to it being the SPACE bar except that it's a whopping big target on the notebook I have that is sitting on the instrumentation cart. It's a lot easier for the user, who will be gloved-up, to press. However, if you think the only way I may be able to get away with this is by using a non-character key, then so be it.

JRL, I think I understand what you have proposed. In essence, you are saying to create a dummy dialog or trashcan to accept the unwanted characters, correct? Is there anyway to hide that dialog from the user?

Thanks for the inputs so far. It's given me some ideas already.

[JRL]

In essence, you are saying to create a dummy dialog or trashcan to accept the unwanted characters, correct?

Well stated. That is correct.

Is there anyway to hide that dialog from the user?

There are several ways that I'm aware of. Again, it depends on what you want to accomplish. The easiest way is to move the dialog off screen. In the dialog definition block, make the "Top" dimension a very large or a very small whole number such as 100000 or -100000. This makes the dialog not visible on the screen, but it can still have focus.

Code: Select all

Dialog>Dialog1
   Caption=Measure
   Width=231
   Height=112
   Top=-100000
   Left=66
   Button=Ok,70,40,75,25,0
EndDialog>Dialog1

One downside to this is that the user can mouse click somewhere on the screen and remove focus from your trashcan dialog. Another method would be to use the library function mentioned HERE. In Marcus' script there is an "opacity" variable. If opacity is set to 255 the window is fully visible, as the value of the opacity variable approaches zero, the window gets more and more transparent. A transparent window still functions exactly like a fully opaque window. If the opacity variable is set to zero, the window is completely invisible however it also behaves as if its non existent. If the opacity variable is set to one, the window is effectively invisible but also behaves like a fully opaque window.

All that said, if you make a dialog that is the size of the screen, and make it NEARLY invisible, the user won't be able to click on anything but the trashcan dialog. So mouse clicking will not be a issue. of course they won't be able to do any work on the computer either.

If low opacity sounds like the way you want to go there is another library function call that will keep a window on top of all the other windows. You may want to investigate that also. Though this will be difficult, but not impossible, since you are running Macro Scheduler version 7 and doing a waitkeydown>. The task would be easier and more robust if you had event handler capabilities to wait for a keystroke.

[Fran D]

JRL, thanks for the quick reply. That gives me a couple of more things to try and see which would work better for my application.

I actually found the opacity tip late last night, after my original post. I had tried a quick implementation, but the script kept hanging up at WaitWindowOpen>notepad*. Notepad, in fact, was running according to Task Manager, so I'm not sure what the problem was. But, it was late, so I may take a look at that harder, today.

I do have a follow-up question regarding your last statement:

...If low opacity sounds like the way you want to go there is another library function call that will keep a window on top of all the other windows. You may want to investigate that also. Though this will be difficult, but not impossible, since you are running Macro Scheduler version 7 and doing a waitkeydown>. The task would be easier and more robust if you had event handler capabilities to wait for a keystroke.

I'm not familiar with the event handler capabilities. Are you saying it would allow me to capture any keystroke event and then I could branch to whatever part of the script I'd like depending on the key, sort of like a CASE statement? That still wouldn't address visibility, correct? One of the approaches you've mentioned would still be required.

[JRL]

I'm not familiar with the event handler capabilities.

check the online help. Click on "Command Reference" then scroll down to Click on "OnEvent". This will give you an idea of how OnEvent>, Macro Scheduler's event handler, works.

Are you saying it would allow me to capture any keystroke event and then I could branch to whatever part of the script I'd like depending on the key, sort of like a CASE statement?

I'm unsure of the CASE statement reference, but otherwise yes. The script runs normally, usually in a loop where it can check for and or set desired conditions. When a predetermined key is pressed the script processing immediately jumps to and processes the subroutine specified in the OnEvent> Function. The advantage to this over WaitKeyDown> is that the script can continue running checking for and or setting conditions to control the computer while waiting for that key press.

That still wouldn't address visibility, correct? One of the approaches you've mentioned would still be required.

Correct, but the approaches are easier to implement because the script can maintain control of the computer.

[Me_again]

I'm not familiar with the event handler capabilities.

check the online help. Click on "Command Reference" then scroll down to Click on "OnEvent". This will give you an idea of how OnEvent>, Macro Scheduler's event handler, works.

Fran is using 7.4, I think OnEvent may have been added in a later version.

[JRL]

Thanks Me_again.

Yes I was aware of Fran's Macro Scheduler version. That's why I pointed to online help. I guess I should have been more clear.

In order to use OnEvent, Fran will need to upgrade. But prior to upgrading, a quick look at online help might make the OnEvent> potential or lack of potential more clear.

According to "History" OnEvent was introduced in Version 8.0 01/01/2006.

[Fran D]

Yes, I am going through the process to upgrade, but I was actually making great progress using the dummy dialog approach where I've now seemed to have crept into another issue. I will post those issues in another thread, so that I can attract broader views.

However, whether I continue with WaitForKey or OnEvent, it looks like the dummy dialog works best (especially since it is quietly destroyed whenever the script ends rather than asking whether I want to save a text file!).

Thanks for the help.