Match error with INI file

[Tripredacus]

I've found another issue concerning matching data in an INI. Since my last type of problem I found was due to a hardware problem, this may be the case here, but I figure I'd post this and see if anyone has any idea about it.

Global $bin = IniReadSectionNames("z:foldertype.ini")

; Board Manufacturer from WMI
$sWMIService = "winmgmts:" & @ComputerName & "rootCIMV2"
$objWMIService = ObjGet($sWMIService)
IF IsObj($objWMIService) Then
    $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_Baseboard")
    If IsObj($colItems) Then
        For $oItem In $colItems
            $sModel = StringRegExpReplace($oItem.Product , "[/()]", "")
        Next
    EndIf
EndIf

; Find board name in list
For $r = 1 to $bin[0]
If StringStripWS($bin[$r], 8) == StringStripWS($sModel, 8) Then
    Global $Sections = IniReadSectionNames("z:folder" & StringStripWS($sModel, 8) & ".ini")
    $source = "z:folder" & $sModel & ".ini"
    Global $Radio[$Sections[0] + 1], $SectionContents, $topPart, $sname, $vname, $Button1
    Global $Fun[$Sections[0] + 1]
    Global $support = "yes"
        ExitLoop
    ; If board not found, read old ini file
Else
    ;Show default
EndIf
Next

The ini file only has sections and currently has 4 of them. Here is a sample:

[Section1]
[Section2]
[Section3]
[Section4]

Let's pretend that the value pulled from WMI is "Section4". In the INI file example, Section4 is the last section in the list. When this is the case, the variables match, but I end up with the "Subscript used with non-Array variable" error.

If I put [section4] in any location in the INI file besides the last, the match fails and the default code is run.

In an interesting development, if I put MsgBox after the match to display me the WMI value, I get 4 MsgBox before the error. I also did a test using hex conversion verify that both the data in the INI and the WMI actually match, in case there are any other characters I can't see or there is an encoding difference. I did confirm that both values had matching hex conversions.

Any ideas why the match condition would vary depending on where the section was located in the INI?

I will do an additional test using the WMI Tools to see if there is something up with this particular peice of hardware.

Update: Removed the part of this post about not being able to replicate it with other hardware. I have. With another system, if the matching section is last in the INI, it works, but in any other location the default action is done (caused by a mismatch).

Edited June 12, 2012 by Tripredacus

[Tripredacus]

Bump...

I passed code of to another programmer and appears the code is correct but suspects there may be a bug in the IniReadSections function. Or it could be there is a better way to code it.

[BrewManNH]

If the WMI query returns more than one entry, then the $smodel variable is only going to contain the last entry returned, not all of them. You should debug this by seeing what $smodel contains after this section by adding a consolewrite, or msgbox.

If IsObj($objWMIService) Then
     $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_Baseboard")
     If IsObj($colItems) Then
          For $oItem In $colItems
               $sModel = StringRegExpReplace($oItem.Product, "[/()]", "")
          Next
     EndIf
EndIf
ConsoleWrite("$smodel = " & $smodel & @CRLF)

See if it matches what you think it's supposed to be.

[Tripredacus]

Thanks, I already do report this model data. I have a place on the GUI that shows it! So, as an example if I want to see it I can either run my test app (that just shows me that data in MsgBox form), or I can rig the INI to fail the match on purpose, which loads the default GUI but still shows me the data. As I mentioned in my first post, I even went to the trouble of converting both the INI and WMI variables to Hex to see if there was an encoding problem, which there wasn't.

Oh and I can confirm there is only 1 value there for that item. I verified that for sure using the WMI Toolkit.

[Tripredacus]

I have the solution to this problem. While I did not post the entire code, it isn't impossible to determine what the problem is. This opens my eyes a little to how I can read other people's code to give clues on how to help others on this forum. Here's how it could be determined. This is based on the idea that unless I was using code pilfered from elsewhere (I'm not) that I am using things that are actually needed. As most people wouldn't use something they didn't need, right?

So look at how I am using the WMI data:

$sModel = StringRegExpReplace($oItem.Product , "[/()]", "")

I am using StringRegExpReplace on the WMI data for a specific reason. In some instances, some of those characters I am removing show up and I can't have them in my variable. So now look at how I end up using this variable of mine:

StringStripWS($sModel, 8)

I am taking out the whitespace when I am using it in the compare and getting my GUI variables. That is because sometimes we get some spaces (obviously) and if you search in this forum you'll find the thread where I initially had this problem and was directed to use StringStripWS. You can see from my code that I am also using this var to set a filename.

This is where the problem was:

$source = "z:folder" & $sModel & ".ini"

I didn't use the StringStripWS at this point, which was what caused the error on the match. The reason the default (or mismatch) part of the code works is because it has a hardcoded path and filename instead... which is also the reason why I didn't post that part of the code.

So now I am not able to replicate the Mismatch scenario I was having, but I was able to solve the match error.

Edited June 15, 2012 by Tripredacus