2

Problem

I am trying to differentiate these google chrome processes from one another via there main window title. I know that some google chrome processes are processes that run within the background with no window, and therefore should return a main window title of an empty string. But, I can't make sense of why processes that are specifically windows are also returning empty strings as output onto my console when they clearly have a main window title.

Research

I have done some research about some of the possible reasons these other window related processes are returning empty strings at https://msdn.microsoft.com/en-us/library/system.diagnostics.process.mainwindowtitle%28v=vs.110%29.aspx , but am unsure if the remarks section of the website applies to my situation.

Here are the remarks section from the website

A process has a main window associated with it only if the process has a graphical interface. If the associated process does not have a main window (so that MainWindowHandle is zero), MainWindowTitle is an empty string (""). If you have just started a process and want to use its main window title, consider using the WaitForInputIdle method to allow the process to finish starting, ensuring that the main window handle has been created. Otherwise, the system throws an exception.

The main window is the window that currently has the focus; note that this might not be the primary window for the process. You must use the Refresh method to refresh the Process object to get the current main window handle if it has changed. Win98WinMe

My Case

To save everyone's time, I won't go into too much detail about what my application is trying to accomplish, besides that my goal at the moment is to further differentiate process ID's that happen to have the same process name.

For example,

EmptyStringsOnGoogleChrome

And here's the code

// Get all instances of Chrome running on the local computer.
// This will return an empty array if Chrome isn't running.
array<Process^>^localByName = Process::GetProcessesByName("chrome");

// Print out each individual processes Process Name, ID, and Window Title
for each (Process^ p in localByName)
{
    Console::WriteLine("Process: {0} ID: {1}, Main window title: {2} ", p->ProcessName, p->Id, p->MainWindowTitle);
}

Questions

  1. Can someone identify if the reason why I'm getting empty strings is related to how MainWindowTitle variable works, or if it has to do with the OS, or something else?
  2. Are there alternatives to getting all of the MainWindowTitle's for each of my Chrome processes?
  3. This question is kind of a mesh of question 1 and question 2, but I would really appreciate if someone can explain why the google chrome process that is active is the only case where it prints out a non-empty string. Live examples provided below

Example 1 : NFL.com active

enter image description here

Example 2 : Google.com active

enter image description here

Application Environment

OS : Windows 8.1

Programming Language : C++

IDE : Microsoft Visual Studio 2012

  • I think you are confusing the tab text with window title. My guess is chrome is settings it's main window title to the active tab so it shows in the task bar. – 001 Jan 07 '16 at 21:07
  • Johnny is right -- there is only one "chrome main window" in your screenshot. The three tabs inside this window are totally under chrome's internal control and have no connection with the Process/MainWindowTitle API you are using. – ThorngardSO Jan 07 '16 at 21:14
  • @ThorngardSO How would I go about working within Google Chrome's API? I have tried to work with Google Chrome's API, but it seems like it is something that you have to work within the browser in order to accomplish (AKA Developer Mode in Chrome). I have thought about creating a javascript script that handles the browser side of things and send this information to my C++ script, but Chrome's API isn't something that can be downloaded and installed onto your computer. So my question i guess is how would i go about accomplishing the task I want under the assumption that processes might not work? – Diego Holguin Jan 07 '16 at 21:22
  • @DiegoHolguin That's a good question :-) According to this thread http://stackoverflow.com/questions/19364189/instantiate-chrome-object-in-powershell chrome does not offer a COM-API like the InternetExplorer, which would allow for such queries/interaction. So that road is blocked. I don't have any experience with chrome otherwise... – ThorngardSO Jan 07 '16 at 21:36
  • @DiegoHolguin This post here is also interesting: http://stackoverflow.com/questions/28477479/chrome-net-ui-automation-automatic-sign-on-to-browser-automationelement-inv Keywords: Inspect.exe from some windows sdk, and the Windows UI-Automation/Accessibility framework. – ThorngardSO Jan 07 '16 at 21:51
  • @ThorngardSO Thanks for the feedback, I'll check them out and see if i can dig up any information. – Diego Holguin Jan 08 '16 at 03:00

0 Answers0