_ArrayAdd problem

[wakillon]

May be i missed something in recent script-breaking changes., but i'm trying the last version (3.3.12.0)  and i can't get _ArrayAdd Function working as previous versions...

Try this :

#include <Array.au3>
;~ Opt ( 'GUIDataSeparatorChar', '*' )

Global $aLinks[1]
Global $aDatas[5] = [ '1', '2', '3', '4', '5' ]

_ArrayAdd ( $aLinks, $aDatas[0] & '|' & $aDatas[1] & '|' & $aDatas[2] & '|' & $aDatas[3] & '|' & $aDatas[4] )
ConsoleWrite ( 'UBound ( $aLinks, 1 ) -1 : ' & UBound ( $aLinks, 1 ) -1 & @Crlf )
_ArrayDisplay ( $aLinks )

Edit : Ok i found a solution : use another delimiter than '|' 

 

Edited June 2, 2014 by wakillon

[BrewManNH]

Other than the rewrite of the array functions, that shouldn't have happened.

That is a bug in the function _ArrayAdd, instead of assuming that the incoming data should be added to the array, it's assuming that if there's a delimiter in the incoming text that it should split it and create the array wrong.

[wakillon]

Ok.

I was thinking that Opt ( 'GUIDataSeparatorChar', '*' )  could resolve or avoid the problem, but it has no effects !

[BrewManNH]

No because the function doesn't allow for a change of delimiter unless you add it to the function call.

[Melba23]

Hi,

 

That is a bug in the function _ArrayAdd

No it is not - the function is behaving just as the Help file says it will:

 

1D arrays:

Single item - adds 1 element

$sDelim_Item delimited string - adds as many elements as items

If you want the "|"-delimited string to be added as a single item then redefine the required delimiter when calling the function:

#include <Array.au3>
;~ Opt ( 'GUIDataSeparatorChar', '*' )

Global $aLinks[1]
Global $aDatas[5] = [ '1', '2', '3', '4', '5' ]

; Redefine the required delimiter
_ArrayAdd ( $aLinks, $aDatas[0] & '|' & $aDatas[1] & '|' & $aDatas[2] & '|' & $aDatas[3] & '|' & $aDatas[4] , 0, "-")
ConsoleWrite ( 'UBound ( $aLinks, 1 ) -1 : ' & UBound ( $aLinks, 1 ) -1 & @Crlf )
_ArrayDisplay ( $aLinks )

As stated in the changelog:

 

Changed: Re-wrote Array UDF to add 2D support and add some functions. THIS IS A SCRIPT BREAKING CHANGE.

So the function is working as designed - but not the same way as before, which is what the changelog says.

M23

[BrewManNH]

Ok, so it's working as intended, but should that be the way it should work? Just because it's listed in the changelog doesn't mean it was a good change.

[Melba23]

BrewManNH,

The new _Array_Add function has been working like that since the Array library rewrite began. I asked for comment here and here - no-one mentioned any concerns at the time. And the new library has been in the Beta since v3.3.11.4 released on 7 April 2014 - again with no complaints until now.

Is it as good change? In my opinion it is - the entire Array library now offers 1D/2D functionality (where sensible) and the change required to scripts in this particular _ArrayAdd case is minimal.

M23

[guinness]

I see no issue and made my opinion well known on this matter.

[BrewManNH]

I never tested _ArrayAdd because I have no use for it myself, so that one slipped by me.

[Melba23]

BrewManNH,

So what would you have suggested as an alternative method had you noticed and commented during the past 4+ months?

M23

[BrewManNH]

First, I would see what the the current delimiter is set to rather than assuming it's "|" (Opt("GUIDataSeparatorChar")), currently the function doesn't take into account that someone might be using a different one. If they use the Default keyword, it should grab the current delimiter to use to split the text.

[czardas]

I thought private range Unicode characters had been selected for delimiters. I haven't got so far as testing anything, so I don't know what's changed yet. The discussion about this was about 6 months ago.

---

Hmm!

I suppose it doesn't make a difference if the delimiter in the string is not specified by the user.

Edited June 3, 2014 by czardas

[Melba23]

BrewManNH,

Alas you are going to be very disappointed when you finally get around to looking closely at the Array library - the default delimiter is also set to "|" in the Insert, ToClip & ToString functions. I can only presume that you do not use those functions either and so never looked at nor tested them when I sought comment. But as I demonstrated earlier, it is very easy for the user to set another delimiter when calling the functions, so I do not see any reason to change them now.

---

czardas,

A Unicode character is used as a delimiter in _ArrayDisplay so that all characters will display - nothing to do with how delimited strings are split elsewhere in the library.

M23

[czardas]

Okay. It's a pretty safe choice, I think.

[RTFC]

Hi Melba, other devs et al.,

