Unigram: it's crash while I click the advance setting

[SteveLuo9]

Unhandled exception

System.ArgumentException: Delegate to an
instance method cannot have null 'this'.
at SharedLibrary! +0x7e3276
at
Unigram.Controls.StartupSwitch.
dl.MoveNextO + 0xe9
— End of stack trace from previous location
where exception was thrown —
at
System.Runtime.ExceptionServices.ExceptionDis
patchlnfo.ThrowO + 0x21
at
System.Runtime.CompilerServices.AsyncMetho
dBuilderCore. < >c. < ThrowAsync>b7JO(Otyect)

• 0x1 e
  at System.Actionl .lnvoke(Object,
  TEventArgs) + 0x2e
  at Interop.lntrinsics.HasThisCall24[TArgO]
  (Object, IntPtr, Object, TArgO) + 0x36
  at Unigram! +0x1 fb5ac0

[m-alice]

Same exception after unigram's update, but application not crashed, just shows exception window.
Windows 10 pro 1909 build 18368.815 week after clear reinstall
In prev update it lost their notification area icon

[amithiel]

Confirming this. Lost tray icon, and crashes when trying to access advanced settings
Windows 10 pro 19.09.
Unigram 3.15.4756

[Daksh777]

@amithiel The tray icon was already removed.

[amithiel]

@amithiel The tray icon was already removed.

What? may i ask why? there used to be an option to enable it or not

[FrayxRulez]

What? may i ask why? there used to be an option to enable it or not

It caused a few issues including but not limited to:

• Users being always online
• App reopening by itself when closed from the system tray
• App running outside of the "sandbox" (for someone this is a security issue)

None of the above issues are easily fixable or fixable at all.
May I ask why is the tray icon so important to you?

[amithiel]

What? may i ask why? there used to be an option to enable it or not

It caused a few issues including but not limited to:

• Users being always online
• App reopening by itself when closed from the system tray
• App running outside of the "sandbox" (for someone this is a security issue)

None of the above issues are easily fixable or fixable at all.
May I ask why is the tray icon so important to you?

well, I'm a tray guy. when I know I'm using an app all day, I like to have it in the tray, so it's not in my way. the importance of tray is really at stake? how does the official telegram app handles that?

[MarcAnt01]

@amithiel Telegram Desktop is not UWP, so it's a completely different kind of app. UWPs aren't made to be used with tray icons, Unigram was just using Desktop Bridge workaround

[amithiel]

@amithiel Telegram Desktop is not UWP, so it's a completely different kind of app. UWPs aren't made to be used with tray icons, Unigram was just using Desktop Bridge workaround

thanks for clarifying. that's too bad I liked unigram a lot.
cheers

[FrayxRulez]

Tray icon is considered something obsolete by Microsoft and it doesn't offer to UWP developers the ability to have one in their apps.
Telegram Desktop literally simply creates a icon in the tray, and it handles it in code.
To do the same thing in a UWP app you must use an hack, that consists in creating an additional app, that's actually a Win32 program, just to display the tray icon and handle it.

[MarcAnt01]

@amithiel Telegram Desktop is not UWP, so it's a completely different kind of app. UWPs aren't made to be used with tray icons, Unigram was just using Desktop Bridge workaround

thanks for clarifying. that's too bad I liked unigram a lot.
cheers

I can suggest you to pin Unigram to the taskbar, in the end it's almost the same😁

[FrayxRulez]

the importance of tray is really at stake?

Yes, but not by my decision but by Microsoft's. I'm really trying to figure out why you feel the need to have it, this is still unclear to me.

[MarcAnt01]

the importance of tray is really at stake?

Yes, but not by my decision but by Microsoft's. I'm really trying to figure out why you feel the need to have it, this is still unclear to me.

I have a friend of mine who uses Unigram that told me the same, it's not really something needed, but he has this type of apps in the tray icon so that he can quickly launch them

[amithiel]

Tray icon is considered something obsolete by Microsoft and it doesn't offer to UWP developers the ability to have one in their apps.
Telegram Desktop literally simply creates a icon in the tray, and it handles it in code.
To do the same thing in a UWP app you must use an hack, that consists in creating an additional app, that's actually a Win32 program, just to display the tray icon and handle it.

yeah, well buddy. I'm old-school. that's why in Linux, there are Gnome fans, and Xfce fans.
I know tray it's not the future, but i have to try to fight it for as long as I can. don't get me wrong, I belong to the fewer percentage

