Closing a notification dialogue

[xtian170174]

Windows repeatedly informs a program update issue, which if the program is to remain installed [and considering it is not itself running], will not be prevented by e.g. run as administrator, or toggled in the program settings, or that a change in this behaviour is observed when the program is running - and I perceive this is possibly the result of a folder\path being too long [too many characters] or something, so that results a couple or more times in quick succession - every five to ten minutes of using the computer - with this update dialogue notification announcing it has failed.
I do not mind it running if there's no perceived impact on system resources - I just mind it popping up and having to clear it down.

For that matter I wrote this script,

Code: Select all

SetTitleMatchMode 2
 id := "dialogue title" 
IfWinexist, dialogue title
	WinActivate  ;
SendInput {Esc}

Whether it works or not is moot. Notably, it will run once and then quit, while it needs to be permanently featured in SysTray for every instance of the offending dialogue to be met and dealt with in short order.

So, I then added a line,

Code: Select all

SetTitleMatchMode 2
 id := "Opera_GX" 
IfWinexist, Opera_GX 
	WinActivate  ;

Esc:: Send {Esc}

SendInput {Esc}

[Mod edit: [code][/code] tags added. Please use them yourself when posting code.]

And this ensures it remains in the Systray because it is waiting for the keystroke to be manually entered. There is an issue however with this, it will send the Esc keystroke tens of times per second every time it is pressed in any other context, and then another dialogue will pop up for the script itself asking if that is what you want and whether or not to keep running it?

The obvious answer is therefore to now use an alternative to clearing the dialogue down, not a simple Esc keystroke, but e.g. making the dialogue the active window in the foreground, defining the pixel coordinates of either the 'X' close button in top right, or 'Ok' button and sending the mouse l/click instruction instead.

I guess I'm happy that any & all of this is possible - but a script could be kept very simple for these sorts of instances, like the first and simplest one I created.
...I'm aware that program update is not going ahead [it's only a 'check for update' though after all] and I'm choosing to acknowledge this by ignoring it, and at some stage I will need to reinstall a more recent app version to bring it up to speed that way instead, and then likely choose/rename it's path(s) too, to avoid it all happening again..., but essentially a script waiting on that popup needn't be more than the simplest/most succinct way of handling the matter - once a WinTitle is specified, the way the dialogue is closed [using Esc] should be limited to just that dialogue window and not prevent the Esc keystroke behaving differently in any other way [affecting other active windows].

I feel I have missed something therefore in specifying the WinTitle and a function of the Esc key in that context - as it performs differently as a result in other windows/desktop environment...
...Any pointers?
[Mod edit: Removed a supposedly unintentional s-tag (strikethrough).]

[Mod edit: Moved topic from AHK v2 help to v1 help, since this is not v2 code. AHK v2 is the new main release.]

[kunkel321]

Sorry I'm having a hard time following the overall question, but here are a couple of observations. First, I'm a newbee, so this might be wrong info... but: I think the Esc:: Send {Esc} might break the flow of your code(?) The one line is equivalent to

Code: Select all

Esc::
Send {Esc}
Return

so the code under it never runs, even if you press esc. Also, I think it's redundant(?) It just watches for and intercepts the Esc key for the purposes of sending the esc key.

Also with the line id := "dialogue title" you are setting the variable id to that string value, but then not using it for anything.

That's all.

[xtian170174]

That makes sense, given the message it returns.

Succinctly, a notification that can just be cleared down by clicking 'ok', comes up so often in a single session that I'm clearing it down automatically with an ahk script.

It should otherwise be possible to replicate anything described from the code used, but obviously I'm still getting round it stopping after the first instance, and the 'Esc key smash record' message it returns.

It should be watching for something - that is what keeps it in the systray, and my theory was that making it only send itself reverts the key to usual functioning...
...and also, while I noticed the term 'persistent' as I was looking into options for this and so tried it too, but it just stopped the script with an error.

[kunkel321]

Hopefully I'm not giving you bad advice here... It's usually not a good idea to have a loop run forever. That said, maybe you can build on this. It waits for Notepad to be open, then sends "hello world." Then there is a three-second pause and it starts waiting again. The soundbeeps are just for debugging... Get rid of them once you have your code working.

Code: Select all

#SingleInstance, Force
#Requires AutoHotkey v1.1.33+
SetTitleMatchMode 2

Loop
{
	soundbeep 1300, 600 ; high pitched -- remove later
	WinWaitActive Notepad
	{
		SendInput hello world
		SoundBeep 700, 600 ; low pitched -- remove later
	}
	Sleep 1000*5 ; 5 seconds between loops. ; use 1000*60*X for X minutes. 
}

I do recommend having the sleep as long as possible.

EDIT: I just notice in your code, that you have Opera_GX for the match. Be sure that you are matching on a string of characters that appears in the dialog each time, but does NOT appear and the top of the Widow where you are working... You don't want it to send Esc every time you open the application; only when the unwanted dialog appears.

Edit again: Those inner braces are not needed LOL. This works the same:

Code: Select all

#SingleInstance, Force
#Requires AutoHotkey v1.1.33+
SetTitleMatchMode 2

Loop
{
	soundbeep 1300, 600 ; high pitched -- remove later
	WinWaitActive Notepad
	SendInput hello world
	SoundBeep 700, 600 ; low pitched -- remove later
	Sleep 1000*5 ; 5 seconds between loops. ; use 1000*60*X for X minutes. 
}

[DuckingQuack]

@kunkel321 I agree with you about loops running constantly being bad, which is why I go out of my way to come up with inventive ways to apply SetTimer. WinWait will just look for the window to exist rather than being active, so you can send a close command a little faster.



This is a v2 example, adapt as needed.

Code: Select all

#Requires AutoHotkey v2.0
#SingleInstance Force
DetectHiddenWindows True

Esc::ExitApp

SetTimer(FnClose, 1000)
FnClose(){
    WinWait("WinTitle")
    ; Sleep(1000) ; This sleep shouldn't be needed unless your pc sends the command before the window can accept a command
    WinClose("WinTitle")
}