Slack no longer winExist-able

[cssyphus]

Has anyone played with WB and Slack at all?

I have a Swiss-army-knife background app that monitors my environment and restarts Slack on those occasions when I accidentally close it.

At some point, Slack has become invisible to WinExist() - I can see six copies of Slack background processes in the Windows10 Task Manager, process name for each is "slack.exe" - but winExist('Slack') returns 0.

Any thoughts, anyone? Am I missing something obvious, like I usually do?

[td]

WinExit expects a partial window name and not an exe or process name so you need to find out what the window name of the main Slack window is.

You could also consider testing the WinItemProcID and TerminateApp functions that may work with Slack.

There may be other approaches, including using the CLR hosting, if the above doesn't yield the desired results.

[cssyphus]

Hi Tony - the Window Name for Slack appears to be invisible to WinBatch. For example, here is what is displayed in the Task Manager, under Background Processes:

https://imgur.com/a/fjqjnLi

But WinExist('Slack') returns 0.

So, in the above-linked screencap, is Slack the Window Name that should be detectable by WB, or am I missing something?

Do you have Slack installed? Can you try WinExist('Slack') on your side?

All I want to do is detect when Slack is closed, and re-open it under certain conditions.

[spl]

Maybe off-topic for this thread. But here is an user-udf posted years ago that would test for a process based on an exe

Code (WINBATCH) Select Expand

#DefineFunction udfProcID(processname)
   retvalue = 0
   objWMIService = ObjectGet("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
   strQuery = 'select * from win32_process where Name = "%processname%"'
   colProcesses = objWMIService.ExecQuery( strQuery )
   ForEach objProcess In colProcesses
       procid = objProcess.ProcessId     ;Specify required property here     
       If procid > 0 Then retvalue = procid
       Break
   Next
   objProcess    = 0
   colProcesses  = 0
   objWMIService = 0
   Return retvalue
#EndFunction

processname = "slack.exe"
ret = udfProcID (processname)
Message("Process ID for %processname%", ret)


[cssyphus]

Stan!

That works great - Thank you!

FFR: If winExist() does not detect a window title when you know for sure the app is running, this little UDF returns the procId of 'appname.exe' (e.g. "slack.exe"), or 0 if it ain't running. I don't know what's up with these new programs that don't have detectable window names, but this little UDF totally saved the day.

I'll bet this will also solve problems I am having detecting Zoom windows... and Outlook windows... and etc.

Many thanks,
cssyphus

[td]

Hi Tony - the Window Name for Slack appears to be invisible to WinBatch. For example, here is what is displayed in the Task Manager, under Background Processes:

https://imgur.com/a/fjqjnLi

But WinExist('Slack') returns 0.

So, in the above-linked screencap, is Slack the Window Name that should be detectable by WB, or am I missing something?

Do you have Slack installed? Can you try WinExist('Slack') on your side?

All I want to do is detect when Slack is closed, and re-open it under certain conditions.

Slack and newer iterations of Outlook are UWP (a.k.a. Windows store apps) applications. They usually (but not always) have a main window name but not always the one you think or see. Outlook is an interesting animal because it has different Window names depending on which version you are using. There is a version that is a part of Windows 10/11 and one that is a part of Office. 

One of the best ways to determine if the main window name of an application is to use Spy++ from the Windows SDK. The WinBatch analyzer script is also useful but does not always provide the necessary information.

This issue has been known for some time and is why WinBatch has more processid based functions and has added processid awareness to existing functions.  It is also why I suggested several processid aware functions in my original reply.

Stans WMI script is another approach to obtaining the processid of an application but there are several others available.

Here is a CLR example:

Code Select Expand

strProcName = "Notepad"  ;

;; Start the UWP application.
RunApp(strProcName, 0)
TimeDelay(5); UWP apps are slowwwww.

ObjectClrOption("useany","System")
objProcess = ObjectClrNew("System.Diagnostics.Process")
aProcs = objProcess.GetProcessesByName(strProcName)
foreach Proc in aProcs
   Proc.Kill()
next
exit 


[spl]

(OFF-TOPIC) Nice to see the CLR brought into the thread. The System.Diagnostics.Process class has methods which permit capturing STDOUT/STDERROR if needed for certain operations.

[td]

Here is a link to the Process class documentation:

https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=net-8.0

Note the id property of the process object. It returns the processid of a process.

Code Select Expand

id = Proc.Id