SetError And SetExtended not integer value

[anonymous]

Therefore in 3.3.13.1 autoit beta, developers have managed to return in @extended macro not a number, it can be seen in the function FileFindNextFile.

(Return a string in @extended in the same format as FileGetAttrib())

Therefore the question.
Can be improved SetError And SetExtended function so that the returns are not just a number.

[TicketCleanup]

Automatic ticket cleanup.

[czardas]

I don't really see a reason to change behaviour if an integer value suffices. Other than having to reference the meaning of an error, or extended, value; there is no further inconvenience. There are already many ways to create multiple return values, which perhaps ought to be prefered over any additional internal complexity. Advise me if I'm wrong.

[anonymous]

There are already many ways to create multiple return values

but what prevents little change seterror? Then it will be possible to write such elegant things as:

Return SetError(0, 'MB', 1024)
Return SetError(0, 'PTR', $DATA)
Return SetError(0, 'CDROM', 'F:')
Return SetError(0, 'YYYYMMDD' 20140811)

Instead of using Byref, Global, Array ...

[czardas]

As things are, it is neither necessary to use ByRef nor a global array. The code I posted in the following topic demonstrates this.

​http://www.autoitscript.com/forum/topic/163429-can-extended-be-a-string/?p=1190642

I question the need for a change, but I also appreciate the previous poster's concept.

[anonymous]

extended so it is called, so you can return additional information from the function, and why it should only be a number, it is not clear!

[BrewManNH]

Microsoft decided long ago that error codes would be numeric. No one seems to mind that, so I don't understand why you'd expect AutoIt to do something like this.

[Melba23]

Personally, I think this would be a good addition to the language. We are talking about @extended and not @error so I do not find the "MS numeric error code" argument particularly convincing. Being able to pass strings as well as numbers could be very useful.

And Jon has only himself to blame for having implemented the FileFindNextFile @extended return in that way - if he had stuck to a numeric value (as is returned by the API) the question would not have arisen!

M23

[Jpm]

Hi,
Fix sent to Jon