| Author |
Message |
   
David Antonuk (Dantonuk)
| | Posted on Thursday, Jan 6, 2005 - 22:41: | |
I have a licensed professional copy of WinHex 11.15. I am calling WinHex from a .bat file and running a script to execute a series of commands on against a file. The script is working fine I just want to keep the GUI from opening & closing on the screen every time it is invoked. |
   
Stefan Fleischmann (Admin)
| | Posted on Friday, Jan 7, 2005 - 15:41: | |
Undocumented, available since v11.7: The script command Hidden with the parameter 2 can be used at the beginning of a script to render the WinHex main window invisible. The main window becomes visible again when Hidden 0 is called or when script execution completes (except if the "auto" parameter is specified in the command line). However, the currently active window's caption of another application might flash shortly because it becomes inactive for the duration of script execution. Script example: Hidden 2 MessageBox "Where the heck is WinHex now?" Hidden 0 MessageBox "WinHex is back. Pure magic."
|
   
Paul Mullen (Pcguru)
| | Posted on Friday, Jan 7, 2005 - 23:36: | |
I seem to recall that there is also the turbo command, which speeds up a script considerably by not displaying every change. The last time I looked at this however (which was about 18 months ago) I found that with turbo mode on you couldn't see the progress. I couldn't see any easy way to update a progress window. I am writing a script to rebuild a broken RAID array, copying stripes from each array member drive to the target drive. This seems very slow (many hours to copy just 100 Gb) and I'd like to be able to keep a eye on progress while allowing it to run as fast as possible. Any suggestions? |
   
Stefan Fleischmann (Admin)
| | Posted on Friday, Jan 7, 2005 - 23:42: | |
The progress bar display indeed depends on "turbo" being disabled. If the current position on the drive changes, maybe you could interpret the position of the scrollbar button as a kind of progress indicator. |
   
Mike Montgomery (Mikem22)
| | Posted on Saturday, Jan 8, 2005 - 11:23: | |
If the total is 100 GB and the block size is 64k then you will have a long wait! Our experiments using indicated that it takes approx 30 minutes per GB in a RAID 0 array. Something we found a bit faster was to copy the drives one at a time leaving gaps in the target for the other drives in the array. If you are doing RAID 0 it is a lot easier to script than RAID 5 I dont have access to the scripts just now, but it went somethng along the lines of; Turbo on Open 81h read-only //(Source) Move x // Open 82h in-place // (Target) Move 0 // normally 0 but for other drives will be the blocksize times the number drives in the array. e.g. two drive with 64k blocks would be 'Move 65536' for the seond drive. // Copy the Individual Stripe ( // Start the loop NextObj // Select Source Drive Read Block // Read Source Drive NextObj // Select Target Write Block // Write the Block to Target Move BlockSize // Leave a Gap in Target // If there are more than two drives change the blocksize value to the total number of blocks to move past. ) [TotalBlocks] CloseAll // Done Note ( and ) should be open and closed curly braces Mike |
   
Mike Montgomery (Mikem22)
| | Posted on Saturday, Jan 8, 2005 - 11:27: | |
Correction to above.. Move x // Move past RAID Header x=bytes Read Block Should Be Read Block BlockSize Mike |
   
Paul Mullen (Pcguru)
| | Posted on Monday, Jan 10, 2005 - 20:42: | |
Just looked at the job I left running over the weekend... it had stopped after 8985472 sectors with an error message "Error #21. Error writing to hD 3 Not enough quota is available to process this command." Is this a problem with the swap file? |
   
Paul Mullen (Pcguru)
| | Posted on Monday, Jan 10, 2005 - 20:47: | |
In case it's relevant I am using v11.6 SR 11 |
   
Stefan Fleischmann (Admin)
| | Posted on Monday, Jan 10, 2005 - 22:23: | |
That additional hint "Not enough quota..." originates directly from Windows. Sorry, I have no idea why writing physical hard disk sectors should fail because of a quota. For general considerations I recommend you download WinHex 12.0, which is a free update for you. |
   
David Antonuk (Dantonuk)
| | Posted on Wednesday, Jan 12, 2005 - 20:51: | |
Stefan, Going back to my original question here. I loaded the eval copy of 12.0 and now the gui doesn't open but the Warning Msg box about In-place editing keeps appearing even after I select the box to suppress this message. Also a Details & Data Interpreter box appear every time Winhex is called from the .BAT file. How can I shut these off. |
   
Stefan Fleischmann (Admin)
| | Posted on Wednesday, Jan 12, 2005 - 21:09: | |
I'm sorry, I am 100% sure I did reply immediately, but now cannot find the message I meant to have sent. View | Show | [ ] Details Panel View | Show | [ ] Data Interpreter > Msg box about In-place editing keeps appearing Try to give WinHex a chance to save its configuration, by omitting "Exit" at the end of your script in case it's there (rather use "auto" in the command line to terminate WinHex). Or alternatively have WinHex suppress this error message when you open a file from the GUI (without running a script), then quit WinHex so that the winhex.cfg file can be saved. Or alternatively run WinHex with the GUI and switch away from global in-place edit mode after pressing F6. |
   
Mike Montgomery (Mikem22)
| | Posted on Wednesday, Jan 12, 2005 - 21:17: | |
According to; http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/w2000Msgs/824.asp It could be the pagefile.sys size. Check the free space on the disk where the pagefile is stored. It could be worth setting up a separate partition just for page file. We do this with an 8 GB NTFS partition. Set to adjust automatically. Mike |