If Ripcord is at the Windows tray, it is usual to click it's icon (muscular memory) and receive the message:

"It looks like Ripcord is already running. You may also be seeing this message if Ripcord recently crashed. [...]"

Maybe it would be viable to create an option to "Try to open already created Ripcord proccess", instead of (or before) sugesting forcing a new one to be created (which is already not recommended).

I'm guessing what you're saying is that you are using Windows, you have a shortcut to Ripcord pinned to the taskbar, you also have Ripcord running and set to display a tray icon, and you have also set Ripcord to stay running in the tray even after the last window is closed, and you are closing the last window and then trying to launch another instance of Ripcord by clicking on the item in the taskbar.

And instead of it trying to launch another instance of Ripcord, it should recreate a window in the already-running one.

Well, unfortunately, that's not how Windows taskbar itself works. The behavior that Windows does is that it tries to create another process of Ripcord. This is out of my control. The OS is doing this.

But there is a way to circumvent it -- you create a meta-wrap launch thing that looks for existing Ripcord processes and then forwards the second launch to them. That's how other software that implements this launch-forwarding feature (like web browsers) does it.

I agree this would be nice to do, but it's actually a lot of work to implement this feature -- it's quite complicated in that it has to interact with the system and process list, and can potentially be unsafe. So it's like weeks of work, potentially, for this one small thing.

I'm probably never going to implement it, because it requires adding a lot of code to Ripcord and altering how the program starts up -- it will make launching the software slower for everyone, every time they run it. And it's an ongoing maintenance burden.

My recommendation for now is "stop hitting yourself" -- don't close the last Ripcord window if you plan to click on the icon in the taskbar again. That's what the taskbar is for. Just minimize it like normal. I believe this is why Windows itself has this behavior. Of course, I could be making a mistake and there's something I'm overlooking here. If there's a reason you prefer to close all of the windows and then expect to re-open it via the taskbar instead of just minimizing, maybe I could try to fix that reason instead? It would probably be easier than making the startup procedure of Ripcord more complicated.

Your guess is absolutely right. That behaviour you described in the first paragraph is what I "expected".

I also understand the hassle of creating a proxy process just for solving this VERY minnor "inconvenience". The way I had envision this solution was asking Windows API for his process list and, in the eventual existence of Ripcord there, a call of some sort for the app to show himself. But, even if possible, not only this would probably require administrator rights in order to work on W7+, as this solution would not be crossplatform. And, again, I honestly agree it doesn't worth it AT ALL.

The easiest solution is to, me as a user, remove my task bar Ripcord icon and get used (as a normal human being) to call it from the system tray, which is, in fact, the correct way of using it.

I want to thank you, not only for your response, but for the software itself. The official Discord app takes TOO much screen space (not mention resources). This software should REALLY be advertised for streamers because you can't really fit Discord + SLOBS in the same FHD resolution screen.

I wish you all the very best.

Thanks for responding and not being angry :)

The problem with just looking at the process list is that it breaks under several conditions that are pretty common for Ripcord users -- intentionally running more than one Ripcord process, which you can do in "portable data mode". It also breaks for running multiple different versions of Ripcord simultaneously (which is less common, but maybe some people do it...).

This isn't a problem for web browsers like Chrome and Firefox since you can only run one "copy" of them at the same time. (These programs are already "distributed"-like software on your computer -- they spawn several or dozens of processes in the background that never quit, and talk to each other with cross-process communication.)

Another problem is that you could trick Ripcord into launching or sending commands to a non-Ripcord process by toying with the name of processes in the process list. This is a potential security risk, so I'd have to add code that somehow vets the versions/hashes/signatures/whatever of the processes it's trying to talk to... yeah.

Roger that!

=)