Can this script be shortened

Ianw · Post by **Ianw** » Tue Mar 31, 2009 1:25 pm

Hi,
I use MSched mainly to backup all my settings in the programs files that can backup to other locations.

They work OK, this one is one of the shorter scripts, but they look a trifle long, so I was mulling over the thoughts that they might be made more shorter.

Its not that important but it would be nice to have them more compact, unfortunately I don't know how to do so.
Thanks in advance.

rem
DeleteFile>H:\Configs\Dropit Pro\*.*
wait>3
DeleteFile>E:\Configs\Dropit Pro\*.*
wait>3
DeleteFile>G:\Configs\Dropit Pro\*.*
wait>3
DeleteFile>F:\Utils\Dropit Pro\Mine\*.*
wait>3
DeleteFile>J:\Configs\Dropit Pro\*.*
wait>3
rem
CopyFile>F:\Utils\Dropit Pro\*.txt,E:\Configs\Dropit Pro\
wait>3
CopyFile>F:\Utils\Dropit Pro\*.txt,G:\Configs\Dropit Pro\
wait>3
CopyFile>F:\Utils\Dropit Pro\*.txt,H:\Configs\Dropit Pro\
wait>3
CopyFile>H:\Configs\Dropit Pro\*.txt,F:\Utils\Dropit Pro\Mine\
wait>3
CopyFile>F:\Utils\Dropit Pro\*.txt,J:\Configs\Dropit Pro\
wait>3
message> All done
wait>3
Message>All Done
wait>2

JRL · Post by **JRL** » Tue Mar 31, 2009 4:36 pm

I don't have your computer or your files to test with. I don't believe the delete> and copyfile> functions are modal. That is I think that the script will continue even though the file has not finished being copied or deleted so there are potential opportunities for interference. In the code you posted the only place I see an opportunity for interference is in that the same directories are being deleted from and copied to. So I took out all of the waits except for the one between the deletes and the copies. Hopefully 5 seconds is long enough for all of the deletes to complete. The safer thing to do would be to test each directory to make sure they are empty before copying files back into them. but this would add more code rather than making the script shorter.

Try this see if it works.

Code: Select all

DeleteFile>H:\Configs\Dropit Pro\*.*
DeleteFile>E:\Configs\Dropit Pro\*.*
DeleteFile>G:\Configs\Dropit Pro\*.*
DeleteFile>F:\Utils\Dropit Pro\Mine\*.*
DeleteFile>J:\Configs\Dropit Pro\*.*
Wait>5
CopyFile>F:\Utils\Dropit Pro\*.txt,E:\Configs\Dropit Pro\
CopyFile>F:\Utils\Dropit Pro\*.txt,G:\Configs\Dropit Pro\
CopyFile>F:\Utils\Dropit Pro\*.txt,H:\Configs\Dropit Pro\
CopyFile>H:\Configs\Dropit Pro\*.txt,F:\Utils\Dropit Pro\Mine\
CopyFile>F:\Utils\Dropit Pro\*.txt,J:\Configs\Dropit Pro\
mdl> All done

Post by **Marcus Tettmar** » Wed Apr 01, 2009 8:29 am

DeleteFile and CopyFile are script modal.

JRL · Post by **JRL** » Wed Apr 01, 2009 12:56 pm

DeleteFile and CopyFile are script modal.

For some reason I was thinking they were not. Thank you for the clarification.

jpuziano · Post by **jpuziano** » Sat Apr 25, 2009 8:39 am

JRL wrote:
DeleteFile and CopyFile are script modal.
For some reason I was thinking they were not. Thank you for the clarification.

I also had this mistaken impression. Marcus, could we get a note added to the Help File to remind us that these commands are script modal? Please and thanks.

Also, today I was hoping the ExecuteFile> command wasn't script modal but after testing, I see that it is. Not a problem... but again, an entry in the Help File saying that the ExecuteFile> command is scipt modal would be a helpful reminder.

Thanks and take care

Post by **Marcus Tettmar** » Sat Apr 25, 2009 7:39 pm

I don't know why you guys thought that CopyFile and MoveFile were not "script modal" (assuming by "script modal" you mean the script waits for the command to complete). With these commands the script does not proceed until the operation is complete.

ExecuteFile and RunProgram may appear subtly different in that they *start* a file/program. The act of spawning a new process is complete when that process is created. So in this sense they are modal too. In fact ALL commands are modal. Send sends a character and returns once its in the queue. But this doesn't mean the target app has responded to it yet. ExecuteFile tells the OS to start a file/app and returns but that doesn't mean that app is ready for use yet. The RP_WAIT var can be used to tell RunProgram to wait until the new process has terminated.

JRL · Post by **JRL** » Fri May 01, 2009 4:58 am

jpuziano wrote:Also, today I was hoping the ExecuteFile> command wasn't script modal but after testing, I see that it is. Not a problem... but again, an entry in the Help File saying that the ExecuteFile> command is scipt modal would be a helpful reminder.

mtettmar wrote: The act of spawning a new process is complete when that process is created. So in this sense they are modal too. In fact ALL commands are modal.

