question about window groups

[autocart]

if it is still true, we cannot "reset/delete" a group. (workaround: https://autohotkey.com/board/topic/7169 ... ntry455084)

Now my question:
When does a group get "destroyed" automatically?
e.g.: at the end of a hotkey?
or do I have to end the whole script?
or do I have to reboot windows?

Thx.

[boiler]

When you exit the script, the group definition no longer exists. So if you run your script again, it will build it from scratch, which can be different if you are building it dynamically.

[autocart]

ok. thx.

[autocart]

Maybe a dumb question, but that means that in script_2 I can use the same group name(s) as in script_1 (with possibly different definitions) and run both scripts parallel without interferences, correct?
(The scope of the group definitions is limited to the individual script context, right?)

But I cannot do that with two different hotkeys which are defined in one ahk script, right?

[autocart]

another question:
Is it possible to read out what window definitions are already defined inside an existing window group?

[autocart]

conclusion about ahk window groups:

DOES NOT WORK RELIABLY, especially not with MS Excel windows.

Here is the code which I am testing with:

Code: Select all

; --------- Example ---------------------
GroupAdd(MyGroup, "Untitled")       ; You have to use expression syntax in functions
WinWaitActive ahk_group %MyGroup%   ; and ahk_group %MyGroup% in Win-commands
WinMinimize % "ahk_group" MyGroup   ; or "ahk_group" MyGroup in expression mode
MyGroup =                           ; "Deletes" the group
; ---------------------------------------
; https://autohotkey.com/board/topic/71695-is-there-any-way-to-destroy-delete-a-window-group/#entry455084
GroupAdd(ByRef GroupName,p1="",p2="",p3="",p4="",p5=""){
  static g:= 1
  If (GroupName = "")
     GroupName:= "AutoName" g++
  GroupAdd %GroupName%, %p1%, %p2%, %p3%, %p4%, %p5%
}
; ---------------------------------------
global $AHK_WINDOW_GROUP

#g::
MsgBox, 1, , This creates a new current ahk window group starting with the currently active window.`n(More windows can be added with the shortcut win+a.)
IfMsgBox, Cancel, return
$AHK_WINDOW_GROUP =
$winID := WinActive("A")
GroupAdd($AHK_WINDOW_GROUP, "ahk_id " . $winID)
return

#a::
$winID := WinActive("A")
GroupAdd($AHK_WINDOW_GROUP, "ahk_id " . $winID)
return

^<::
if $AHK_WINDOW_GROUP
{
	GroupActivate, %$AHK_WINDOW_GROUP%
}
return

An Excel window can be added but most of the time its not activated. Once in a long while it does get included in the activation sequence but it is not reliable.

[boiler]

Maybe a dumb question, but that means that in script_2 I can use the same group name(s) as in script_1 (with possibly different definitions) and run both scripts parallel without interferences, correct?
(The scope of the group definitions is limited to the individual script context, right?)

Yes. Different scripts are totally independent, and group names and variable names in one script are in no way affected by the other script, even if they are named the same.

But I cannot do that with two different hotkeys which are defined in one ahk script, right?

If by this you are asking whether the groups of code that would be executed by two different hotkeys in the same script are similarly independent, the answer is no.

[boiler]

Be careful about concluding that a command is not reliable when your evidence is that your script and how you use it has not been reliable. The issue could be something else, such as the window not being active yet when the GroupAdd command is executed after your MsgBox is closed.

[autocart]

Thx for ur readiness to keep answering, boiler!
Regarding your reply about "reliability", in general you are right, but in the case of my code, no. You did not look closely enough at the code and my comments in the post. MsgBox has nothing to do with it, becuse the Excel Window that gets skipped *most* of the time does not get skipped *all* the time (without changing the group, meaning, it *is* contained int the group), so, I assume it has something to do with the peculiarities of the Excel window, which in turn would mean that the GroupActivate command does not take into account all of the ways how windows might work in Windows, which is another way of saying that the command is not reliable.

[boiler]

I did read your comments closely. And again I'll say that your code does not isolate the reliability of the GroupAdd command such that you can confidently conclude it is unreliable. It could be that the Excel window takes longer to activate than other windows. There is a reason that there is a WinWaitActive command, and that is because it actually takes some time for a window to become active. Some windows may take longer than others. Your script assumes it is active immediately upon your MsgBox closing.

You have not proven that the Excel window is the one your are trying to add to the group. There are many ways to do that, and adding the active window, especially when your script takes focus from the active window right before it adds it, is not proof.

It may well be that your conclusion about Excel windows is true, but you need the script to positively identify that the window about to be added is the Excel window, then add that verified window and check the result.

[autocart]

One of us is reading the others comments wrong then. The msgbox has nothing to do with it. the problem occurs when the excel window has already successfully become part of the group. as I wrote, it does get activated occasionally (I would think < than 10 % of the time). So, it is part of the group and gets activated but not always. I'd call that unreliable. But I am repeating myself. Either way, I am done with the group thingy. Thx for trying to help.

[boiler]

I did help. You are refusing to listen. The MsgBox does matter because you are making another window (the MsgBox) the active window briefly, and you are adding the active window to the group before you know it has had time to become active again. And it may take longer for Excel windows to become active. I'm not saying it's definitely what is happening, but I am saying your script is not proof of the unreliability of the GroupAdd command.

This script activates the Excel window every time on my system, and it uses the GroupAdd command to do it:

Code: Select all

SetTimer, MonitorWindow, 100
return

MonitorWindow:
	MouseGetPos,,, WinID
	WinGetTitle, WinTitle, ahk_id %WinID%
	ToolTip, % "Press Home key to activate window titled:`n" WinTitle
	Sleep, 50
return

Home::
	SetTimer, MonitorWindow, Off
	GroupAdd, MyGroup, ahk_id %WinID%,, GroupError
	WinActivate, ahk_group MyGroup
	ToolTip, Window has been activated
	Sleep, 3000
	ExitApp
return

GroupError:
	MsgBox, Unable to add window to group.
return

[fischgeek]

The MsgBox does matter because you are making another window (the MsgBox) the active window briefly, and you are adding the active window to the group before you know it has had time to become active again. And it may take longer for Excel windows to become active.

boiler is correct in this situation. @autocart, can I suggest you replace your Msgbox test with a ToolTip or even a silent FileAppend with a timestamp? That might get you closer to what is actually going on. I personally have used Group commands for a long time (including Excel) without issue (except my own). I encourage you to look again and try again.

[autocart]

UPDATE for all reading this thread at any time:
Yesterday it did not work reliably. The problem I described had nothing to do with the MsgBox (whoever does not believe, must read the description of my problem again). MsgBox could potentially cause a problem, true, but it is not the one I described. But today the same code works fine. My problem with the Excel window - vanished. Since it works today, I have no idea what caused the problem yesterday. Maybe Excel or AHK don't like Thursdays. If I should one day be able to figure it out, I might post again. But probably it is unlikely. Regards, S.

[autocart]

Now, whoever knows and wants to answer this, please let me repeat the one yet unanswered question:

Is it possible to read out what window definitions are already defined inside an existing window group?

Thx. Regards, S.