Nutster

I am willing to admit I was concerned.

There appears to be a module in Windows 10 Powershell called AutoItX that includes Assert-AU3IsAdmin. It returns 1 if run as administrator and 0 if not. At least on my machine. YMMV.

When I check the list of commands in the Powershell included with Windows 10, I found Assert-AU3IsAdmin, from the module AutoItX. Is anybody else getting this, or did Powershell include AutoItX as one of its modules automatically for everybody? Did you know about this, Jon? To reproduce, start PowerShell and enter "Help Admin". I got Assert-AU3IsAdmin which returns 1 if run as admin and 0 if not. The AU3 in the middle got my attention and I thought to check here. "Help AU3" gave me a huge list of entries. Any ideas?

I tend to use complete sentences in my comments, including the appropriate punctuation. So, periods show up at the end. ; Now for something completely different. ; Even though the last line (and this one too) are not complete sentences.

Until needs a complete condition after the keyword. "Not" can be part of a condition, but it is not complete on its own. "Not" reverses the truth value of what follows it (True becomes False or False becomes True).

Well, I have found and fixed the problem in the AssocArrayDelete function, but have uncovered some other bugs. Also, I am adding AssocArrayDisplay(), which returns a string with all the assigned key-value pairs in the sequence in the array and AssocArraySorted(), which returns a string with all the assigned key-value pairs, in order by the key. I am adding a couple of support routines to help with AssocArraySorted, like other support routines, they are not meant to be called directly.

It sounds like I have a bug in the delete code. This could happen if a hash collision is being handled incorrectly during deletion. For example: Local $HashSet(1) AssocArrayCreate($HashSet, 6) ; The overhead is not worth it for such a small list. ; This is for illistrative purposes only. They may or may not map this way. AssocArrayAssign($HashSet, "M", 1) ; Hash index 2 AssocArrayAssign($HashSet, "D", 2) ; Hash index 3 AssocArrayAssign($HashSet, "Y", 3) ; Hash index 2. This collides and gets moved down to 4, the next available location. AssocArrayAssign($HashSet, "T", 4) ; Hash index 1. ; At this point the array looks like: ; Index Key Value ; 0 ; 1 T 4 ; 2 M 1 ; 3 D 2 ; 4 Y 3 ; Now to delete an entry. AssocArrayDelete($HashSet, "M") ; Now the array looks like: ; Index Key Value ; 0 ; 1 T 4 - Hash Index 1. Good. ; 2 ; 3 D 2 - Hash Index 3. Good. ; 4 Y 3 - Hash Index 2. Good luck finding it here! Before the deletion, the hash search function could look for "Y" and start looking at the calculated hash index of 2. That has "M", which is not what it is looking for, so it checks the next elements until it finds either 1) the element it is looking for or 2) an empty element, in which case it says it is not found. When the hash search function looks for "Y" after "M" has been deleted, it will look at 2; finding that empty, it will say "Y" is not in the hash table, even though it is still there, just in the wrong place. "Y" should have been moved up during the deletion process. When the elements are removed in the reversed order that they were added, you remove the "Y" first, before "M", so the hash collision is removed before this becomes an issue. Well that is my analysis anyway; I could be wrong and something else altogether is happening. If we are patient, the original author could come back and fix the bug in the delete code. Oh, wait, that's me. I guess I should look at this. Thanks for the testing set that I can use to verify when I fix this.

I think you are confusing the ideas of MsgBox with your GUI window. They are separate things. When you click any button on the MsgBox (or the timeout expires), the MsgBox automatically closes and returns a value indicating why it closed (which button was pushed, etc.); the MsgBox does not stick around after that, no matter which button you pushed. The GUI that you created can still stick around after the MsgBox disappears, but that is a different story. As an experiment, build a simple script with just a message box with Yes, No, Cancel as the buttons. Put the value returned from the MsgBox into a variable. Present that value from a Ok only message box just after that. Dim $nRetVal $nRetVal = MsgBox(3+32, "MsgBox Test", "Please press a button.") MsgBox(64, "MsgBox Test", "The returned number from the last MsgBox was " & $nRetVal & ".") I like to close the GUI window before exiting with GuiDelete, but that appears to be just me.

It is pretty easy to determine that his name is Jason, which in my experience is usually male.

