Auto-close a display dialog that was created by MacroDroid

Moutya

New member
I have created a pop-up dialog as part of a macro (by using: Notifications > Display Dialog).

Most of the time I close this dialog manually using the 'ok' button, but there are certain times when I want to automate the closing of this dialog.

How can I achieve this?

  • The 'Clear notifications' action does not work (presumably because it's a pop-up dialog and not a notification).

  • UI Interaction sort of works, but it's too broad because it does not identify the exact dialog. The best that I could manage is to limit the click to the MacroDroid app, but this causes unwanted 'ui interaction' clicks on random menus within MacroDroid if the display dialog is not present when the UI interaction action is triggered. I don't want it clicking just anywhere within MacroDroid (which is what it's currently doing). I want the click action restricted to only the specific MacroDroid display dialog that needs closing (unless there is another way other than UI Interaction to get rid of the dialog).

  • I can't find any kind of 'Constraint' that allows matching of the dialog's text in order to limit the UI Interaction click to only the desired display dialog.
Any help appreciated.
 
Last edited:

MacroDroidDev

Administrator
Staff member
You could try using the press back button action but you will still have the issue of unwanted back presses if you invoke it when a dialog is not present.
 

Moutya

New member
You could try with "Option Dialog" instead, there you can choose the default button and timeout

Unfortunately a timeout wouldn't work for my use case.
I need the dialog to stay open indefinitely unless a specified trigger occurs to close it (or I close it manually myself).


You could try using the press back button action but you will still have the issue of unwanted back presses if you invoke it when a dialog is not present.

Thanks for replying. If you don't know of a built-in way to achieve this then I guess it really can't be done (because if anyone would know how to do it, it would be you).

As you pointed out in your work-around suggestion, using the 'back' button suffers the same issue of being invoked when the dialog in question is not present (which can lead to unintended consequences depending on what's focused at the time).

However, I have now managed to fumble my way to a solution. It's clunky, but it works for me.

I created a boolean variable (%dialog_visible) and added a set variable action to make %dialog_visible = true immediately after anywhere that the dialog was invoked. I then added %dialog_visible = false to anywhere there was code that closed the dialog (by button-click or any other means). So the only time that the %dialog_visible variable is set to 'true' is immediately after the dialog has been invoked and before any action has been taken to close it.

I then just used %dialog_visible = false as a constraint for the macro that auto-closes the dialog. This constraint ensures that the UI interaction action (which clicks on the dialog to close it) does not fire unless the dialog is open on screen (because whenever it's not open %dialog_visible = false).

It would still be better to have id's for option and display dialogs (just like there is for floating text) because then you could target specific dialogs for closure or any other action.
 

Endercraft

Moderator (& bug finder :D)
I guess you can use read screen contents to determine whether a dialog is on the screen by searching for the corresponding key.
 

Moutya

New member
I guess you can use read screen contents to determine whether a dialog is on the screen by searching for the corresponding key.
That was one of the first things that I tried, but it was not available as a constraint or an action, and I was struggling to figure out how to get it to work for my situation from within a trigger.

Plus, the screen reader checks for text continuously, whereas flipping a var value is just one small action that happens only at the moment the dialog is invoked or closed (the rest of the time it's doing nothing and using no battery).
 
Top