Just getting some time to really sit down and make some real world things happen and I find myself wanting to automate applications which are GUI based. This presents a problem because everytime you want to do something, you have to be cognisant with which window within the program you are working with. With many child windows, this becomes somewhat of a pain.

Is there a feature forthecoming, or can I request a new feature to have it watch your mouse clicks and keystrokes to generate the scripts automatically?

This would be a wonderful enhancement to an already execellent program.

Playing recorded mouse clicks is very unreliable as it can potentially cause a lot of undesired things to happen. For example, if a target window has several buttons: Connect, Add, Delete, etc… At some point the window gets displayed a little bit above the place where it was at the time of recording, and viola your script can click the Delete button instead of the Connect.

However, there is a solution to this problem, maybe not a simple one but at least significantly more reliable with virtually any logic build in.

Every window has a unique id called window handle and every button, list box, drop-down, check box, and so on is a window itself. All windows are linked as parents, children and siblings. 24x7 offers bunch of various Window... statements that can be used to find windows, drill down to buttons, lists, tabs, and so on then you can press them or click using SendKeys or WindowButtonClick statements. Note that these clicks are different from mouse clicks based on screen positioned clicks. WindowButtonClick generated clicks are result of virtual clicks that trigger direct events in the specified objects. Using these low level Windows statements you can automate a lot of things, including for example clicks on disabled buttons that work as if these buttons were enabled. The bad thing is that window handles are not the same every time you open the same window it has a new handle. That's why WindowButtonClick and SendKeys cannot be *recorded* specifically for the desired application or window. You should always find the window before you can send an event to it.

By the way, there is an enhancement pending for mouse and key recording, but it has a low priority. The priority can be increased if more people request this feature.

: Just getting some time to really sit down and make some real world things
: happen and I find myself wanting to automate applications which are GUI
: based. This presents a problem because everytime you want to do something,
: you have to be cognisant with which window within the program you are
: working with. With many child windows, this becomes somewhat of a pain.

: Is there a feature forthecoming, or can I request a new feature to have it
: watch your mouse clicks and keystrokes to generate the scripts
: automatically?

: This would be a wonderful enhancement to an already execellent program.

I have seen this feature on another scripting program (specifically for 95, doesn't work on NT). Basically, the "recording" application minimizes and catches the handles of any windows and child windows that you click on to effectively "record" what you do. It's a feature that is convient because it saves the end user from having to go through a lot of trouble detecting the correct windows and child windows by doing it automatically.

The way it gets around the changing windows handles was to spawn the new application itself as a child process and it captured the handle in that manner.

: Playing recorded mouse clicks is very unreliable as it can potentially cause
: a lot of undesired things to happen. For example, if a target window has
: several buttons: Connect, Add, Delete, etc… At some point the window gets
: displayed a little bit above the place where it was at the time of
: recording, and viola your script can click the Delete button instead of
: the Connect.

: However, there is a solution to this problem, maybe not a simple one but at
: least significantly more reliable with virtually any logic build in.

: Every window has a unique id called window handle and every button, list box,
: drop-down, check box, and so on is a window itself. All windows are linked
: as parents, children and siblings. 24x7 offers bunch of various Window...
: statements that can be used to find windows, drill down to buttons, lists,
: tabs, and so on then you can press them or click using SendKeys or
: WindowButtonClick statements. Note that these clicks are different from
: mouse clicks based on screen positioned clicks. WindowButtonClick
: generated clicks are result of virtual clicks that trigger direct events
: in the specified objects. Using these low level Windows statements you can
: automate a lot of things, including for example clicks on disabled buttons
: that work as if these buttons were enabled. The bad thing is that window
: handles are not the same every time you open the same window it has a new
: handle. That's why WindowButtonClick and SendKeys cannot be *recorded*
: specifically for the desired application or window. You should always find
: the window before you can send an event to it.

: By the way, there is an enhancement pending for mouse and key recording, but
: it has a low priority. The priority can be increased if more people
: request this feature.

First of all, thanks for the rapid reply.

I recognize that this is not a trivial feature to implement, but neither is it for the developer of the JAL script, and Whew! is it prone to errors!

I wonder if there are some existing components out there that you can plug into to provide this functionality without having to code it yourself. I know that some products can do this functionality, maybe if one has the ability to write to a text file, it could be imported in and generated from that output file.

Just a thought....

Regards,

Steven Garno

: Playing recorded mouse clicks is very unreliable as it can potentially cause
: a lot of undesired things to happen. For example, if a target window has
: several buttons: Connect, Add, Delete, etc… At some point the window gets
: displayed a little bit above the place where it was at the time of
: recording, and viola your script can click the Delete button instead of
: the Connect.

...