Leaderboard

Spoilsport ...

How achievable is a Collection.au3 include that is used by both Map.au3 and Array.au3 Manadar?

czardas, you got it. If you relax and look twice it makes full sense: a value wich is "not present" is hardly comparable (with <, <=, =, ==, <>, >=, >) to another value which is also "not present".

This seems to be more realistic (image look): Case 8 ; Windows reserves first color for white, $tBITMAPINFO.RGBQuad((0)) = 0xFFFFFF ; and last color as black! $tBITMAPINFO.RGBQuad((0xFF)) = 0x000000 Local $iColor = 20, $iRed, $iGreen, $iBlue For $iRed = 0 To 255 Step 51 For $iGreen = 0 To 255 Step 51 For $iBlue = 0 To 255 Step 51 $tBITMAPINFO.RGBQuad(($iColor)) = BitShift($iRed, -16) + BitShift($iGreen, -8) + $iBlue $iColor += 1 Next Next Next Br, UEZ

This is because 0 = "String" returns True (line 48 in _Array_Search) $sStr = "BigString" $iNull = 0 If $iNull = $sStr Then ConsoleWrite("! " & $iNull & " = " & $sStr & @CRLF) Else ConsoleWrite("+ " & $iNull & " <> " & $sStr & @CRLF) EndIf If $iNull == $sStr Then ConsoleWrite("! " & $iNull & " == " & $sStr & @CRLF) Else ConsoleWrite("+ " & $iNull & " <> " & $sStr & @CRLF) EndIf

Manadar, In _MapToString() you are checking if a key is a map or an array, though they can only be integers or strings. Also the function wasn't returning anything as you were only updating the $sOutput variable if it was a map or an array. Also _MapSearch() isn't using the $iCompare variable. Local $mMap[] For $i = 0 To 19 $mMap[$i] = $i Next ConsoleWrite(_MapToString($mMap) & @CRLF) Func _MapToString(Const ByRef $mMap, $sDelim_Item = "|", $sDelim_Row = @CRLF) If $sDelim_Item = Default Then $sDelim_Item = "|" If $sDelim_Row = Default Then $sDelim_Row = @CRLF If Not IsMap($mMap) Then Return SetError(1, 0, -1) Local $sRet = "", _ $vValue = 0 For $vKey In MapKeys($mMap) $vValue = $mMap[$vKey] $sRet &= $vKey & $sDelim_Item __MapToString_Print($sRet, $vValue) $sRet &= $sDelim_Row Next $sRet = StringTrimRight($sRet, StringLen($sDelim_Row)) ; Strip the last delimiter. Return $sRet EndFunc ;==>_MapToString Func __MapToString_Print(ByRef $sOutput, ByRef $vValue) Switch VarGetType($vValue) Case "Array" $sOutput &= "{Array}" Case "Map" $sOutput &= "{Map}" Case Else $sOutput &= $vValue EndSwitch EndFunc ;==>__MapToString_Print

Departing from the widely used (in and far outside the AutoIt world) convention that False converts to 0 and True converts to "not 0" (and often 1) would be uselessly problematic for both existing code base and newcomers. OTOH a solid design choice could have been to use the three-value logic (3VL) in use in SQL. Since Null can translate into "no data present" (but that statement doesn't hold in all 32VLs) it shouldn't make sense to accept conversion to any real-world value in any case. Other 3VLs exist but are much less in use in programming. Of course the added bonus is that Null behavior would have been 100% consistent with every SQL engine and there is a number of users for which this can be important in practice. An important consequence of this choice is that Null <> Null and If $n = Null is Null if $n is Null but this is alleviated in SQL with IsNull and IsNotNull. The case of Default is different. Its current forced conversion to numeric using Int() or Number() are inconsistent (give 0) with its behavior in implicit conversions (giving -1). The best would have been to make Default a similar keyword to Null and never accept to convert it to any value in any context. Again IsDefault and IsNotDefault would then be useful instead of the infamous return value of IsKeyword. Unfortunately these conventions would break the fundamental paradigm in AutoIt that its variants auto-convert depending on context. On the other side we would no more see things like: Func _myFunc($arg = $MY_LOVELY_CONSTANT) If IsKeyword($arg) = 1 Or $arg = -1 Or $arg = "" Then $arg = $MY_LOVELY_CONSTANT ...

Oh wow, derp. Good catch Jon. I didn't even bother reading the posted code because I assumed MouseClick was used.

What need would you have to write into the System Reserved partition??

Train.

The Forum Rules specifically mention that "keyloggers" are a prohibited subject on this forum. Of late we have had several threads locked because they have strayed (usually unwittingly) into keylogger territory. Here is a reminder of what Jon (the site owner) has set out as the basis for acceptability: "how to check for a few keys being pressed is one thing" We are not going to define "a few" in absolute terms, but if you post any code which checks for the best part of the keyboard you can be absolutely sure that you are in breach of the rules, that your thread will be locked, and that sanctions may follow. So please do not post such scripts - we do not want to be heavy-handed, but after this announcement your excuses had better be very good ones! M23