Control under cursor

[rdwray]

What is the EXACT error message that you get when it crashes, what you posted previously was only a tiny part of it. Without the full error message it's going to be very hard to trouble shoot what's happening. Also, make sure you haven't changed the code around the error message area too much from what's posted, if you have changed it, please repost the script with the changes so that we're all working from the same base. Thanks.

This is everything that SciTE is giving me:

>"C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.exe" /run /prod /ErrorStdOut /in "F:\Backup\AutoIt\Projects\DB\DB_csv.au3" /autoit3dir "C:\Program Files (x86)\AutoIt3" /UserParams    
+>07:34:00 Starting AutoIt3Wrapper v.2.0.1.24    Environment(Language:0409  Keyboard:00000409  OS:WIN_7/Service Pack 1  CPU:X64 OS:X64)
>Running AU3Check (1.54.19.0)  from:C:\Program Files (x86)\AutoIt3
+>07:34:00 AU3Check ended.rc:0
>Running:(3.3.6.1):C:\Program Files (x86)\AutoIt3\autoit3.exe "F:\Backup\AutoIt\Projects\DB\DB_csv.au3"    
F:\Backup\AutoIt\Projects\DB\DB_csv.au3 (34) : ==> Subscript used with non-Array variable.:
If $ctrl[4] > 0 Then
If $ctrl^ ERROR
->07:34:03 AutoIT3.exe ended.rc:1
>Exit code: 1    Time: 4.258

When I do the test, I put the script back exactly the same as before. If there is some other error information that you want, tell me how to retrieve it.

[BrewManNH]

Taking your script from post #11 above, and adding the code I suggested, I don't get the crash any longer. Here's what I came up with.

#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>
#include <EditConstants.au3>
#include <GUIScrollBars.au3>
#include <ScrollBarConstants.au3>
#include <Misc.au3>
Global $hGuiWin
Global $pressed, $ctrl, $dll = DllOpen("user32.dll")
Main()

Func Main()

    $hGuiWin = GUICreate("Contacts DB", 900, 750)
    GUISetBkColor(0x000000, $hGuiWin)

    GUISetState(@SW_SHOW)
    While 1
        If _IsPressed(01, $dll) And $pressed = 0 Then
            $pressed = 1
        ElseIf Not _IsPressed(01, $dll) Then
            $ctrl = GUIGetCursorInfo()
            $pressed = 0
        EndIf
        If IsArray($ctrl) Then ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Check if $ctrl is an array
            ToolTip($ctrl[4]) ; if it is, show tooltip
        Else ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< if it's not an array
            ToolTip("") ; <<<<<<<<<<<<<<<<<<<<<<<<<<< clear the tooltip's text
        EndIf
        ;       ToolTip("tooltip") ; DOES NOT CAUSE CRASH.
        Switch GUIGetMsg(0)
            Case $GUI_EVENT_CLOSE
                Exit
        EndSwitch
    WEnd
EndFunc   ;==>Main

[rdwray]

Taking your script from post #11 above, and adding the code I suggested, I don't get the crash any longer. Here's what I came up with.

Your code works stand alone, but I integrated it with the program and it crashed. I am going to do some further looking and get back with you later - not making sense.

Another question, I set the variable as $ctrl[5] which should keep its' array setting, but it doesn't, why? And why does Help say to use a non-array variable when calling GUIGetCursorInfo()

Local $a

$a = GUIGetCursorInfo()

[BrewManNH]

Declaring the variable as an array is not going to keep it an array if the GUIGetCursorInfo comes back with a string, it's going to be reallocated as a string variable. AutoIT allows the copying of an array to a new array just by doing this $newArray = $oldArray, after doing this $newArray contains the same elements as $oldArray, and if $oldArray was a string variable, $newArray now becomes a string variable too.

There isn't anywhere in the help file description for GUIGetCursorInfo that says it needs to have the variable declared as nonarray, I have tried it both ways and it works no matter what.

[rdwray]

Declaring the variable as an array is not going to keep it an array if the GUIGetCursorInfo comes back with a string, it's going to be reallocated as a string variable. AutoIT allows the copying of an array to a new array just by doing this $newArray = $oldArray, after doing this $newArray contains the same elements as $oldArray, and if $oldArray was a string variable, $newArray now becomes a string variable too.

There isn't anywhere in the help file description for GUIGetCursorInfo that says it needs to have the variable declared as nonarray, I have tried it both ways and it works no matter what.

