How "safe" is it to use the "Scripting.Dictonary" class?

[Angel]

I often miss a having a built-in dictionary type in AutoIt. After looking for information on how to implement my own I found that one of the proposed solutions is to use ObjCreate() to create a "Scripting.Dictionary" object.

While I've used ObjCreate() before to access COM objects from AutoIt, I have never used the "Scripting" library (if that is the proper name).

My question is how "safe" it is to use this library. By safe I mean whether the library and in particular the Dictionary class is available on all versions of windows and whether some particular DLL or windows component needs to be installed to be able to use it (e.g. does it need some visual basic DLL?). That is, can I assume that I'll be able to access the Scripting.Dictionary class on all Windows machines (including different language versions)?

I would also like to know whether there are any security/permission issues related to using the scripting library. In particular, does the autoit script need to be run as an administrator? Will it trigger the User Account Control on Windows Vista and Windows 7?

Finally, are there any speed/performance issues using this? How much slower is accessing a Dictionary element than accessing a regular AutoIt array? I understand that I should not bother much about speed when using a scripting language such as AutoIt, but I would like to know if I need to be specially careful when using this.

If this is safe, fast and is available on all versions of windows, wouldn't it make sense to be added as a UDF with AutoIt?

Thank you in advance,

Angel

[Richard Robertson]

It won't trigger UAC and it will be faster than accessing an AutoIt array (as a dictionary).

I can't say for sure what versions of Windows it is available on though.

[Angel]

It won't trigger UAC and it will be faster than accessing an AutoIt array (as a dictionary).

I can't say for sure what versions of Windows it is available on though.

Thanks for the (quick! :-)) answer Richard!

Do you know whether it requires some additional DLL or library to be installed in WindowsXP and/or Vista/7?

Cheers,

Angel

[zorphnog]

The Dictionary object is part of the scrrun.dll, which I believe is standard on all windows versions.

[Angel]

The Dictionary object is part of the scrrun.dll, which I believe is standard on all windows versions.

Thanks a lot! I want to avoid tying my code to certain versions of windows, but it seems that it should be quite safe to use.

Then, wouldn't it make sense to create a UDF library to create dictionaries? It would be very nice to have a standard way of creating dictionaries in AutoIt.

Cheers,

Angel

[Richard Robertson]

There's no need for a UDF really since the COM object itself does everything.

[Angel]

There's no need for a UDF really since the COM object itself does everything.

I think that a UDF would help in two very important fronts:

1. Discoverability:

How many people have wanted to use a dictionary in Autoit and did not know about the "Scripting.Dictionary" solution? How many of those created their own array based implementation?

Even among those that found the "Scripting.Dictionary" solution, how many had the same sort of questions about availability and security that I did?

Encapsulating this as a standard UDF would solve these issues since people could find it on the AutoIt help file and they would take for granted that the dictionary would "just work", without questioning the actual internal implementation.

2. Initialization:

The Dictionary() function that I propose would be able to automatically initialize the dictionary for you based on a 2 optional arrays containing the keys and the values (respectively). It would also be able to take strings as their inputs and automatically call StringSplit() to create the key and value arrays for you.

I think that these would be quite useful, specially #1. If you search for "Hash" or "Dictionary" on the AutoIt Track system you'll see that there are a number of requests for a Dictionary object to Autoit. Having one on the standard library would take care of that.

My proposal would be for including the following (or a similar) function into a UDF called "Dictionary.au3":

expandcollapse popup

; #FUNCTION# ====================================================================================================================
; Name...........: _Dictionary
; Description ...: Creates and returns a dictionary object (using the Windows Scripting library).
; Syntax.........: _Dictionary($vKeys=Default, $vValues=Default, $sDelimiterList=Default)
; Parameters ....: $vKeys - An array of key values.
;                           It can also be a string, in which case the string will be automatically 
;                           split according to the "sDelimiterList" parameter.
;                  $vValues - An array of values corresponding to each of the keys in the vKey list.
;                             It can also be a string.
;                  $sDelimiterList - The characters that will be used to split the vKeys and vValues 
;                                    parameters when those are strings rather than arrays.
; Return values .: Success - Dictionary object
;                  Failure - -1, sets @error to 1
; Author ........: Angel Ezquerra <angel.ezquerra at gmail dot com>
; Modified.......: 
; Remarks .......:
; Related .......: 
; Link ..........;
; Example .......; Yes
; ===============================================================================================================================

