Sign in to follow this  
Followers 0
hgeras

Send() Issues

15 posts in this topic

I have made this proggie here and it works fine but after some recommendations , im trying to change some things.

What i'm trying to do is to run through cmdline the defrag c: command.

One way to quit this command is to processclose("dfrgntfs.exe") which is the process of defrag c:.... But it is not as safe as pressing Ctrl+C or Ctrl+Break...

Run("C:\WINDOWS\system32\cmd.exe")
WinWaitActive("C:\WINDOWS\system32\cmd.exe")
Send("Defrag d:){ENTER}")
Sleep(10000)
send("^C")

When I try to send in the particular running dos box- which is run through the script- the Send("^C") or Send("{CTRLBREAK}") then none of those are simulated and defrag won't exit.... It only quits if i press the REAL Ctrl+Break.

Now , if i start my own dos box through start-->run-->cmd.exe and give this code

WinWaitActive("C:\WINDOWS\system32\cmd.exe")
Send("Defrag d:){ENTER}")
Sleep(10000)
send("^C")

then ^C works perfectly and aborts defragment....

Does anyone know why those keystrokes arent simulated in the dos box ran thru script and work in the second case?

P.S I've tried with Run(@Comspec & "\c defrag d:") but the same thing happens...

Share this post


Link to post
Share on other sites



this worked on my Windows Xp

ControlSend("", "", "", "!F")

ControlSend("", "", "", "{DOWN}")

ControlSend("", "", "", "{ENTER}")

8)


NEWHeader1.png

Share this post


Link to post
Share on other sites

Just my ramblings on this topic:

(Caveat - you might want to pick a non-critical drive - maybe some drive other than c:)

To those willing to test this, run this one line of code:

Run("C:\WINDOWS\system32\cmd.exe")

manually send ctrl-c to that window - it should give you a new prompt

manually type defrag c:

manually send enter

manually send ctrl-c to that window - it should do nothing

repeat as desired

(yes, ctrl-break works - but apparently not from a script)

manually start another "cmd" window via this method:

start >> Run >> cmd >> enter

manually send ctrl-c to that window - it should give you a new prompt

manually type defrag c:

manually send enter

manually send ctrl-c to that window - it should stop the defrag utility

repeat as desired

guess:

The Windows OS treats these windows differently based on the way they start.

Run this line:

Run(@ComSpec & " /k help | more")

and then try to reuse that cmd window for a defrag and ctrl-c interrupt.

If you create the "cmd" window via a batch file, the "cmd" window looks the same, but as you probably know, ctrl-c gives a different prompt to the user...

@Valuater,

You sent those commands to a "cmd" window?


[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

@Valuater,

You sent those commands to a "cmd" window?

<{POST_SNAPBACK}>

nopper..... just the defrag as such

Run("mmc Dfrg.msc", @SystemDir); for windows Xp
Sleep(5000)
ControlSend("", "", "", "!F")
ControlSend("", "", "", "{DOWN}")
ControlSend("", "", "", "{ENTER}")

it was the defrag "itself" i was trying to control

8)


NEWHeader1.png

Share this post


Link to post
Share on other sites

@Valuater,

That is what I thought... but expected to see "!Fx" for exit.

@hgeras,

I did not mean to hijack your thread - I can only offer confirmation of your original post on my systems and an ugly work around --- have the script create as many batch files as needed, have the script launch them and interrupt them as needed.

BTW, if you ever do find a way to send ctrl-c or ctrl-break to the "cmd" window that is started from a script, you could use this line:

Run("C:\WINDOWS\system32\defrag.exe c: -v")

...and skip the lines that send "defrag c:" to the "cdm" window

(unless that was just for the example in your post)

Of course, you could just use the Dfrg.msc GUI that Valuater hinted at :whistle:)

later....


