What people are objecting to is that your program is creating new variables at will. Your expression:

${"Window".$WindowCount} = new Win32::GUI::Window(...);

creates a variable named $Window0 when $WindowCount contains a value of 0. Conceptually, it seems like a nice way to do things. But as you gain experience, you find that there are just too many ways to make mistakes, and too many possibilities for unintended consequences. Code that uses this trick tends to be a maintenance headache

As an example, if $counter doesn't have a value, then you're trying to access the RegExp member of variable $Window, which either doesn't exist or doesn't contain a value. Or perhaps you used $counter for another purpose somewhere, and it contains "foo", in which case $Windowfoo similarly doesn't exist or contain a value.

When you compute your variable names, you can make mistakes which lead to rather surprising behavior in the event that your expression comes up with something annoying like "_", in which case you'd be mangling the $_ variable.

So people are suggesting that you put your variables in a hash to limit the possible interactions with other variables. People often use a hash to do this, because you can use your computed name as a hash key, like so:

$Windows{"Window".$counter} = new Win32::GUI::Window(...);

However, since your counter is simply a number, BrowserUK is suggesting that you use an array instead of a hash. After all, a hash that uses integers as a key is pretty darned similar to an array in useability:

$Windows[$counter] = new Win32::GUI::Window(...);

But an array has better performance¹ and is pretty easy for new(er) programmers to use/understand. (Hashes are beautiful, but have a couple of behaviors² that newer programmers often find surprising.)

...roboticus

Notes:

¹ I think...I've never bothered to profile it, so I could easily be wrong. In any event, it would depend on how (and how frequently) you access it, too.

² Specifically, (1) when you iterate through the keys of a hash, the order they keys are traversed is arbitrary, having no relation to the order in which you put the keys in the hash; (2) you can't sort a hash--you can access the keys in sorted order, but you have to create a new sorted list of keys to do it--you can't actually change the order of the items in the hash itself. There may be a couple of others, but they don't come to mind at the moment.