Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

GUI without persistence


  • Please log in to reply
28 replies to this topic

Poll: #Persistent OFF (12 member(s) have cast votes)

#Persistent OFF

  1. Yes, I'd love it (6 votes [46.15%])

    Percentage of vote: 46.15%

  2. Why Not? (2 votes [15.38%])

    Percentage of vote: 15.38%

  3. Why? (4 votes [30.77%])

    Percentage of vote: 30.77%

  4. No, I'd hate it (1 votes [7.69%])

    Percentage of vote: 7.69%

  5. Blue. No i mean YEL.... (0 votes [0.00%])

    Percentage of vote: 0.00%

Vote Guests cannot vote
Rapte_Of_Suzaku
  • Members
  • 901 posts
  • Last active: Jul 08 2011 02:12 PM
  • Joined: 29 Feb 2008

Gui, -ExitAppOnClose

I now see that I entirely misread your post. That is exactly what I want. Sorry for the confusion!

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
#Persistent merely sets g_persistent=true. Any use of the Gui or Input commands or OnMessage function also sets g_persistent=true when the line containing it is pre-processed at load-time. Setting g_persistent=false might be simple, but it would necessarily override every preceding part of the script, even those not related to that particular Gui. For instance, the script might use two Gui: the first requires g_persistent==true and the second requires g_persistent==false. If the second were to set g_persistent=false, the first would not function correctly.

Currently a script "IS_PERSISTENT" if g_persistent is true or it contains hotkeys or hotstrings or the keyboard and/or mouse hook is installed. I suppose those other cases must be ignored after #Persistent Off (or equivalent) has been used, to be intuitive. On the other hand, Gui -Persistent should only affect Gui, by definition. If it is checked at run-time, this would not be possible.

Gui, -ExitAppOnClose

I do not see how removing this hypothetical option from the Gui would help, as it doesn't apply in the first place. Ordinarily the app is not exited at all if the Gui command has been used unless the script explicitly exits. I suppose that (logically) a script should continue to run as long as any threads are active or it has the means to launch new threads; i.e. a Gui is visible, it has hotkeys or hotstrings, has active message monitors (OnMessage), has active timers, etc.

MacroMan!
  • Members
  • 604 posts
  • Last active: Mar 20 2012 11:40 AM
  • Joined: 28 Aug 2009
I fail to see why having this option would even be an advantage.

Take this simple example:

Gui, Add, Text,, This is some text
Gui,  Show

If this was not persistent, the script would run, create and show the GUI and immediately exit, destroying the GUI. All at such a speed that the user would barley see the gui, let alone have time to interact with it.

The only way this could be done is if Gui, Show acts like a MsgBox or InputBox, which would remove a lot of functionality from the Gui and GuiControl commands (since this would pause the script while showing the Gui) - something that makes AHK so powerful.

David
What ever happened, happened.

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008

...has active timers...

Currently SetTimer doesn't make a script persistent.
Example:
SetTimer, Label, 1000
return

Label:
Msgbox, This is never shown
return

aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

Rapte_Of_Suzaku
  • Members
  • 901 posts
  • Last active: Jul 08 2011 02:12 PM
  • Joined: 29 Feb 2008

I suppose that (logically) a script should continue to run as long as any threads are active or it has the means to launch new threads; i.e. a Gui is visible, it has hotkeys or hotstrings, has active message monitors (OnMessage), has active timers, etc.

That gives me an idea. A list of blocking items could be kept by the script. Every time that list is updated, the script would check to see if it can close or not. The key thing is that GUIs with a hypothetical "Persistant" option removed would not be added to the list.



me01273, how does this make more sense:
Gui, Add, Text,, This is some text
Gui,  Show
MsgBox
Gui, Destroy
Besides, you wouldn't have to use the new non-persistant GUI if you didn't want to

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Currently SetTimer doesn't make a script persistent.

That's irrelevant.

The only way this could be done is if Gui, Show acts like a MsgBox or InputBox,