[FrayxRulez]

but I have to try to fight it for as long as I can

I completely understand what you mean, but I feel that in this case you're fighting with the wrong person. Probably you should show to Microsoft your interest into having the tray icon back.

In the meanwhile, would it be any good if I actually send you the .exe used to create Unigram tray icon? It should work exactly the same.

[amithiel]

but I have to try to fight it for as long as I can

I completely understand what you mean, but I feel that in this case you're fighting with the wrong person. Probably you should show to Microsoft your interest into having the tray icon back.

In the meanwhile, would it be any good if I actually send you the .exe used to create Unigram tray icon? It should work exactly the same.

I'm not fighting with you guys. I'm here talking with you, because it's possible. Microsoft is a large corporation, they would never reply me. :)
I was just sharing my points. I would love that .exe yes,thanks so much

[FrayxRulez]

I would love that .exe yes,thanks so much

I have to first release an update to turn on the app connection in the manifest, then I will send it to you.

[amithiel]

I would love that .exe yes,thanks so much

I have to first release an update to turn on the app connection in the manifest, then I will send it to you.

Thanks, i really appreciate!

[alex-fgsfds]

Without the tray icon notification, the counter on app's tile and taskbar button stopped working correctly, it retains the latest number there was until the app is restarted. Here I have more than 1 unread (push notifications work correctly still), but the counter won't update.

[FrayxRulez]

Without the tray icon notification, the counter on app's tile and taskbar button stopped working correctly, it retains the latest number there was until the app is restarted. Here I have more than 1 unread (push notifications work correctly still), but the counter won't update.

Badge and tray icon are two different things, in fact the first one is a UWP specific feature, while the second is a legacy Win32 component.
Badge stopped updating likely because of this: https://github.com/UnigramDev/Unigram/commit/6be63b2074b11ee83f21f9cbe20e959bd176a8a it’s a temporary piece of code to determine if badge updates cause explorer.exe to crash on Windows 20H1.

[adrianghc]

What? may i ask why? there used to be an option to enable it or not

It caused a few issues including but not limited to:

• Users being always online
• App reopening by itself when closed from the system tray
• App running outside of the "sandbox" (for someone this is a security issue)

None of the above issues are easily fixable or fixable at all.
May I ask why is the tray icon so important to you?

@FrayxRulez Out of curiosity, what makes those issues hard to fix or even unfixable (except for the sandbox point)?

The question is not intended as throwing shade, as in "I bet you just overlooked something", but as genuine interest, as I was considering trying to fix the issues with the tray icon myself so that one could once again have in-app notifications even while the app is closed, but then I stumbled upon that comment of yours.

[FrayxRulez]

@FrayxRulez Out of curiosity, what makes those issues hard to fix or even unfixable (except for the sandbox point)?

I think that the simple answer is: those APIs aren't intended to be used this way, and that's why those behaviors are appearing: by example UWP apps CAN'T reopen by themselves, if Unigram does it's clearly because of a bug in the app lifecycle management in Windows itself, and it isn't really something that I could fix myself.
There are also additional points to take into account when deciding if such investment is worth, and the main one is probably the currently unclear UWP future. Not even Microsoft seem to know what they want to do with it and many hints (WinUI is probably the most clear one) suggest that the plan might be to actually merge Win32 and UWP, but keeping Win32 as the "base" for it: in that case the whole thing we're doing here really makes little sense, because at that point it will be simply possible to use native tray icon APIs directly from the app code.

[adrianghc]

@FrayxRulez Out of curiosity, what makes those issues hard to fix or even unfixable (except for the sandbox point)?

I think that the simple answer is: those APIs aren't intended to be used this way, and that's why those behaviors are appearing: by example UWP apps CAN'T reopen by themselves, if Unigram does it's clearly because of a bug in the app lifecycle management in Windows itself, and it isn't really something that I could fix myself.
There are also additional points to take into account when deciding if such investment is worth, and the main one is probably the currently unclear UWP future. Not even Microsoft seem to know what they want to do with it and many hints (WinUI is probably the most clear one) suggest that the plan might be to actually merge Win32 and UWP, but keeping Win32 as the "base" for it: in that case the whole thing we're doing here really makes little sense, because at that point it will be simply possible to use native tray icon APIs directly from the app code.

