Modify

Opened 5 years ago

Last modified 5 years ago

#2793 new Feature Request

SetError And SetExtended not integer value

Reported by: anonymous Owned by:
Milestone: Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

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.

Attachments (0)

Change History (7)

comment:1 Changed 5 years ago by TicketCleanup

  • Version 3.3.12.0 deleted

Automatic ticket cleanup.

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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 ...

comment:4 Changed 5 years ago by 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.

comment:5 Changed 5 years ago by 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!

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as new The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.