Warnings (#Warn)...how to repair a code?

[Zvonko]

With some codes using e.g. Gdip or Acc functions #Warn produces warnings like this:

This local variable has the same name as a global variable.
This variable has not been assigned a value.

Although such codes may work fine, I would like to know how a code should be adapted to avoid such warnings.

Here is a example using Acc functions.

Code: Select all

#NoEnv
#Warn

f2::
MouseGetPos, X, Y, Win, Control
WinGetClass, WinClass, Ahk_id %win%
if (WinClass ~= "CabinetWClass")
{
	Value := getAccPointValue()
 
	for window in ComObjCreate("Shell.Application").Windows
	{
		if (window.HWND != Win)
			continue
		sfv := window.Document
		items := sfv.Folder.Items
		for item in items
		{
			name := item.Name
			if (name = Value)
			{
				sfv.SelectItem(item, true)
				break 2
			}
		}
	}
}
return
 
getAccPointValue()
{
	Acc := Acc_ObjectFromPoint(ChildId)
	Value := Acc.accValue(ChildId)
	return Value
}






Acc_Init()
{
	Static	h
	If Not	h
		h:=DllCall("LoadLibrary","Str","oleacc","Ptr")
}


Acc_ObjectFromPoint(ByRef _idChild_ = "", x = "", y = "")
{
	Acc_Init()
	If	DllCall("oleacc\AccessibleObjectFromPoint", "Int64", x==""||y==""?0*DllCall("GetCursorPos","Int64*",pt)+pt:x&0xFFFFFFFF|y<<32, "Ptr*", pacc, "Ptr", VarSetCapacity(varChild,8+2*A_PtrSize,0)*0+&varChild)=0
	Return	ComObjEnwrap(9,pacc,1), _idChild_:=NumGet(varChild,8,"UInt") 
}

[HotKeyIt]

Code: Select all

getAccPointValue()
{
	Acc := Acc_ObjectFromPoint(ChildId:=0)
	return Acc.accValue(ChildId)
}

[Zvonko]

No, that seems not to be enough:

This variable has not been assigned a value.
pt (a local variable)
--> 054:if DllCall(...
etc.

[HotKeyIt]

There is an error in your script, there should be no new line:

Code: Select all

Acc_ObjectFromPoint(ByRef _idChild_ = "", x = "", y = "")
{
	Acc_Init()
	If	DllCall("oleacc\AccessibleObjectFromPoint", "Int64", x==""||y==""?0*DllCall("GetCursorPos","Int64*",pt)+pt:x&0xFFFFFFFF|y<<32, "Ptr*", pacc, "Ptr", VarSetCapacity(varChild,8+2*A_PtrSize,0)*0+&varChild)=0
	Return	ComObjEnwrap(9,pacc,1), _idChild_:=NumGet(varChild,8,"UInt") 
}

[Zvonko]

No, there is no new line, this was only a copy&paste error in my posting, my original code is OK.

[HotKeyIt]

Simply initialize it "Int64*",pt:=0)

[lexikos]

Code: Select all

getAccPointValue()
{
	Acc := Acc_ObjectFromPoint(ChildId:=0)
	return Acc.accValue(ChildId)
}

You seem to be implying that the answer is to remove or rename any local variables that have the same name as globals. What if the script is to be used by other people, in other scripts not under your control? Are you going to require each user to avoid the names "Acc" and "ChildId"?

The manual gives a different answer.

LocalSameAsGlobal: Before the script starts to run, display a warning for each undeclared local variable which has the same name as a global variable. This is intended to prevent errors caused by forgetting to declare a global variable inside a function before attempting to access it. If the variable really was intended to be local, a declaration such as local x or static y can be used to suppress the warning.

You don't need to wait until you get a warning before declaring the variable. If you declare it, you won't get a warning even if you later add a global with that name. If you declare it local, its scope won't change even if you later add a global declaration with that name outside the function.

Code: Select all

getAccPointValue()
{
	local ChildId := 0, Acc := Acc_ObjectFromPoint(ChildId)
	return Acc.accValue(ChildId)
}

Code: Select all

global Acc  ; Adding this won't affect the function.

The unfortunate drawback of this approach in v1 is that you must declare every local variable, since the local declaration implicitly makes the function assume-global. If you make a typo or forget to declare a local, you don't get a warning; just a global variable.

[Zvonko]

Ok, HotKeyIt & lexikos, but unfortunatelly as a newbie I am unble to implement your information practically even in my simple and short demo script.

For
> This local variable has the same name as a global variable.
I understand now at least that I can avoid warnings simply by not using the same name ("value" in my example).

But for
> This variable has not been assigned a value.
I have three warnings (for h, pt and pacc) even in my short script.
A script with #Include Acc.ahk or Gdip.ahk could involve a lot of variables ("hidden" in functions and subfunctions of these libraries) leading to a lot of warnings...
How to deal with this?

[just me]

The unfortunate drawback of this approach in v1 is that you must declare every local variable, since the local declaration implicitly makes the function assume-global.

Seems to be another good reason for Local - force local mode.

[lexikos]

just me: It is perhaps a reason to allow local to revert the function to assume-local. It is not a reason for local to restrict dynamic variable references, making local inconsistent with global and static.

Zvonko: What's the problem? Just declare each variable before use. I don't know how it could be explained any simpler.

If you get a warning that "This variable has not been assigned a value", the answer is obviously to assign a value to the variable.

Personally, I would deal with it by disabling warnings when using third-party scripts, and enabling them only while testing my own.

[just me]

lexikos: Local on it's own would be a new option to allow this restriction, so there is no 'inconsistency'. And, using your wording: "If you don't want Local to restrict dynamic variable references, don't use it!"

[lexikos]

Local on it's own would be a new option to allow this restriction, so there is no 'inconsistency'.

Nonsense. If local affects how existing dynamic variables are resolved while global and static do not, they are inconsistent.

Anyway, I was not interested in debating the merits or demerits of your suggestion, hence not posting in your topic. My point was that your suggestion has an extra component that has no relevance to the problems discussed here.

[Zvonko]

Ok, I hope this discussion between just me and lexikos will lead to better AHK solutions for newbies (like me) which would just want to use libraries like Gdip or Acc as comfortably as possible...

Another question of an ignorant:
To avoid "not assigned" warnings in my simple demo script I would have to insert a line like this?
h := 0, pt := 0, pacc := 0
But then I have three new variables which produce "same name" warnings...

[lexikos]

Zvonko: You are creating new variables, not assigning to the variables which you were warned about. In this case, the variables are local to the function. To assign to those variables, you obviously must modify the function. I would not recommend that since they are in a third-party script, and that is why I mentioned that I would disable warnings.

[just me]

The unfortunate drawback of this approach in v1 is that you must declare every local variable, since the local declaration implicitly makes the function assume-global.

No relevance?

[Zvonko]

Ok, maybe I understand now.

To assign to those variables, you obviously must modify the function. I would not recommend that since they are in a third-party script, and that is why I mentioned that I would disable warnings.

So my lesson from this should be the following?
If #Warn shows "not assigned" and "same name" warnings referring to the use of functions from libraries like Gdip or Acc, these warnings can simply be ignored.

[lexikos]

@just me: I think you misread my post.

My point was that your suggestion has an extra component that has no relevance to the problems discussed here.

If local affects how existing dynamic variables are resolved while global and static do not, they are inconsistent.

If #Warn shows "not assigned" and "same name" warnings referring to the use of functions from libraries like Gdip or Acc, these warnings can simply be ignored.

All warnings can be ignored. They're warnings, not errors, and they're optional.