[Implemented] StringField() empty string out-of-range

[Michael Vogel]

I'm not sure if I will like to see differences in program execution between debugger mode and non debugging mode
This won't make debugging easier, what do you think?

What do you mean? Its legal input remains the same. Only it fails more gracefully.

In my opinion, it should be legal to use out-of-bounds fields, and these should return null strings. This way the command is more forgiving, and in some situations it may be useful.

I absolutely agree, that the values out of the borders result in NULL strings - or (even better?) return the separator string!

But don't allow to get different return values depending if debugging is on or not (that is what I expect when reading freds posting) - maybe other functions will follow?

Trouble shooting wouldn't be as before, you won't be sure if everything if your resulting exe will work fine even if everything works as expected in debugging mode.

Just a (n absolute simple) example, but - as I understood it - you could get two different results here...

Code: Select all

If Len(StringField("mode on|mode off",mode,"|"))=0
	MessageRequester("Mode no set","");"Result = '"+StringField("mode on|mode off",mode,"|")+"'")
Else
	MessageRequester("Everythings fine","Result = '"+StringField("mode on|mode off",mode,"|")+"'")
EndIf

Michael

[blueznl]

Yes, behaviour should be similar as much as possible. I can understand the debugger would catch some problems, but that should not affect code logic.

[Trond]

But don't allow to get different return values depending if debugging is on or not (that is what I expect when reading freds posting) - maybe other functions will follow?

He didn't say that. He said it will always return a null a string, and if the debugger is enabled, it will give an alert (error or warning). IMO the warning is not necessary, index < 1 should be a legal input returning an empty string.

[Kurzer]

What about this suggestion?

Result.i = StringField(Sourcestring$, Destinationstring$, Index, Separator$)

Rssult.i will be #True, if the Index is valid and #False if not.
Destinationstring$ receive the Stringfield

[Mistrel]

How about we leave it alone? I use this function a lot and rely upon the current implementation. Does the way it function now break anyone's code or is this just nitpicking?

I think a better argument would be: why doesn't it support string-length fields instead of just character-length fields. I would like to see that.

[blueznl]

How about we leave it alone? I use this function a lot and rely upon the current implementation. Does the way it function now break anyone's code or is this just nitpicking?

Well, it doesn't bother me much, but it may confuse other newcomers. It seems a bit inconsistent and if you would ask me what would be the better implementation, well... Yet frankly: whatever

I think a better argument would be: why doesn't it support string-length fields instead of just character-length fields. I would like to see that.

Heh That is why I have my own x_stringfield() function, which does exactly that: support longer strings as delimeter fields