v3.0.103 Unstable - Reloaded

[SlimShady]

uhhh Jon

Are you sure you uploaded the right version?

I downloaded AutoIt3.exe at least 3 times.

Edited November 13, 2004 by SlimShady

[Jon]

uhhh Jon

Are you sure you uploaded the right version?

I downloaded AutoIt3.exe at least 3 times.

Yeah, I just downloaded Autoit3.exe and it works fine.

[SlimShady]

I still have the problem with the example script you posted.

What I did?

- I closed all the scripts I have running

- Deleted AutoIt3.exe

- Downloaded the file using FireFox

- Run the script

Edit:

After downloading the file with FreshDownload, the script runs perfect.

It seems FireFox didn't actually download the file.

[SumTingWong]

Wow 10 pages already!

Is v3.0.103 Unstable - Revolution needed yet?

[Jon]

Wow 10 pages already!

Is v3.0.103 Unstable - Revolution needed yet?

You read my mind

[Jon]

I've added some of that magnify magic that everyone has been playing with to AU3_Spy.exe - looks pretty cool. Currently it's drawing the crosshair in the control highlight colour until I can work out how to draw an inverted line instead.

http://www.autoitscript.com/autoit3/files/...oit/AU3_Spy.exe

Edit: Figured out the inverted thing.

Edited November 13, 2004 by Jon

[Josbe]

I've added some of that magnify magic that everyone has been playing with to AU3_Spy.exe - looks pretty cool.  Currently it's drawing the crosshair in the control highlight colour until I can work out how to draw an inverted line instead.

http://www.autoitscript.com/autoit3/files/...oit/AU3_Spy.exe

Edit: Figured out the inverted thing.

<{POST_SNAPBACK}>

Very nice (especially, the crosshair).

BTW, As Pacman says: Revolution it's needed.

[this-is-me]

Thanks a lot, Jon.

:Goes off to download autoit and update script:

Edited November 13, 2004 by this-is-me

[Jon]

Updated AU3_Spy.exe and fixed the screen corruption in the magnifying glass at the extreme edges of the screen.

[this-is-me]

... A small bug, if selecting a computer name, the return should be "\\servername" instead of "servername". It can be scriptde around, but I thought it should be mentioned.

[trids]

.. I downloaded the new Au3_Spy.exe on the weekend, and it worked like a charm on my Win2K machine at home.

.. But the one I downloaded this morning at work (NT4) doesn't seem to have the MRU stuff in it anymore. Not sure if this is an NT issue, or do the EXEs differ?

Edit: details

Edited November 15, 2004 by trids

[Jon]

.. I downloaded the new Au3_Spy.exe on the weekend, and it worked like a charm on my Win2K machine at home.

.. But the one I downloaded this morning at work (NT4) doesn't seem to have the MRU stuff in it anymore. Not sure if this is an NT issue, or do the EXEs differ?

Edit: details

I've tried it on 95 and XP, should be ok...

Edit: Hmm, no doesn't work on NT...that's really odd.

Edit: Oh silly me, it won't save the settings (i.e. messing up the registry) unless you have AutoIt fully installed via the new installer.

Edited November 15, 2004 by Jon

[Jon]

http://www.autoitscript.com/autoit3/files/unstable/autoit

Updated:

- Added Holger's DirGetSize()

- Added JP's fix for auto sizing pic controls if w/h is 0 (maybe it should be -1...)

- Fixed GuiCtrlSetCursor()

Next on my list is a "dummy" control that you can set/read/force notify as a sort of intrascript communication, and control specific context menus.

[jpm]

http://www.autoitscript.com/autoit3/files/unstable/autoit

Updated:

- Added Holger's DirGetSize()

- Added JP's fix for auto sizing pic controls if w/h is 0 (maybe it should be -1...)

- Fixed GuiCtrlSetCursor()

Next on my list is a "dummy" control that you can set/read/force notify as a sort of intrascript communication, and control specific context menus.

<{POST_SNAPBACK}>

w=-1 or h=-1 means use previous default sizing so that the reason I choose 0

Did you forget to upload the installer version? or I am too early

[Jon]

w=-1  or h=-1 means use previous default sizing so that the reason I choose 0

Did you forget to upload the installer version? or I am too early

I forgot, sorry :">

[stingjoel]

Jon, I think I found a bug at GUICtrlCreateList & GUICtrlCreateCombo...it need long time to create it....please check....my scripts act different after I download last unstable.... :">

[stingjoel]

My Scripts have 3 GUI....1 GUI without List/Combo Control, 1 GUI with 7 Combo Control and 1 GUI with one List Control....

When I run it (before I install the 2nd last unstable autoit), I can show every GUI...but after I install the 2nd last unstable autoit (sorry, not the last one), The GUI can't show like usual....when I debug it one by one, the problem is in Combo/List control...the control need time too long to create...so, the GUI can't show like usual (some of control at GUI #2 show in GUI #1)....

Sorry for my bad english....I hope u understand my explanation...

just a wee bit more info and our imagination may have a starting point...

Lar.

<{POST_SNAPBACK}>

[trids]

StringReplace appears to be extremely slow .. in the beta versions downloaded today, and the one from a few days ago:

Takes an average of 56 seconds to process a file of 1,000 records, where each record has 15 semicolons each of which I'm replacing with a @TAB.

By comparison, a text editor's Search & Replace (TextPad) takes only 20 seconds to process 15 times as many records

Here's my call to StringReplace:

FileWrite($sFileDAT, StringReplace($sData, ";", @TAB,0,0))

Is there room for improvement or is it just "a lot of data"?

[SumTingWong]

StringReplace appears to be extremely slow .. in the beta versions downloaded today, and the one from a few days ago:

Takes an average of 56 seconds to process a file of 1,000 records, where each record has 15 semicolons each of which I'm replacing with a @TAB.

By comparison, a text editor's Search & Replace (TextPad) takes only 20 seconds to process 15 times as many records 

Here's my call to StringReplace:

FileWrite($sFileDAT, StringReplace($sData, ";", @TAB,0,0))

Is there room for improvement or is it just "a lot of data"?

<{POST_SNAPBACK}>

Looks like the performance penalty is with FileWrite rather than StringReplace. In TextPad, you are doing your find/replace in memory whereas here you are also writing the resultant string to a file.

Also, $sFileDAT seems to indicate a file name rather than a file handle. You will definitely gain some speed by opening the file first and using the file handle. Alternatively, do your StringReplace in memory by looping through a string array and then write the array to your file.

[trids]

Thanks for the suggestion, pacman

But based on my experiments ... the bottleneck is definitely StringReplace. I have already eliminated the file-access angle: if I leave out just the StringReplace, the entire 1.8Mb file gets duplicated in a flash!

And the following code gives the same results, even though there's little doubt that it falls under the "doing it in memory" category:

$sData = FileRead($sFileTXT, FileGetSize($sFileTXT))
        $sX = StringReplace($sData, ";", @TAB,0,0)
        FileWrite($sFileDAT, $sX)