I see. Not sure about merging Win32 and UWP at the expense of UWP's app model (lifecycles, permissions etc.), but we'll see what happens.

What about the "always online" issue? That doesn't seem like it would be on the UWP APIs. Is that perhaps a flaw of TDLib where there is no distinction between "in the foreground, therefore online" and "in the background, therefore offline", so as long as the tray process is active, there is no way to be shown as offline at the same time? (Just a guess without knowing much about TDLib at all.)

[FrayxRulez]

What about the "always online" issue? That doesn't seem like it would be on the UWP APIs. Is that perhaps a flaw of TDLib where there is no distinction between "in the foreground, therefore online" and "in the background, therefore offline"

TDLib doesn't take care about view lifecycle at all.
What I do is to listen for window activation state changes and settings online status consequently to them, nothing else.

[adrianghc]

What about the "always online" issue? That doesn't seem like it would be on the UWP APIs. Is that perhaps a flaw of TDLib where there is no distinction between "in the foreground, therefore online" and "in the background, therefore offline"

TDLib doesn't take care about view lifecycle at all.
What I do is to listen for window activation state changes and settings online status consequently to them, nothing else.

Not view lifecycle, my idea was more along the lines of "if you're connected to the Telegram server using TDLib, you're always online, no matter what". But it was just a wild uneducated guess.

Then what is the unfixable problem there?

[FrayxRulez]

Then what is the unfixable problem there?

Didn't say it's unfixable, but that's not trivial, and considering all the other things I don't think that the investment really makes a sense.
I truly dislike the "bridge" thing and I'm pretty happy not to use it.

[adrianghc]

Then what is the unfixable problem there?

Didn't say it's unfixable, but that's not trivial, and considering all the other things I don't think that the investment really makes a sense.
I truly dislike the "bridge" thing and I'm pretty happy not to use it.

Okay then. I don't really care about the tray icon per se, only about the fact that in-app notifications work great while push notifications don't. Though I guess this could be realized without a tray icon, just with an invisible background process? That would also presumably avoid the other problems with the tray icon. Would it be possible to have that background process not affect online status at all, so that online status could be set exactly as it is now (which seems to be working)?

[FrayxRulez]

Well, all those problems aren't really caused by the tray icon itself but by the background process that hosts it. A background process still requires desktop bridge, because that's a unsupported scenario in a UWP app.

[MarcAnt01]

Probably won't help, but what about that?
https://docs.microsoft.com/en-us/windows/uwp/launch-resume/run-in-the-background-indefinetly

[adrianghc]

Well, all those problems aren't really caused by the tray icon itself but by the background process that hosts it. A background process still requires desktop bridge, because that's a unsupported scenario in a UWP app.

Maybe this was just a misunderstanding on my end then. Since one of the issues was

App reopening by itself when closed from the system tray

I thought that problem only occurred when right-clicking the tray icon and selecting Quit. Without the tray icon, that scenario would not be possible.

So the problem with the online status is that when there is the bridge process, the listening for window activation states does not work properly anymore?

[FrayxRulez]

I thought that problem only occurred when right-clicking the tray icon and selecting Quit. Without the tray icon, that scenario would not be possible.

No, it also occurred by closing the app by using "X" title bar button

[FrayxRulez]

So the problem with the online status is that when there is the bridge process, the listening for window activation states does not work properly anymore?

I didn't investigate at all into this honestly. It's basically impossible to debug the bridge because it's two separate processes and last time I tried it wasn't possible to launch them together from Visual Studio. To state it clearly: desktop bridge for UWP apps is a hack itself.

[adrianghc]

I thought that problem only occurred when right-clicking the tray icon and selecting Quit. Without the tray icon, that scenario would not be possible.

No, it also occurred by closing the app by using "X" title bar button

I see, then that was a misunderstanding on my end. Thanks for clarifying.

[adrianghc]

So the problem with the online status is that when there is the bridge process, the listening for window activation states does not work properly anymore?

I didn't investigate at all into this honestly. It's basically impossible to debug the bridge because it's two separate processes and last time I tried it wasn't possible to launch them together from Visual Studio. To state it clearly: desktop bridge for UWP apps is a hack itself.

I see. And even if you or someone fixed the "always online" issue, there'd still be the problem with the app reactivations. Probably not worth it then. Too bad, but thanks a lot anyway.