Modify

Opened 10 years ago

Last modified 7 months ago

#2793 assigned Feature Request

SetError And SetExtended not integer value

Reported by: anonymous Owned by: Jon
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 (9)

comment:1 Changed 10 years ago by TicketCleanup

  • Version 3.3.12.0 deleted

Automatic ticket cleanup.

comment:2 Changed 10 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 10 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 10 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 10 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 10 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 10 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

comment:8 Changed 4 years ago by Jpm

  • Owner set to Jpm
  • Status changed from new to assigned

Hi,
Fix sent to Jon

comment:9 Changed 7 months ago by Jpm

  • Owner changed from Jpm to Jon

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 assigned The owner will remain Jon.
Author


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

 
Note: See TracTickets for help on using tickets.