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
From the manual:

Any script that uses the GUI command anywhere is automatically persistent


I'd like a way to override that. Like if I use toaster popups. If you think of them as really fancy traytips, then it seems silly to force any script that uses them be persistent. Yes, I can use ExitApp where necessary... but I'd still like a #Persistent OFF directive or something similar.

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005
+1

Chicken Pie 4 Tea
  • Members
  • 379 posts
  • Last active: Dec 12 2014 06:46 PM
  • Joined: 18 Aug 2009
me too
"Choose your parents wisely"

Frankie
  • Members
  • 2930 posts
  • Last active: Feb 05 2015 02:49 PM
  • Joined: 02 Nov 2008
What difference does putting '#Persistent Off' at the top of your script and putting ExitApp at the end of the autoexecute have?
In nonpersistent scripts AHK assumes there is an ExitApp at the end of the autoexecute section.

[color=red]#Persistent off[/color]
Gui, Add, Button,, Press_Me
Gui, Show
Sleep 5000
return

;or

Gui, Add, Button,, Press_Me
Gui, Show
Sleep 5000
[color=red]ExitApp[/color]
return

I think its easier to put ExitApp.
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
It isn't that it is so hard to add ExitApp, but rather that it makes little sense. Why should my script stick around after I've closed my GUI? Heck, it'll become persistent even if the GUI is never created. And unless I resign myself to always use ExitApp just in case, it adds an annoying requirement to any library that utilizes a GUI... if I wanted to use toaster tips for my debugging library, I'd have to temporarily modify any script I'm debugging to use ExitApp. If I'm debugging my FileContainer object in this way, then I also have to modify any of the scripts that use FileContainer to use ExitApp as well. And anyone else who uses my debugging library will have to do the same. That takes the convenience out of quick debugging statements.

MacroMan!
  • Members
  • 604 posts
  • Last active: Mar 20 2012 11:40 AM
  • Joined: 28 Aug 2009
I think it wouldn't be neccesary to have a #Persistence Off function.

It's less work to put ExitApp at the end than #Persistence Off at the beginning.

David
What ever happened, happened.

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

It's less work to put ExitApp at the end than #Persistence Off at the beginning.

Less work for simple scripts, but not for libraries. I think I'll add a poll (how fun!)

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

but not for libraries

Can you provide an example of when a library would use Gui commands and when a library would use directives :?: I can't think of any good reason.
aboutscriptappsscripts
Request Video Tutorials Here or View Current Tutorials on YouTube
Any code ⇈ above ⇈ requires AutoHotkey_L to run

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005
It is an ugly workaround to create/show a GUI from a library function, because it will make the calling script persistent.
If we had a Persistent ON/OFF and A_Persistent, Then we could do:

Func() {
 Old_Persistent := A_Persistent
 Persistent, OFF
 ....
 Do Gui
 WinWaitClose, Gui

 Persistent, %Old_Persistent%
}

I had to use CreateWindow() in my View()
I used an in-script DialogResource for HtmDlg()

Now I need to create a ProgressBar window with Close Button for my InternetFileRead() function and my only options are CreateWindow() or DialogResource.

One of the nice elaborate function that uses GUI commands:
CMsgbox() by jballi

AutoHotkey has the superior GUI capabilities, but unusable for library functions.

Rapte_Of_Suzaku
  • Members
  • 901 posts
  • Last active: Jul 08 2011 02:12 PM
  • Joined: 29 Feb 2008
Did the toaster tips + my debugging library not work for you and an example?
EDIT: SKAN replied quicker with more examples

SKAN
  • Administrators
  • 9115 posts
  • Last active:
  • Joined: 26 Dec 2005
Poll? Okay, I did not vote. I do not know how tough it will be to implement it.
Persistence is something that has to be decided at load-time rather than runtime..
Maybe the parser should see that GUI is being called from inside a function.
Whatever! Some facility that allows GUI creation from function without making the whole script persistent, would be very useful for:
Custom MsgBox / InputBox and Progress Windows

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
May be it would make more sense to add a new option to Gui command, like:
Gui, -Persistent
or
Gui, Show, NoPersistent
But the first one would make more sense. Because the persistent state is not changed at show time.

No signature.


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

I think it wouldn't be neccesary to have a #Persistence Off function.

This is directive and as such it is processed before the script is run. That means that you can't just switch it on or off. That requires changes that will introduce compatibility problems.

Gui, -ExitAppOnClose


is probably what everybody wants.
In Forms framework I included similar optionfor ESC:
hForm := Form_New("e3 ...")
which will exit the script if ESC is pressed while form is active.
Posted Image

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

exit the script if ESC is pressed while form is active.


If I understand that correctly, that's not want I'd want... Back to the toaster tips, it would be terrible to have the entire script die just because a user pressed ESC while a tip popped up. To phrase my wish differently, I want the GUI to be (optionally) subservient to the script. If the script wants to end, then the GUI gets out of the way and dies. If the script wants to keep going, it doesn't matter if the GUI is open or closed or whatever. This is for situations in which the GUI isn't the main function of the script.

[a new #Persistence Off directive] requires changes that will introduce compatibility problems.

None of the existing scripts would have to change at all. The new functionality should come only when someone uses that new directive.

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
That may be OK, but its not possible to use code posted by SKAN

About ESC, I said its similar, not the same. Form code can be changed so it monitors closing window instead of ESC keypress for the effect you want.
Posted Image