While  fixing my broken CodeScanner I came across this novel _ArrayAdd change, when trying to add the string "|" to a 1D array, which fails (it stores two single quotationmarks, like so:

#include <Array.au3>
Local $test[1]
$text='"|"'
_ArrayAdd($test,$text)
_arraydisplay($test)

I understood the new helptext to mean that the new 2D-supported functionality would not apply when parsing a 1D array. Yet my example still produces two separate entries.

Before I go and rewrite every _arrayAdd I ever used (and CodeScanner has to be able to process any string, so I would have to determine what dummy character I could use as faux delimiter for every instance separately), I'd greatly appreciate  it if somebody could clarify whether my example's behaviour is supposed to happen or whether _arrayAdd needs to distinguish between 1D/2D cases before processing delimiter characters by default as delimiters and not as characters. I'm slightly confused.

Thanks in advance for any help.

Edit: upon further reflection, I guess the default delimiter applies to 1D cases too. I can see that this could be useful, it just creates a serious headache for my codes.

 

Oh, one other thing re. Array.au3,  the new _ArraySwap helptext refers to boolean $bRow, which if true should swap rows (if I understand it correctly, that is), but looking at the example it seems to swap columns when true , so should perhaps be renamed $bCol??? Or am I missing something?

Edited June 9, 2014 by RTFC

[Melba23]

RTFC,

 

Before I go and rewrite every _arrayAdd I ever used

Sorry, but we did warn that "THIS IS A SCRIPT BREAKING CHANGE" when we released the new Array library. We felt the added functionality was worth the inconvenience.

 

if somebody could clarify whether my example's behaviour is supposed to happen

I thought I did that in post #5. What happens in that script is exactly how the UDF is designed.

 

I understood the new helptext to mean that the new 2D-supported functionality would not apply when parsing a 1D array

I am afraid that you understood incorrectly - and this has nothing to do with 2D functionality. Did you run the first of the associated examples in the Help file - the section headed:

; Add a delimited string - each item adds new element

shows exactly what happens with a "|" delimited string - as stated each item adds a new element.

 

CodeScanner has to be able to process any string, so I would have to determine what dummy character I could use as faux delimiter for every instance separately

I do not believe that is necessary. All you need do is set the required delimiter to a non-used character (we used one of the user-defined Unicode characters in _ArrayDisplay) when you call the function - as I also demonstrated in post #5. That way your string will never be converted to multiple elements as the delimiter will never match - so a simple fix which you can simply paste in every time you call the function.

I will look into the _ArraySwap code later - thanks for the heads-up.

M23

Edit: Looks like I got the Help file the wrong way round for the parameter in _ArraySwap - thanks again for pointing it out.

Edited June 9, 2014 by Melba23

[RTFC]

I guess I owe you an apology, Melba.   I didn't check that example you mentioned, and I guess I should have looked into the background of this change more carefully before posting. I did work out my own workaround as well, and the expansion to support 2D arrays more substantially is of course a welcome addition.  But I guess any script-breaking change will elicit lots of frustration if only because of the change itself and the bother of adjustments to be made to scripts that were functional before (my CodeScanner will be leaving intensive care soon though, just ironing out some creases now). I've also had several bad experiences with other formerly working environments that took many, many days to get up and running again after a harmless little upgrade (<cough>MSVC<cough>Nvidia<cough> ). It's then easy to slip into a kneejerk reaction whenever anything breaks. That's no excuse, though, more post hoc rationalisation.

Edit: as an afterthought, would it perhaps make sense to include the option to parse an empty string for the user-defined delimiter to indicate that row-splitting should not be applied?

Edited June 10, 2014 by RTFC

[Melba23]

RTFC,

No problems - I quite understand. But we did try to make the changes as obvious as possible - there is even a special page in the Help file explaining the changes to the Array library.

 

When I was rewriting the Array library I did consider adding code to look for the character set in Opt(GUIDataSeparatorChar) but I decided against it and I still believe that the solution of having parameters for the user to set specified delimiters is the better option. But we may just have to agree to differ on this point.

M23

P.S.

post hoc rationalisation

Got the tee-shirt for that one!

[thebreaker]

I have a serious problem with the _ArrayAdd function as well:

I already read that the syntax changed, and although it means I have to change my scripts, I can live with that.

But I can't make the new function support what I need:

What I currently use as functionality from the "old" version of _ArrayAdd is to store whole arrays as objects in an array.

My use case is that I read many files (with _FileReadToArray) which I use later on.

To avoid that the files have to be read multiple times, I store them in an array with _ArrayAdd($dataArray, $myFileContentArray).

The problem is that the new _ArrayAdd function detects that the object I want to add is an array, splits it up and adds the single elements (lines). That's not what I want.

How can I have the old behavior (storing the whole "file content array" as one element)? I read that the new _ArrayAdd has this $hDataType parameter. Is there a possible value I could use to make the new _ArrayAdd store the complete array as with the old _ArrayAdd function? I did not find something in the documentation.

[Melba23]

thebreaker,

Welcome to the AutoIt forums.

You can very easily do what you want with a simple function:

<snip>

I will look at the UDF to see how I might add this functionality to the existing _ArrayAdd function.

M23

Edit: See next post.

Edited July 12, 2014 by Melba23