Report Help File Issues Here

[Lupo73]

The _FTP_FileTimeLoHiToStr() description is wrong:

"Closes the _FTP_Open session." needs to be replaced with "Get FileDateTime String."

In _FTP_ProgressDownload() and _FTP_ProgressUpload() the remarks could be restyled to easily read examples.

[guinness]

The _FTP_FileTimeLoHiToStr() description is wrong:

"Closes the _FTP_Open session." needs to be replaced with "Get FileDateTime String."

Done. Thanks.

About your other request I will look more into this as it appears those examples need to be tidied up a little bit.

[guinness]

Number ( expression [, flag ] )

(large snip)

"A string beginning with digits has non-numeric characters stripped"

To me this sounded like a string such as "1,000,000" would return 1000000. It returns 1.

You might change this to something like

"A string beginning with digits has non-numeric characters and all following numeric and non-numeric characters stripped"

In the example, I did see tht 24/7 would return 24. However, since a comma is used very often with a number you might want to at least add

Local $v=Number("1,000" ) ;returns 1

I added a 5th example to clearly show what the remark is referring too. So now there shouldn't be any confusion.

[BrewManNH]

The _PathMake function remarks say:

; Description ...: Creates a path from drive, directory, file name and file extension parts. Not all parts must be passed.

This is incorrect because the function parameters have no default values set, if you omit any of the parts, the function call fails and the script crashes. The header information in the File.au3 file is also incorrect (it's where I got the quoted text above) and should be corrected.

[Valik]

The _PathMake function remarks say:

This is incorrect because the function parameters have no default values set, if you omit any of the parts, the function call fails and the script crashes. The header information in the File.au3 file is also incorrect (it's where I got the quoted text above) and should be corrected.

Proof or it didn't happen. Not only does the function not crash for me it works as advertised. Well other than the root path not adding a "" bug I just found but that's irrelevant. It doesn't crash and it does not require all parts of the path to be present.

[guinness]

It creates an error if all parameters (4) are not passed, so I see the sentence 'Not all parts must be passed.' as a little misleading for those who might misrepresent it as parameters. (This is how I interpret the sentence.)

#include <File.au3>

Local $sFilePath = _PathMake("C:", "Example", "", "") ; Not all parts are passed.
MsgBox(4096, "", $sFilePath)

Edited March 9, 2012 by guinness

[Valik]

Oh, I get it now. It's arguing semantics as to what "not all parameters must be passed" actually means. Two things...

• I am pretty sure I wrote this function long before optional parameters were supported.
• It should be pretty obvious looking at the documentation that all parameters are required which means the interpretation defaults to "some parameters may be empty strings".

I guess if you can come up with a better wording to convey the intent then go for it.

[guinness]

It should be pretty obvious looking at the documentation that all parameters are required

Agreed.

I'll see what I can come up with.

[Valik]

I don't think what you came up with is much of an improvement. It's more technically correct if you wish to argue the semantics behind my original statement but it's awkward at best. Perhaps something like: "You may pass "" (an empty string) for any part of the path you do not need in the final output." Or some variation on that.

[guinness]

OK, I'll re-word it to your suggestion.

[Chimaera]

Macro Reference - System Info

@OSServicePack Service pack info in the form of "Service Pack 3" or, for Windows 95, it may return "B"

Win 2000 minimum now i thought ?

Also im curious what does it return if there is no service pack installed?

Edited March 11, 2012 by Chimaera

[guinness]

Win 2000 minimum now i thought ?

Correct it is. But it's inevitable that someone out there will probably still be using AutoIt on Windows 95, so I believe this should be documented for now. Unless I'm told otherwise.

About your second question, this is for a Dev to answer.

[Chimaera]

Maybe it ought to read

On systems that are Pre Windows 2000 it may return "B"

And maybe the no service pack return should be listed as well?

Once you know what it is.

[GEOSoft]

no support for pre-windows 2k doesn't mean that some autoit functions don't still work on earlier versions. i see no need to touch that at all since it will still return potentially usefull information on win 9x machines.

there is a major difference between "9x systems not supported" and "won't work on 9x systems". if you want to use autoit on 9x then you take your chances is all it really means. many versions ago i removed win 98 from the fonts page but that was of necessity since a new column needed to be added. that doesn't mean that we should test every function on 9x and add notes about whether or not it will work on old systems.

[BrewManNH]

I thought that because they're using newer versions of VS, that the executables for AutoIt won't run on anything pre-Win2K, I may have gotten that wrong, but that's what my understanding was.

[GEOSoft]

i still use the odd function on 9x systems. just limited to which ones will work.

[Richard Robertson]

Not even close. 9x used slightly different libraries than post-9x so the code had to be maintained to use some of the deprecated (and now non-existent) functions to do the same thing in the 9x series.

[Chimaera]

erm lets back up a step

The only reason i mentioned it is because of the 2000+ support.

And because its misleading to me it looks like were still ok for 95 by the way its phrased.

Hence why i suggested

On systems that are Pre Windows 2000 it may return "B"

It doesn't say it wont work just that its inline with current autoit.

Im not making any technical distinction just I thought it could be worded better.

[BrewManNH]

_GUICtrlListView_Create - Help file mentions that if the function fails it returns 0, but doesn't mention that it also sets @error to tell you why it failed.

From the UDF code

If Not IsHWnd($hWnd) Then Return SetError(1, 0, 0) ; Invalid Window handle for _GUICtrlListViewCreate 1st parameter

If Not IsString($sHeaderText) Then Return SetError(2, 0, 0) ; 2nd parameter not a string for _GUICtrlListViewCreate

Further down the function if the DLLCall errors, it returns 0 and sets both @error and @extended to the values returned from the DLLCall

Local $aResult = DllCall('ole32.dll', 'long', 'CoInitializeEx', 'ptr', 0, 'dword', $COINIT_APARTMENTTHREADED)

If @error Then Return SetError(@error, @extended, 0)

Here it returns the errors from the internal function __UDF_GetNextGlobalID and sets @error and @extended

Local $nCtrlID = __UDF_GetNextGlobalID($hWnd)

If @error Then Return SetError(@error, @extended, 0)

I think at the very least it should mention the error values returned so that the user might know why it's failing, they'll be able to figure out that it failed because the LV isn't created, but no idea why.

[AZJIO]

Specify, that GUICtrlCreateEdit/Input by default accommodates no more than 30 000 characters