Not good, an array should maintain its' size in any circumstance. This means that a variable can take on any definition at any time. I don't think this in the help file either.

[BrewManNH]

In AutoIT there's no way to keep an array an array if you're doing bad coding or using a function that you're not sure how it works and assigning it to a variable. It's up to the programmer to keep track of what his/her code is doing to the variables at all times. If you're not making sure that the variable you declared as a Global isn't redeclared as a Local inside your function, and you're expecting it to contain the value from the Global (as an example of bad coding), then you're at fault for not paying attention.

Once you understand how variables and arrays work in the programming language you're coding in then you will be better able to avoid mistakes like that in the future. After all, in some languages, variable names are case sensitive, and you can reuse a variable name if you change its case without affecting the other variable. It's not poor design in the programming language that it works that way, it's just how it works in that language.

[rdwray]

In AutoIT there's no way to keep an array an array if you're doing bad coding or using a function that you're not sure how it works and assigning it to a variable. It's up to the programmer to keep track of what his/her code is doing to the variables at all times. If you're not making sure that the variable you declared as a Global isn't redeclared as a Local inside your function, and you're expecting it to contain the value from the Global (as an example of bad coding), then you're at fault for not paying attention.

Once you understand how variables and arrays work in the programming language you're coding in then you will be better able to avoid mistakes like that in the future. After all, in some languages, variable names are case sensitive, and you can reuse a variable name if you change its case without affecting the other variable. It's not poor design in the programming language that it works that way, it's just how it works in that language.

They are called languages because that is what they are, no two are alike. No other language I know of destroys an array after it is declared and I have used many.

I only declared the variable (array) once. Once a variable is declared Global, then it should not be able to be redeclared. If a variable is declared Local, then it can be reused in other functions as Local. As flexible as VBA is, it will not allow you to change a variable type once it has been declared. I normally use Global to keep variables from overlapping and it looks like AutoIt tracks Local first ignoring Global if they both exist. The issue is that these little things can cause several hours of lost effort, that is why I appreciate this forum for the information that it conveys.

Help file says: "When using variables, the local scope is checked first and then the global scope second."

Also from Help: "If you declare a variable with the same name as a parameter, using Local inside a user function, an error will occur. Global can be used to assign to global variables inside a function, but if a local variable (or parameter) has the same name as a global variable, the local variable will be the only one used. It is recommended that local and global variables have distinct names."

The answer to what happened here is also in Help: "To erase an array (maybe because it is a large global array and you want to free the memory), simply assign a single value to it:

$array = 0

This will free the array and convert it back to the single value of 0."

[SmOke_N]

You're assuming that it remains an array always.

As you noted yourself, you can clean the array by $a_arg = 0, however, if for some reason, your function does not return an array ( Check for Return Values for both success and failure always ), then your var will then hold whatever the return value of the function is upon failure.

This simply requires error/sanity checking on your part, or to properly check if your var is still an array with something like: If IsArray($a_arg) Then.

[rdwray]

You're assuming that it remains an array always.

As you noted yourself, you can clean the array by $a_arg = 0, however, if for some reason, your function does not return an array ( Check for Return Values for both success and failure always ), then your var will then hold whatever the return value of the function is upon failure.

This simply requires error/sanity checking on your part, or to properly check if your var is still an array with something like: If IsArray($a_arg) Then.

In a nut shell, if an array is declared, then it should be an array, not a string. The array was destroyed by the internal working of AutoIt, not my failure to code it correctly. AutoIt forces error checking because it does not do it.

[Jos]

In a nut shell, if an array is declared, then it should be an array, not a string. The array was destroyed by the internal working of AutoIt, not my failure to code it correctly. AutoIt forces error checking because it does not do it.

mmm ... am I detecting attitude issues here?

An Variable declared as Array can be easily changed into an string or something else when that is the returned result of a Function.

Not important whether you like that or not... it's the way it is.

Jos

Edited June 7, 2011 by Jos

[BrewManNH]

In a nut shell, if an array is declared, then it should be an array, not a string. The array was destroyed by the internal working of AutoIt, not my failure to code it correctly. AutoIt forces error checking because it does not do it.

In other languages that may be true, but not in AutoIT. If you can't deal with the fact that the rules have changed when you stopped playing cricket and started playing baseball, then you shouldn't be playing baseball.

Your failure wasn't in coding it correctly, your failure was in understanding how the functions you use work. If you don't know how to use the functions, and in Autoit the help file is extremely well written, then you need to learn to read the help file before using that function. GUIGetCursorInfo states quite clearly that if it's not over a user created Autoit GUI then it will return 0. If you run the example script for the function, move the mouse off the window, click anywhere else, and hit ESC the exact same error happens.

