How to stop string delimiter in _ArrayAdd?

[cyanidemonkey]

This is probably a very simple thing to resolve, but I could not figure it out from the AutoIt Help, or find it on the forums.

I want to use _ArrayAdd with delimiter feature off. I have an issue where a randomly generated string sometimes contains a pipe and is splitting the string. Because it is random string generation (not controlled by me) I can not simply switch the delimiter to another character without the probability it would also randomly break the string.

[czardas]

You could probably use something like ChrW(63743) for the delimiter. How many characters are in the random selection? How is the random string generated?

_ArrayAdd ($aArray, $vValue, $iStart, ChrW(63743))

 

Edited September 24, 2015 by czardas

[Melba23]

cyanidemonkey,

Are you adding a single item each time to a 1D array?

If so, use the $ARRAYFILL_FORCE_SINGLEITEM parameter as explained in the Help file.

If not, then you need to do as czardas has suggested and force the delimiter to a character which is not going to be used - 0xEF0F is from the user-defined set and should pose no problems with normal characters in any language.

M23

[czardas]

Ah, I didn't know about that.

[Melba23]

czardas,

I added that after the last round of complaints.

M23

[TheSaint]

Cannot you just do some replacement (substitution) method in the randomly generated string, before the array is made, which gets restored during a read of the array. For example, use an uncommon ASC II character or combination.

[czardas]

Not really because the problem still remains and you would also have to loop through the array to make the replacements. The characters me and M23 suggested do not exist in any language. In fact this Unicode range is intended for private use, and this is an example of where such characters can come into play. If they do happen to occur within the string (highly unlikely), then you can simply loop through the range until one is found that is not contained within the string. The likelihood of a string containing all Unicode characters (being generated randomly) is so remote that it's hardly worth consideration at all.* On the other hand if the string can contain these private range characters, you should loop through as I suggested. This is actually implemented in my CSV UDF, but I very much doubt the loop ever ran more than once before a suitable delimiter was found

* To try and create such a string using AutoIt would actually be quite difficult.

Edited September 24, 2015 by czardas

[cyanidemonkey]

Thank You Guys.

It is part of an automated test script that is retrieving the random generated password (sent from our server) from our test email account using POP3 etc.

I could not find $ARRAYFILL_FORCE_SINGLEITEM in the Help file. I am currently running on v3.3.12.0 so I suspect I am needing to update to the latest version.
 

[TheSaint]

  On 9/24/2015 at 11:39 AM, czardas said:

Not really because the problem still remains and you would also have to loop through the array to make the replacements.

* To try and create such a string using AutoIt would actually be quite difficult.

Why would you not do the replacement before the string gets added to the array? In other words you test each string for your delimiter first. When you extract (or read) a string from the array, you apply the reverse treatment.

Now that we know it is a password, that gives quite a few replacement characters for use outside the norm, but just to be sure, you could also use a combination of two or three characters that just would never appear together.

[czardas]

  On 9/24/2015 at 10:42 PM, TheSaint said:

Why would you not do the replacement before the string gets added to the array? In other words you test each string for your delimiter first. When you extract (or read) a string from the array, you apply the reverse treatment.

The reason is that it is a slow process. You need to first run a check. Then you replace the characters. At the end you loop through the array and undo all the replacements. Instead of all that - simply add the string and be done (in this case). I think this should be the default behaviour of the function _ArrayAdd(). Further delimiters can be included - depending on the number of dimensions in the array* ...2, 3, 4 etc. I don't think default delimiters should be used, but rather specified by the developer. If no delimiter is specified, I would put everything in the first element created - but that's just my own take on it.

* or the number of additions.

Edited September 25, 2015 by czardas

[czardas]

  On 9/24/2015 at 10:04 PM, cyanidemonkey said:

I could not find $ARRAYFILL_FORCE_SINGLEITEM in the Help file. I am currently running on v3.3.12.0 so I suspect I am needing to update to the latest version.

Yep!

[guinness]

v3.3.14.0 or above to be exact.

[TheSaint]

  On 9/25/2015 at 6:29 AM, czardas said:

The reason is that it is a slow process. You need to first run a check. Then you replace the characters.

It seemed to me that we were most likely looking at a fraction of a second here, so I guess "slow" is relative, dependent on the number of passwords to be processed at any one time, and I would not actually do a separate check or test, just apply the StringReplace to every string before adding it to the array. I don't see where looping through the array comes into it. Replacements occur before add and then only again (the reverse) when reading an entry in the array (loop method or otherwise).

The real question I guess, is whether the array is an array full of passwords or just a single password with some other user data, and if that last is so, then it is likely that slowness is not relevant at all, unless you are processing a whole database of passwords at one time, and they are numbered in the hundreds etc.

Anyway this is a mote point now, seeing as it is not necessary, due to the string being a password, any ASC II character that will not be in the password (if all passwords are standard keyboard based) would be suitable as the delimiter. Then again, perhaps not, if the password is being stored encrypted, which means it could contain any character.

P.S. Obviously I always opt for the simplest approach, but you and Melba23 seem to have the solution well in hand, and the OP seems to understand, so really I'm not arguing against that, just continuing for my own enlightenment and or offering what seems a suitable alternative, just in case. In any case, we lack full knowledge of the complete scenario ... number of passwords, etc.

Edited September 25, 2015 by TheSaint