Leaderboard

Simply put, second number is too big. On a 64 bit system, the highest 64-bit signed integer you can store is 263 − 1 which equals to 9,223,372,036,854,775,807. So a small comparison: 9,223,372,036,854,775,807 31,373,534,333,631,303,739 Your number is 3.5 times larger. Trying to store that big of a number would usually cause buffer overflow in some programming languages, but AutoIt caps it at its maximum value, which is 263 − 1 = 9,223,372,036,854,775,807. So that's why you're getting that specific number instead of 31,373,534,333,631,303,739. Consider storing it as a string if you don't have to do math operations with it. Otherwise read about handling big numbers.

https://www.autoitscript.com/trac/autoit/ticket/581

@TungNhoc, isn't $eFrame itself the ID of iframe element? Maybe you can do away with the 3rd and 4th lines of your code. $eFrame = _WD_FindElement($sSession, $_WD_LOCATOR_ByXPath, "//iframe[@name='QC Test Máy']") ConsoleWrite(@CRLF & "Finding Frame ID (" & $eFrame & ")" & @CRLF & @CRLF) $sFrame = _WD_FrameEnter($sSession, $eFrame) ConsoleWrite(@CRLF & "Enter Frame result (" & $sFrame & ")" & @CRLF & @CRLF) By the way, _WD_FrameEnter returns a boolean value.

pixelsearch, The problem arises when the ListView is completely emptied and then a new item is added - the internal array which the UDF uses to do its magic does not get correctly resized. I can see the problem but finding the solution is going to take a while - please be patient. M23

Correct, Ternary type statements were introduced much later and all we (i) have done in au3check is to tolerate the ternary statements, so trying to avoid wrong warnings/errors, but never tried to implement checking the validity as they aren't as easy as some of us think they are. I have said it already many times before, but my brains aren't build to think in the way YACC & FLEX work, so I am trying to stay out of that code when there is no real problem. Jos

and the trap closed on the reckless ...

@Bowmore You're right, the issue isn't precisely that. There are still actual minor issues with ?: in Au3Check if I recall correctly albeit I don't remember which use case right now. Here it's rather the use of a pointless ternary assignment that's causing the warning. I believe the OP's original code is more involved but boils down to the example posted. Also the code can be logically simplified: #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 Func _test() Local $rc = 1 ? Beep() : "" #forceref $rc EndFunc ;==>_test _test()

Using global pollutes the variable space IMHO. The less globals, the less problems. And yes this is a minor Au3Check issue with the ternary op.

Would assigning space, zero or NULL help to DE-assign the variable?

Seems like an issue with assignments using the ternary operator.

.. but you were the one stating it should be 'trivial"...no?

It actually tells you what the issue is, the variable is declared but not used, if you use it you won't have an issue. Your last example you didn't declare the variable or use it within the function. #AutoIt3Wrapper_Au3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 Func _test() Local $rc = 1 ? Beep() : "" ConsoleWrite($rc & @CRLF) EndFunc ;==>_test _test()