Error checking should be up to the programmer to implement.

[SmOke_N]

In a nut shell, if an array is declared, then it should be an array, not a string. The array was destroyed by the internal working of AutoIt, not my failure to code it correctly. AutoIt forces error checking because it does not do it.

A shame more languages don't force error checking. But, regardless, I do it in every language.

To me, that's just a part of programming properly ( my sole opinion ).

I agree with what you said about languages that force you to declare types for your vars. But, AutoIt is loosely typed, and should be handled accordingly.

And knowing that, you are well on your way to achieving results you set out to I'm sure.

Just some food for thought.

[rdwray]

In other languages that may be true, but not in AutoIT. If you can't deal with the fact that the rules have changed when you stopped playing cricket and started playing baseball, then you shouldn't be playing baseball.

Your failure wasn't in coding it correctly, your failure was in understanding how the functions you use work. If you don't know how to use the functions, and in Autoit the help file is extremely well written, then you need to learn to read the help file before using that function. GUIGetCursorInfo states quite clearly that if it's not over a user created Autoit GUI then it will return 0. If you run the example script for the function, move the mouse off the window, click anywhere else, and hit ESC the exact same error happens.

Error checking should be up to the programmer to implement.

So you are stating to me the GUI I created using GUICreate is not an AutoIt GUI?

[rdwray]

So you are stating to me the GUI I created using GUICreate is not an AutoIt GUI?

BTW: The help file I have does not say anything about an AutoIt GUI or a user GUI and this may well be the problem, my help file is out of date.

Help file info:

v3.3.6.1

©1999-2010 Jonathan Bennett & AutoIt Team

AutoIt v3 Homepage

[SmOke_N]

BTW: The help file I have does not say anything about an AutoIt GUI or a user GUI and this may well be the problem, my help file is out of date.

Help file info:

v3.3.6.1

©1999-2010 Jonathan Bennett & AutoIt Team

AutoIt v3 Homepage

This is true. One rule of thumb.

The standard GUI functions in AutoIt are for AutoIt GUI's.

Generally speaking, the UDF GUI functions in AutoIt can be used for both AutoIt GUI's and Standard Window Control GUI's.

If you do not know the difference's in Standard AutoIt GUI functions and UDF/Non-Standard, the Non-Standard have an underscore before their function names.

[BrewManNH]

So you are stating to me the GUI I created using GUICreate is not an AutoIt GUI?

I didn't say that, you misread what I wrote. If you move the mouse cursor away from your window, then the return from guigetcursorinfo is going to be a string and not an array. You yourself found out that if you use the window's handle then the script won't crash, because as it states in the help file, If the "winhandle" parameter is used then the specified window becomes the new "current" window., so you know that you made a mistake in coding your function but you want to complain about how variables are handled.

[BrewManNH]

BTW: The help file I have does not say anything about an AutoIt GUI or a user GUI and this may well be the problem, my help file is out of date.

Yes it does, The mouse cursor position is successful only on an window created by a GUICreate.

Help file info:

v3.3.6.1

©1999-2010 Jonathan Bennett & AutoIt Team

AutoIt v3 Homepage

That is the current release version of the help file.

[rdwray]

This is true. One rule of thumb.

The standard GUI functions in AutoIt are for AutoIt GUI's.

Generally speaking, the UDF GUI functions in AutoIt can be used for both AutoIt GUI's and Standard Window Control GUI's.

If you do not know the difference's in Standard AutoIt GUI functions and UDF/Non-Standard, the Non-Standard have an underscore before their function names.

What I was getting at is that Mass Spammer said this:

GUIGetCursorInfo states quite clearly that if it's not over a user created Autoit GUI then it will return 0

and this is not in the help file that I have. I understand the UDF, but I am a little confused about the AutoIt GUI and whatever other GUI I have the option to create. I thing other than GUICreate it would be using Windows API to create the window - missing the point on this one.

[BrewManNH]

What I was getting at is that Mass Spammer said this:and this is not in the help file that I have.

It's in the line where the return value is specified

Failure: 0 and set @error to 1

[rdwray]

It's in the line where the return value is specified

A lot of the functions say that, but that doesn't inform me that it was because of the GUI type. Help me out here...

I use GUICreate, so this should not come into play:

The mouse cursor position is successful only on an window created by a GUICreate.