Aside from the sense that "ALL commands are modal". And personally defining modality as: the script halts for some extended period possibly until user input such as a modal message or a modal dialog. I don't think of ExecuteFile> as modal. If I use ExecuteFile> to open a text file, the script actually runs the next few lines before notepad has a chance to open on my computer. In the following example the message will pop up first and notepad will open second even though that's opposite the order of the script lines. I actually have to bump the Until>kk= line up to nearly 1000 before Notepad opens ahead of the message. I'm curious what testing brought you to the conclusion that ExecuteFile> is modal. And/or how are you defining "modal".

Code: Select all

WriteLn>%temp_dir%ModalTestFile.txt,wres,Create a text file
ExecuteFile>%temp_dir%ModalTestFile.txt
Let>kk=0
 Repeat>kk
   Add>kk,1
 Until>kk=100
MDL>This message would not pop up until the file is closed if ExecuteFile is modal.

jpuziano · Post by **jpuziano** » Fri May 01, 2009 9:05 am

Hi JRL,

In my script, I was using ExecuteFile> with a .csv file which causes Excel to start up and display that file. On my system, it takes a few seconds for Excel to do this and I was looking to speed things up. The steps preceding ExecuteFile> were:

- pull data via SQL
- close database connection
- write data to a csv file on the disk

I wanted to get that csv file opening faster in Excel so I removed the command that closed the database connection from its normal spot and moved it to immediately after the ExecuteFile> command.

This didn't seem any faster. To see the timing of what was happening, I put the following line immediately after the ExecuteFile> command:

MDL>Now!

Unfortunately, when I ran it... Excel started up as slow as ever... window appeared and eventually loaded the file... and only then did the Now! message appear.

I was hoping that ExecuteFile> kicked off an independent process somehow that would get Excel going and immediately the script could continue and do other things in the time it would take for Excel to load and display the file... but that's not how its working.

Marcus said "The act of spawning a new process is complete when that process is created". I guess if its Excel, we can also tack on to the end... "and Excel is displaying the file so if it takes a few seconds... the script is just going to wait."

Maybe Marcus or someone can shed more light on this topic.

In any case, I just wanted to speed things up. I found that writing all the data to a variable first and then writing that one variable to disk was much faster than looping through the rows and columns and writing it bit by bit to the disk. That one change provided all the speedup I needed.

Marcus... there's another potential Blog topic for you - A list of several common ways to speed up a script by writing it better, using better commands, how to time chunks of code to see where the speed bottlenecks are, how to time one chunk of code against another to see which is faster etc. Any speed optimization tips, tricks or techniques would be much appreciated.

Thanks and take care

Post by **Marcus Tettmar** » Fri May 01, 2009 9:40 am

I was speaking technically. ExecuteFile returns when it has done it's job. It's job is to ask the OS to start a file. When the OS says "ok" it returns. The OS then starts the app and the app is then left to its own devices. In terms of what it's task is it is modal. Of course I realise than in practice this is not how you think of modality. Yes, of course, it is essentially asynchronous since Macro Scheduler doesn't know what happens after a file is started. We therefore need to tell it what to do next. If we wish to interact with that app we need to tell the script how to wait until it is ready, read as far as WE are concerned with what we want to do with it.

JRL · Post by **JRL** » Fri May 01, 2009 2:20 pm

jpuziano wrote:Unfortunately, when I ran it... Excel started up as slow as ever... window appeared and eventually loaded the file... and only then did the Now! message appear.

I was hoping that ExecuteFile> kicked off an independent process somehow that would get Excel going and immediately the script could continue and do other things in the time it would take for Excel to load and display the file... but that's not how its working.

I see what you mean. I altered the test script above so the file created is a .CSV rather than a .TXT file and the message does not pop up until Excel has completed which takes several seconds. Apparently the OS treats Excel differently than it treats notepad. Possibly because Notepad has no dependencies, from the OS perspective, its "open" as soon as its called. When Excel is called, the OS also calls a variety of other files. I'm speculating that ExecuteFile> does not finish until all of those other files have been called.

I understand you have already found a solution for your situation. For future reference a method to get around ExecuteFile>'s modality would be to write the executeFile> line to a temporary script file, then run ExecuteFile> against the temporary script file.

See the example below.

Code: Select all

WriteLn>%temp_dir%ModalTestFile.csv,wres,Create a text file
//Next line writes the excel-opening ExecutFile> to a temp script file.
WriteLn>%temp_dir%ModalTestFile.scp,wres,ExecuteFile>%temp_dir%ModalTestFile.csv
//Next line executes the temp script file.
ExecuteFile>%temp_dir%ModalTestFile.scp

Let>kk=0
 Repeat>kk
   Add>kk,1
 Until>kk=100
MDL>This message would not pop up until the file is closed if ExecuteFile is modal.

DeleteFile>%temp_dir%ModalTestFile.csv
DeleteFile>%temp_dir%ModalTestFile.scp

mtettmar wrote:We therefore need to tell it what to do next. If we wish to interact with that app we need to tell the script how to wait until it is ready, read as far as WE are concerned with what we want to do with it.

And this is another important aspect of this issue. Obviously the script is opening Excel for a reason. How often will there be any need for the script to proceed before excel is ready for use. Seems kind of pointlesss to find a workaround for the modality of ExecuteFile> just to make the next line WaitWindowOpen>Excel*.

Later,
Dick