Func _Dictionary($vKeys=Default, $vValues=Default, $sDelimiterList=",")
    Local $oDict = ObjCreate("Scripting.Dictionary")
    If @error Then
        SetError(1)
        Return 0
    EndIf
    If $vKeys <> Default Then
        Local $nFirstElement = 0
        If IsString($vKeys) Then
            $nFirstElement = 1
            $vKeys = StringSplit($vKeys, $sDelimiterList)
        EndIf
        
        If $vValues == Default Then
            Local $vTemp[UBound($vValues)-$nFirstElement]
            $vValues = $vTemp
        ElseIf IsString($vValues) Then
            $vValues = StringSplit($vValues, $sDelimiterList)
            If $nFirstElement == 0 Then
                Local $vTemp[UBound($vValues)-1]
                For $n = 0 To UBound($vTemp)
                    $vTemp[$n] = $vValues[$n+1]
                Next
            EndIf
        EndIf
        ReDim $vValues[UBound($vKeys)]
        For $n = $nFirstElement To UBound($vKeys)-1
            $oDict.Item($vKeys[$n]) = $vValues[$n]
        Next
    EndIf
    
    Return $oDict
EndFunc

[Melba23]

Angel,

Ther are 2 dictionary UDFs which already exist in AutoIt.

Hash by aGorilla (based on the scripting dictionary) and this one from Nuster (based on associative arrays).

I use the second one a lot.

M23

[Richard Robertson]

I'd suggest some changes such as

Local $oDict = ObjCreate("Scripting.Dictionary")
If @error Then Return SetError(1, @error, 0)

Also add a check to make sure that $vKeys/$vValues is an array before you use any subscript operators. You've got a check for Default and string, but I could pass a number or a COM object or any other weird thing.

[Angel]

Angel,

Ther are 2 dictionary UDFs which already exist in AutoIt.

Hash by aGorilla (based on the scripting dictionary) and this one from Nuster (based on associative arrays).

I use the second one a lot.

M23

Thank you M23! In fact that is _exactly_ why I believe that a Dictionary/Hash/AssociativeArray UDF should be added to the standard library. Rather than having people look for one of these implementations or implement their own, just give them one that is proven to work and hopefully as fast as it can get (according to Richard Robertson the one based in Scripting.Dictionary should be faster, but we could easily perform some benchmarking).

One could ask why should a Dictionary UDF be added to the standard library and I would argue that the fact that most (if not all) popular scripting languages have it (python, PERL, Javascript and LUA come to mind) indicates that it is not only useful but an expected feature on any scripting language.

Since it seems that there are already several good implementations it seems that we would only need to agree on whether it is a good idea to add it to the standard library or not.

[Melba23]

Angel,

The problem is the number of UDFs which would have to be added to satisy everybody. The download would become really bloated. And then there is the problem of maintaining these UDFs. At the moment the Devs do so, but if the number keeps increasing....

You do have the "corporate memory" of the longer-term members to help out when people ask for something which already exists - as has just happened.

M23

[Angel]

Angel,

The problem is the number of UDFs which would have to be added to satisy everybody. The download would become really bloated. And then there is the problem of maintaining these UDFs. At the moment the Devs do so, but if the number keeps increasing....

You do have the "corporate memory" of the longer-term members to help out when people ask for something which already exists - as has just happened.

M23

Obviously not everything can be in the standard library. But I would argue that Dictonaries are as basic a feature as it comes.

If you look at the current standard library there are many packages that seem much less generally useful than a Dictionary package would be. Granted, you can live without dictionaries, but it often means that you end up needlessly complicating your code (using arrays or other tricks instead).

I agree that bloat should be avoided, but that does not mean that nothing new should go into the standard library.

Is there a process that can be followed to propose adding some new package or function to the standard UDF library?

[Melba23]

Angel,

Bug Reports and Feature Requests - scroll down to the bottom of the page. Please read the instructions carefully.

Good luck.

M23

Edit: Typnig!

Edited February 24, 2010 by Melba23

[Angel]

Thank you. Will give this a try! :-)

Angel