If you search the forums, you may find scripts which use Gui and WinWaitClose to implement custom dialogs.

A list of blocking items could be kept by the script. Every time that list is updated, the script would check to see if it can close or not.

AutoHotkey internally has lists of all the things I mentioned. "Persistence" is only relevant when the Exit command is used or the bottom-most thread finishes. If the script is not considered persistent at that point, it should terminate. (The current behaviour is somewhat like that: when Exit is used or the auto-execute section finishes, the script terminates if it is not persistent.)

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

do not see how removing this hypothetical option from the Gui would help,

Ah sorry, I thought +ExitOnClose :D. Was using cmd line syntax accidentally.
I think its easiest to implement and its useful, since you don't have to be concerned with other windows created, and user can have fine control over which window does it.
Posted Image

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
So instead of forcing the script to be persistent, force the script to terminate? That might be useful in some very specific cases, but it's no solution.

Rapte_Of_Suzaku
  • Members
  • 901 posts
  • Last active: Jul 08 2011 02:12 PM
  • Joined: 29 Feb 2008

"Persistence" is only relevant when the Exit command is used

So if "-persistent" GUIs were excluded from the list and GUIs in general would not automatically set the g_persistent flag, a workaround could be to SetTimer a subroutine that calls Exit?

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I don't think I understand your line of thought.

The GUI list has no relevance to script persistence. If a GUI was omitted from the list, the Gui commands would not be able to access it.

The timer subroutine would either have no effect or would have an undesired effect. If the script is persistent, Exit will simply end execution of the timer subroutine. If the script isn't persistent, the timer can only fire if there are still active script threads, in which case it shouldn't exit. If the script isn't persistent and the auto-execute section finishes, the script terminates and the timer ceases to exist.

A solution (not "workaround") would be to remove g_persistent and implement more complex logic as per my previous suggestion (beginning with "I suppose that").

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
That OK for me. Persistent should really be outdated.
Posted Image

Rapte_Of_Suzaku
  • Members
  • 901 posts
  • Last active: Jul 08 2011 02:12 PM
  • Joined: 29 Feb 2008

The GUI list has no relevance to script persistence.

I thought it did? I must have misread the following... so that's why you didn't understand my line of thought!

A list of blocking items could be kept by the script. Every time that list is updated, the script would check to see if it can close or not.

AutoHotkey internally has lists of all the things I mentioned.


As for the timer, I thought they didn't affect persistence (as Frankie said)... oh well.

A solution...as per my previous suggestion (beginning with "I suppose that").

+1

None
  • Members
  • 3199 posts
  • Last active: Nov 05 2015 09:55 PM
  • Joined: 28 Nov 2009
How about Gui, Destroy also removing the persistence caused by that Gui.

Removes the window (if it exists) and all its controls, freeing the corresponding memory and system resources. If the script later recreates the window, all of the window's properties such as color and font will start off at their defaults (as though the window never existed).

It would more seem consistent because the way it works now if you make a script with just Gui, Destroy in it, the scipt is persistent because it has a gui command not nonpersistent because the window never existed.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

I must have misread the following...

Yes. My point was that the lists are there, so they could be used for this purpose, but currently aren't.

As for the timer, I thought they didn't affect persistence

They don't. Earlier I suggested that they should, but that isn't relevant to my previous post.

How about Gui, Destroy also removing the persistence caused by that Gui.

I suppose what you're asking is for the script to be persistent as long as a Gui exists, which basically requires changing it to work like I suggested earlier.

It would probably be faster to check if the Gui exists, but I think checking visibility would be more logical. An invisible GUI probably isn't useful unless there's some way to show it (such as a hotkey or timer) or the script is monitoring messages it receives via OnMessage (or by subclassing the window, but it wouldn't be worth checking for that). What do you think?

It would more seem consistent

More logical or more useful, perhaps. More consistent, I think not. Whether or not the window ever exists is irrelevant:

Any script that uses the GUI command anywhere is automatically persistent (even if the GUI command is never actually executed).