Get application handle from process name

[Jeremy Whilde]

Is there a way in WB to get a handle from an application process name? or from the PID?

So if you have an application running as app.exe and you do not have its window name but you have the "app.exe" as process name and if required I can also get the PID of this, like this:

#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 = 'app.exe'   ; program / process name


ret = udfProcID (processname)


Message("Process ID for %processname%", ret)

So how do you get the handle for the app.exe? (remember I have not got the app.exe main window title as this unfortunately changes)

I had thought that I could use the above function and specify the property as "Handle" but this seems to also return the process ID and not the handle for the app.exe!

Thanks JW

[td]

Check out this Tech Database article.  It illustrates using the OpenProcess kernel32 function to obtain a process handle:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Samples~from~Users+Account~Name~Associated~with~a~Process.txt

Here is a link to the win32 function's documentation:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684320(v=vs.85).aspx

Please note the required SeDebugPrivilege privilege.

[oldone1]

  The supplied code works, but is not very understandable.  DLLCalls are very confusing.  There is another option, but you might not like it.  A competing product (Autoit) has a vast repository of user coded functions. There is one that does exactly what the original question wanted.  Their code did what your code did, but without having to actually code it.  The negative side is that you would have to install autoit and be able to invoke autoit from winbatch.  I have been doing that for years and it has been a great help.  An alternative would be to have a UDF respository included in the winbatch system. 

[td]

Rube Goldberg would be proud...

[snowsnowsnow]

What is the difference between AutoIt's "vast repository of user coded functions" and the WinBatch Tech Database (which is, surprise!, surprise! a vast repository of user coded functions)?

[td]

WinBatch and Audoit have a very similar (almost identical) procedure for calling Win32 APIs.  There are over 3500 examples in the WinBatch Tech Database and more than a few of those examples include  the WIL DllCall function.   In fact, there is even a tutorial on calling Win32 functions in the WinBatch Tech Database. 

One difference is that  Audoit's DllCall like user "libraries" serve a similar role to WinBatch extenders in many cases so there are conceivably more of them.   There is nothing stopping WinBatch users from creating extender like functionality using DllCall and related WIL functions.  They simply have not done as much of it or perhaps not been as inclined to give the results of any efforts back to the community.     

[oldone1]

 

  The point of my reply to the question regarding process handles was this

  1.  The autoit udf respository is part of the autoit system.  It is there for you look at
      when you are coding.  You access it via the help system(not required to use the internet
      to get the information).  The code is there.  All you have to do is code the use ie.

      user = _winapi_getprocessuser(PID)  (where _winape_getprocessuser is a UDF and
                                          (PID is the process id of the process involved)

     please note that you must also include the location of the udf via

     #include <WinAPIProc.au3>    the location of the udf



  2.  In the Winbatch tech database, the UDF must be copied and placed in your script.  If you
      wish to use the UDF in another script, it must be copied again.  Therefore if you have five
      scripts that use the UDF, you would have 5 copies of the uDF.  If the UDF is somewhat
      lengthy, you now have 5 rather large scripts.  If for some reason, the UDF code has to be
      modified, you have to do that 5 times. 

      However, I do recall  something about an #include directive. I am thinking that this could be
      used to store snippets of code that could be placed in your scripts.   I did not see anything
      about the location of these snippets.  If these snippets can be located in their own
      directory(within the winbatch main diectory). then the winbatch developers could store some
      of the more useful UDF's within this directory.

      I placed the udf from the tech database regarding user name for a process into the sample
      directory of winbatch and then included that file into my script and it worked.

      I now leave any further work to the powers that be as they see fit.

[td]

With regard to point 1, the industry trend is to use the Internet for documentation and source code.  For example, Microsoft stopped shipping DVDs with there MSDN library Windows programming documentation about 8 years ago.  The documentation and examples are online only.   The reasons for this trend are obvious. 

FWIW, I believe there is a plan to place WinBatch documentation online at some point down the road.  Although the help file version will likely still ship with the product.  I also believe there are plans to reorganize the Tech Database and improve its search capabilities.  But that is wandering off topic.

With regard to point2, you are incorrect on several points.   You absolutely do not need to copy source every time you use it.  If you wish to use the library model, simply use the "include" statement to, well,  include  the file or files containing the  library or libraries.  So you only need to copy the source exactly once.  You can place the file anywhere on your file system or network that you have read access to.  From the documentation for the "include" command, "The file name may contain path information."   

Considering pressing ctrl+c then ctrl+v an onerous  burden may be a first on this forum.
 
Finally, if you find AutoIt  a great product then by all means use it.   The AutoIt forum is a fine place to post questions, and search for answers and examples related to that product.  This forum is for and about Wilson WindowWare software.