2

I'm trying to iterate over each key of a hash map, and for each key, look it's value up in 3 different maps, assigning to a psCustomObject. For some reason, after just going through the foreach once, the resultsCase looks like this, and the length is the same as the map I got the Keys out of in the foreach statement. Every time it iterates thru the foreach, it populates the 69 rows again, over-writing them:

Object[69]
[0]: @{sdkErr=HopResultMap3[seFatal];sdkDesc=HopResultMap2[seFatal];sdkOutErr=HOP_FATAL_ERROR}
[1]:@{sdkErr=HopResultMap3[seInterface];sdkDesc=HopResultMap2[seInterface];sdkOutErr=HOP_INTERFACE}
...
[68]: @{...}

As you can see, it's only resolving the map lookup for the last item above.

I'm not sure why it's not doing the lookup in the other map, and actually putting the value in the $resultCase. It only does it right for the last one, which is coincidentally, the map I'm using for the foreach. I designed this so I could use the key from the first map and use it to look up values in the other two maps. I need a combined map here so I can re-use code for something that has a different file structure.

$resultCase = foreach ($key in $HopResultMap.Keys){ 
            [PSCustomObject][ordered]@{
              sdkErr      = $($HopResultMap3[$key]) 
              sdkDesc     = $($HopResultMap2[$key]) 
              sdkOutErr   = $($HopResultMap["$($key)"])
            }
         

 }

I've also tried this with this sort of thing for Map2/3 and it didn't change the results:

$($HopResultMap2[$($key)]) 
and also 
$($HopResultMap2["$($key")]) 

For reference, the maps look like this:

HopResultMap:

OrderedDictionary[69]
[0]:@{seFatal,Hop_Fatal_Error}
[1]:@{seInterface,Hop_Interface}
...

HopResultMap2:

OrderedDictionary[69]
[0]:@{seFatal,"Fatal error"}
[1]:@{seInterface,"Interface not.."}
...

HopResultMap3 (have a little extra in the third one, but the extras have a different key...like sc...):

OrderedDictionary[120]
...
[16]:@{seFatal,"0"}
[17]:@{seInterface,"1"}
...

I can't really change the psCustomObject data structure, because I have another model that has the same data structure. This is with powershell 5.1, and VSCode.

Update:

The 3 maps are all constructed (similar to) this way:

function Get-Contents60{
    [cmdletbinding()]
    Param ([string]$fileContent)


            #m_HopErrorMap.insert(make_pair(
            #MAKEWORD(scError,sePaperJam),
            #HOP_JAM ));

    # create an ordered hashtable to store the results
    $errorMap = [ordered]@{}
    # process the lines one-by-one
    switch -Regex ($fileContent -split '\r?\n') {
        'MAKEWORD\([^,]+,([^)]+)\),' { # seJam, seFatal etc.
            $key = $matches[1]
        }
        '(HOP_[^)]+)' {
            $errorMap[$key] = $matches[1].Trim()
        }
    }
    return $errorMap
}
mklement0
  • 382,024
  • 64
  • 607
  • 775
Michele
  • 3,617
  • 12
  • 47
  • 81
  • 1
    All your _ordered dictionaries_ are actually an array of _ordered dictionaries_, you should take a step back, and reconsider how are you constructing them – Santiago Squarzon Feb 04 '22 at 21:21
  • @SantiagoSquarzon - I added an Update to show how I'm constructing the 3 maps. – Michele Feb 04 '22 at 21:27

1 Answers1

2

Since you are dealing with arrays of hash tables and not with hash tables, referencing by [$key] will be null, this should likely solve the problem:

$dict1 = @(
    @{seFatal = 'Hop_Fatal_Error'}
    @{seInterface = 'Hop_Interface'}
)

$dict2 = @(
    @{seFatal = "Fatal error"}
    @{seInterface = "Interface not.."}
)

$dict3 = @(
    @{seFatal = "0"}
    @{seInterface = "1"}
)

foreach($key in $dict1.Keys)
{
    [pscustomobject]@{
        sdkErr = $dict3.$key
        sdkDesc = $dict2.$key
        sdkOutErr = $dict1.$key
    }
}

The result would be:

sdkErr sdkDesc         sdkOutErr
------ -------         ---------
0      Fatal error     Hop_Fatal_Error
1      Interface not.. Hop_Interface

As mklement0 points out, referencing the Keys property ($dict1.Keys) of each element of the $dict1 array (the same applies to $dict2.$key and $dict3.$key) is possible thanks to member enumeration.

Santiago Squarzon
  • 41,465
  • 5
  • 14
  • 37
  • 1
    The difference I see is that you are missing $resultsCase to assign the psCustomObject to, and you got rid of ordered in that data structure. Plus you are doing $HopResultMap3.$key instead of what I had. It's weird, when I am stepping through it, I saw what I used to have, but when I let it run through, with assigning the data structure to $resultCase like I had, it did wind up having everything in it correctly. That's great! Thank you! :) – Michele Feb 04 '22 at 21:42
  • 1
    @Michele my pleasure, glad it worked :) – Santiago Squarzon Feb 04 '22 at 21:48
  • 1
    @mklement0 thank you sir :) your feedback is always appreciated – Santiago Squarzon Feb 04 '22 at 22:04
  • 2
    Glad to hear it, thanks for updating. Good to see that the term has - finally - made it it into the official docs (though it arguably also at least deserves mentioning in [about_Properties](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Properties) and [about_Methods](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Methods)) – mklement0 Feb 04 '22 at 22:24
  • 2
    @mklement0 I was searching official docs for this term for ages. Still the term doesn't appear to be indexed very well by search engines (even MS docs built-in search engine doesn't find it). They seem to confuse it with enums. – zett42 Feb 04 '22 at 22:27
  • 1
    @mklement0 hehe, I know I saw it on about_Arrays which is the official doc I've referenced, but yes, as zett42 points out, Member Enumeration is not well documented – Santiago Squarzon Feb 04 '22 at 22:31
  • 1
    They must have added it very recently, perhaps in response to this - still open - GitHub docs issue: https://github.com/MicrosoftDocs/PowerShell-Docs/issues/8437 /cc @zett42 – mklement0 Feb 04 '22 at 22:34
  • 2
    @mklement0 Still not the ideal location, in my opinion. I just commented this at the GitHub issue. – zett42 Feb 04 '22 at 23:02