[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

herewasplato: (BTW Plato was here....hehe)

I see you fully understood what the problem is with your observations.

I didnt find but a rather rookie and uglier way to do this and accept ^C and abort:

Example Code:

send("#r")
send("cmd{ENTER}")
WinWaitActive("C:\WINDOWS\system32\cmd.exe")
Send("Defrag " & _guictrllistgettext ($listbox, $i)& "{ENTER}")
WinSetState("C:\WINDOWS\system32\cmd.exe","",@SW_HIDE)
Sleep(10000)
Send("^C")
ProcessWaitClose("dfrgntfs.exe")
ProcessClose("cmd.exe")

Now this way works successfully.And i'm goin to leave it as is till i find another way.You can check both versions of the whole app through the link in my first post and if you find out something else that works,you are welcome to notify me.

BTW, if you ever do find a way to send ctrl-c or ctrl-break to the "cmd" window that is started from a script, you could use this line:

Run("C:\WINDOWS\system32\defrag.exe c: -v")

...and skip the lines that send "defrag c:" to the "cdm" window

(unless that was just for the example in your post)

This is the original way i used to start defrag but ^C ot {CTRLBREAK} will no way work whatsoever....Check the link if you want....

Run this line:

Run(@ComSpec & " /k help | more")

and then try to reuse that cmd window for a defrag and ctrl-c interrupt.

Is that way tested or just a guess? Because again the cmd window is through the script....

EDIT: I tested this way but no luck...

Valuater:

I see your point but using the MMC version of defrag wasnt my target...

Thanks for the input

Edited by hgeras

Share this post


Link to post
Share on other sites

Sorry, I was not clear about this point:

Run(@ComSpec & " /k help | more")

after running the line of code above you should still have a "cmd" window. Starting defrag from that window just proves that you cannot interrupt it via ctrl-c. Just one more data point to prove the difference in behavior.

The point being that:

"cmd" windows started via AutoIt acts one way,

"cmd" windows started via the OS acts another way,

"cmd" windows started via batch files acts yet a third way.

I had never noticed this difference between AutoIt and the OS start method before.

BTW, I use platowashere, herewasplato and wasplatohere as aliases elsewhere. The AutoIt forum just got the middle one.


[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

OK I got your point now. Unfortunately it seems that there is no other way than the one i had to use....

BTW what I meant is that Plato was INDEED here,the philosopher, cos I'm from Greece as you can see....:whistle:

Share this post


Link to post
Share on other sites

BTW what I meant is that Plato was INDEED here,the philosopher, cos I'm from Greece as you can see....:whistle:

<{POST_SNAPBACK}>

Oh that is funny - I had not noticed that you are from Greece - not that observant today. I was not sure what you meant, I figured that you just wanted me to know that you had figured out the normal order of those words... but that did not seem all that "hehe" to me.

thanks for the laugh... now off to try and stay awake thru a meeting


[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

I had puzzling results with Send() until I found out that you can, and often must, alter the delay at which the keystrokes are sent, depending upon the op system, the hardware and the app. Same statement goes for delays for commands to Windows and their controls.

A segment of code right from the prog:

Opt ("SendKeyDelay", 19)         ;5 milliseconds default Orig=20
Opt ("SendKeyDownDelay", 9)   ;1 millisecond default Orig=10
Opt ("WinSearchChildren", 1)     ;0 is default -- does not search children
Opt ("WinWaitDelay", $c_SleepUnitms * 3)        ;250 millis default  Orig=375

J


If I am too verbose, just say so. You don't need to run on and on.

Share this post


Link to post
Share on other sites

jdickens: I dont think that SendKeyDelay is the key to the problem for one simple reason.... Once you start a cmd window thru the script or batch file and not from Start-->Run-->cmd.exe ,then ^c is not applicable not even from the keyboard,which means that the specific windows wont do us the favor and accept it in any way from what it seems....

Share this post


Link to post
Share on other sites

For those of you that would like to test this with something less dangerous than repeatedly halting a defrag, try this:

Run this one line of code from a script:

Run("C:\WINDOWS\system32\cmd.exe")

Once the "cmd" window comes up

manually type dir c:\windows\system32 and then press enter

before all of the info is displayed - send ctrl-c

(the info just keeps flowing)

Manually start another "cmd" window via this method:

start >> Run >> cmd >> enter

Once the "cmd" window comes up

manually type dir c:\windows\system32 and then press enter

before all of the info is displayed - send ctrl-c

(the flow of info should be interrupted)

The point is - the way that you start the "cmd" window affects your ability to interrupt a process running in that window. It does not impact all processes, but defrag and Dir seem to "not halt" via "ctrl-c" even if that "ctrl-c" is sent manually.

jdickens,

I find it interesting that you have had to adjust the default settings to slow things down. I usually change them to speed things up from the default settings... anyway, would you run thru the steps above and report your findings?


[size="1"][font="Arial"].[u].[/u][/font][/size]

Share this post


Link to post
Share on other sites

I will attempt the experiment should time allow.

I am implementing AutoIt with app called VAM 6.5 or Virtual Accountmate.

The controls are "mostly" non-standard and can only be accessed via tabs, and some even reject cut and paste, so I use keysends.

The PCs are typically PIIs at 350 MHz, running db apps over network.

My AutoIt apps worked great when I developed them, then when I put them in the wild, not all the letters would "take" during the send. Or a tab or two would be missed. Or a child window would pop up a few seconds after I expected it. Miserable!

J


If I am too verbose, just say so. You don't need to run on and on.

Share this post


Link to post
Share on other sites

#15 ·  Posted (edited)

This is the hard way you chose but then again i guess you dont have enough resources to do it through objects huh?

In your case sendkeydelay could be critical as you mentioned above....

And i believe you make the keys delay further cos you are working on very slow machines....

Check the link in my sig.The last posts .I have some info on how office 2003 can give you useful info about objects in any program installed on your pc....It might give you better and more controllable results....

Edited by hgeras

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0