This looks like a rounding problem. Mod is an integer function, but the numbers you gave are too big for integer (limited to just over 2 billion / 2 thousand-million). The fail-over is use floating-point numbers, but the storage for floating-point is limited and the least significant digits can be lost or scrambled during operations and storage, sort of like rounding off the decimals on a regular number. Imagine that you are performing some calculations but you can only store 2 digits after the decimal point. This is an example of limited storage that I was talking about earlier. Determine 500 / 17 * 17 = ? 500 / 17 = 29.41176470588235294118... Rounding to the nearest 2 digits yields 29.41. 29.41 * 17 = 499.97 So under these circumstances, 500 / 17 * 17 = 499.97, due to rounding error. The effect gets more noticeable with larger denominators and you are using a pretty big denominator. The reason the second method, using int and subtraction, worked is that the Int function reset that precision back to 0 as it were. Much easier to work with. One way to mitigate rounding errors is to see if you can simplify things before asking the computer to perform the calculations. The calculations can be faster and more accurate that way.

There are other ways to do this, without catching a few false positives, like "10.10.42.22". One way is to use sscanf. Keep in mind that bool and cout are part of C++, not C. #include <stdio.h> int IsNumber(const char *text) { double result; char c = '\0'; /* returns true (1) if there is only one value read (the float). */ /* returns false (0) if nothing valid was read or if a character followed the floating point value. */ if (sscanf(text, "%lf%c", &result, &c)==1) { return 1; } else if (c == '\0') { /* if c has only a null character, then the string did actually end in the correct spot. */ return 1; } else { return 0; } }Another way is to create an interpreter function to read the input string and rejects if the string is not ended by the time the number is finished. I have not included the parts that actually determine the value, just valid syntax. #include <assert.h> #include <ctype.h> int IsNumber(const char *text) { char *ptr=text; /* a pointer to keep track of where in the string we are looking */ /* check for a sign */ if (*ptr == '-' || *ptr == '+') { ++ptr; } /* Read the part in front (whole number) portion of the string; while (isdigit(*ptr)) { ++ptr; } if (*ptr == '.') { /* found the decimal point. Move on to the next part */ ++ptr; } /* other characters will actually get trapped later. */ /* read the decimal (fractional) portion */ while (isdigit(*ptr)) { ++ptr; } /* String should end, or may be followed by exponent portion, the E-42 part. */ if (*ptr == '\0') { /* end of string. Valid exit point. */ return 1; } else if (toupper(*ptr) != 'E') { /* nothing else is valid. Return false. */ return 0; } /* Exponent portion */ assert(*ptr == 'e' || *ptr == 'E'); ++ptr; if (*ptr == '-' || *ptr == '+') { ++ptr; } while (isdigit(*ptr)) { ++ptr; } /* This has to be the end of the string. */ if (*ptr == '\0') { /* end of string. Valid exit point. */ return 1; } else { return 0; } }

Just thinking of what would not need to be have a major rewrite to work under Linux. Some of the variable internals are specific to Windows operations and would need to be rewritten. There are a bunch of math functions (abs, sin, cos, tan, random, etc.) and string functions (StringIsAscii, StringMid, StringLower, etc.) that should run without too much work. Everything in Environment, Graphics and Sound, GUI Management, Keyboard, Message Boxes, Mouse, Network, COM, Process, Registry, Timer, Tray, Window Management would need a total rewrite. A good chunk of the rest of the function sections either need minor changes to everything or major changes to a few or somewhere in between. Even using Wine is not going to help.

Perl, Ruby, Python are all languages / systems that originated in Linux/Unix and are used in ways that AutoIt it is in Windows. There is also Expect that is specifically designed for Linux automation tasks. I've got to learn that one. At the level AutoIt runs at, Wine (or winelib) does not provide a full enough environment for AutoIt to run effectively on Linux. We just go too deep under the covers. It could run on a Windows virtual machine on a Linux box, as that is a complete environment, but then the AutoIt (and Windows) stuff does not interact with the Linux OS in any meaningful way. I think Valik put "Porting to Linux" in the "Not going to happen" list for a reason.

Actually, I was developing a database-interactive website at the time, so I was between Javascript and Perl. I will check out your work-around.

You could try (untested) Func UnsignedBitShift(const $value, const $bitshift) Dim $retval If $bitshift > 0 Then $retval = $value << $bitshift ElseIf $bitshift < 0 Then $retval = BitAnd($value, 0x7fffffff) >> (-$bitshift) ; Strip the sign bit and then bit-shift. If $value < 0 Then $retval = BitOR($retval, 1 << (31-$bitshift)) ; Introduce the removed sign bit Else ; $bitshift = 0 $retval = $value EndIf Return $retval EndFunc Msgbox(0, "Bitshift test", UnsignedBitShift(0xffffffff, -16))