Can't get activated event

[Nikolai Orekhov]

I tried to use powertoast with @nodert-win10-20h1 and electron 16.0.7 but I can't get 'activated' event.

It's always 'TimedOut' when I click on it or 'UserCancelled' when closed.
And no event when clicking on the notification in action center (just like in electron native or node-notifier)

P.S. Also some inconsistencies in esm.d.ts: bool should be boolean and some more.

[Anthony Beaumont]

Hi, I was able to reproduce both errors.
But I do not know why NodeRT/WinRT triggers the onDismissed cb instead of the onActivated cb when clicking the toast.
And indeed unlike in node, onActivated cb isn't even triggered from the action center (click).

I don't know who is the culprit or where is the error. All I can say is that it works as intended in node.
It might even be specific to @nodert-win10-20h1 since it's "experimental".
I'll try to poke around tho but I don't know if I can fix it from this lib.

PS: Oh I'm deeply sorry for the inconvenience. I'm really just discovering typescript.

[Nikolai Orekhov]

@nodert-win10-20h1 with node 16.13.1 result is the same. So I guess it's the NodeRT issue

[Anthony Beaumont]

The problem seems to appear when there is no "onClick" registered (buttons included) whether it's in node or electron.
But the callback behavior is consistent with PowerShell core...
So actually it's not a bug per say that's just how it's handled by Windows now:
If there is no clickable action registered you can't "activate" a toast and since click will just dismiss it, the timedOut is triggered early instead of at the end of the max allowed time.

[Nikolai Orekhov]

Can you please post an example with onClick ? I tried something like this and it's not working still.
Also note now there's no way to pass onClick data to activated event.
Related to powershell mode I think this is not really usable. Powershell script execution is disabled by default for most of the users so it won't work in installable app.

// Callback
toast({
    onClick: 'hello, world!',
    title: 'Title',
    message: 'Message',
    button: [
        {
            text: 'Hello',
            onClick: 'click me',
        },
    ],
    callback: {
        keepalive: 50000, // keep-a-live in ms
        onActivated: () => {
            console.log('activated');
        },
        onDismissed: (reason) => {
            console.log(reason);
        },
    },
})
    .catch((err) => {
        console.error(err);
    });

[Anthony Beaumont]

Unfortunately as per Microsoft doc it has to be a valid protocol type action.
So things like:

onClick: "bingmaps:?q=sushi"
onClick: "https://www.google.com"

[Anthony Beaumont]

You can create your own URI scheme to pass a value back but a callback is obviously easier.
Powershell execution policy is irrelevant (it can be bypass) the problem is that powershell core is required for callback and it's not installed by default. If I mention it; it was just to point out that it's not an issue with WinRT.

I'm thinking of detecting if there is a click action and manually triggered the onActivated callback, that would "fix" your problem ... but it clearly seems that it isn't supposed to work like that anymore and that's just how it's handled by Windows now

So I'm not sure if I should do it.

[Nikolai Orekhov]

Thank you very much!
This is very logical taking into account these notifications can survive reboot. So it's absolutely correct that app should be launched back with a custom URI scheme.
Moreover Electron already supports it and if launched second instance passes the call to the running instance.

I also managed to get activated event but only if click comes within keepAlive time. Though it is not very usable as there's no parameter passed back.

So I think custom URI scheme is a way to go.
Moreover Electron notifications have 'toastXml' string so I can use your library purely to nicely generate this XML with proper parameters without the need of NodeRT or powershell.

[Nikolai Orekhov]

Thanks again.
Looks like I don't need powertoast or any other toast libraries for Electron as notification api allows me to specify toastXml directly.
To work even from Action Center these toasts should specify custom protocols as actions and app should be aware of this custom protocol.

Though it would be nice to have a library to generate adequate XML's.

[Nikolai Orekhov]

As a follow up for version 2.0.2:
I can get click from Action Center if I leave default appID.
If I set appID to my registered Electron app that is installed only clicks from open notification can be seen.
No clicks from actionCenter.

Though works with MSEdge or Chrome for example.

Tried with a simple node example.

[Anthony Beaumont]

After browsing Microsoft doc, taking into account the workaround I'm using for the original "issue" (7555ddc), I believe the problem is because with a win32 appID the shortcut needs a CLSID (Com interface) registered for action center persistence (and thus a valid activated behavior down the line).

I'm taking innosetup as an example here since that's what I am familiar with for building Windows installer.
In innosetup just like you have an AppUserModelID parameter to register the AUMID on the sortcut (appID) there is also a
AppUserModelToastActivatorCLSID to register the CLSID.

I'll need to do some testing to confirm. Now it's too late for me, apologies.

[Nikolai Orekhov]

Thanks. Looks like it's the issue.
Though I need to add a real com server behind it with something like electron-windows-interactive-notifications.

[Anthony Beaumont]

I'm afraid there isn't much more I can do regarding this ^^

[Nikolai Orekhov]

I managed to do almost everything I wanted with this.
Just for your information: I see that you put condition activationType="${options.callback && !options.onClick ? "background" : "protocol"}"
This is not fully correct as both with foreground and background you can also have arguments.
So I would better provide the user with activationType parameter rather then guess it.

For foreground and background type one will need installed and registered COM server. Important note that in this case you won't get activated event after the timeout if the app with your appId is not properly installed (you must have Start Menu shortcut with AppId and ToastActivatorCLSID and registered COM server for your ToastActivatorCLSID)

For protocol type you would need a registered custom protocol.

So the user mush choose what's better for him.

There's also system activation type - though it's not clear what it means. I got it from samples in Notification Visualizer

[Anthony Beaumont]

Yes, now that I have a better grasp of the situation with activationType it makes sense to expose it for advance usage.
But I will still keep the condition as default as I feel this is a nice workaround for the original issue in the context of the scope of this lib.