With the my having to rewrite the UI I decided to redo the List of Active Windows window. So, I spent the last 24 hours working on it.
The first thing I did was replaced the ListBox component used by AC Tool to display the list of Active Windows/Processes. With a StringGrid component. This made the display of the Window/Process list better and allowed for the use of column titles. But, the standard StringGrid component in Delphi is unable to sort the what you have in the component's grid array. Which means the list of Windows/Processes is shown with the WIndows/Processes in the order that they were added. So, I had to add code to sort the list. By default all of the sorting done is done in the descending order And the list is initially created and then sorted based on the entries in the Title column.
I also wanted the user to be able to change the sorting of the list based on the column they wish to use, either the Title or PID column. But, the standard StringGrid component in Delphi, or a most of the free StringGrid components derived from the standard one, are unable to acknowledge the fact that the user is clicking on the Column Title/Header. In order to run the process to sort the list, I was looking at have to derive my own version of StringGrid to add in the that ability. But, I had found that in the JEDI JVCL component package there was a StringGrid component that did work as I needed. So, I switched to the JvStringGrid component. And I was able to get the sorting of the list based on user selected column, again only in descending order, to work.
The next thing I wanted to work on was the list itself. In Divide, and sometimes in AC Tool, the list that is given to you is a list of all the Windows/Processes that windows sees. And for the most part this is a good thing. But the problem was that for many of the items in the list. There were Windows/Processes that had no Title/Caption. But they did have a PID number. And for some of the other items in the list. They were just components being used within a UI of some other application's UI. Such as a button or a label and as such really are not a window. And even some other items are Windows/Processes that are not even visible to the user. Or is just a process that does not have a window.
The list really didn't need to have all those items. At least not for what Divide, and AC Tool, are mainly used for. So, I adjusted the code I wrote to not add those items to the list.
Then I started doing a lot of testing and I have found many of the Windows/Processes listed. Are nothing more than Child window/process of another window/process. Or is a main Window/Process but is Owned by another window/process. Or are Windows for applications that are considered to be tools.
And I had come up with a way to display a list without all those windows/processes too. But, I also added the ability for the user to include those Windows/Processes in the list if they so choose. They can choose any one of them or any combination of them.
So, by default the windows behavior will be to display all Windows/Process that are not owned by another window/process. that does not have another window/process as a parent, and is not Tool window. And the user is able to change that behavior of that listing.
* NOTE: a window/process that is owned by another window/process and a window/process that has a parent window/process are not necessarily the same thing.
Also Note that not all application's window/process Titles will match that of the window that you are looking at. This is cause by the developer of the application not setting the application's Title properly. For some applications the developer used code that would set the application Title one way. And then set the application's Window caption to something else.
Example: AC Tool
In AC Tool, Cam or someone else, had originally used the following code:
procedure TfrmMain.SetCaption(sFile: String);
if ExtractFileName(sFile) = sFile then
s := GetExePath + sFile
s := sFile;
Application.Title := sTitle + ' - ' + ExtractFileName(s);
Caption := sTitle + ' - ' + s;
This procedure/method is called every time a macro/script file is loaded, or when a new macro/script is created and/or saved.
Basically it gets the macro/script file, including the full path to the file, and then uses it for the applications's Title and the application's Window caption.
To illustrate this, run AC Tool and load the Alchemy Ahead.mac macro/script file.
In the case of AC Tool and the above procedure, the application title is being set to:
AC Tool 5.4.0 - Alchemy AHead.mac
While the application's Window caption is being set to:
AC Tool 5.4.0 - C:\AC Tool\Macros\Alchemy AHead.mac
Or what ever the path is for you.
Ideally the application's Title and the application's Window caption should be the same. But, many developers in the past made the above mistake and have the two being different.
And then there is this behavior that I had found. In some applications child windows have a window caption of one thing and is shown in the window list as having something else.
Example: AC Tool
With AC Tool running and have the script Alchemy AHead.mac script file loaded.
From the Main Menu select Tools and then Window List. The Window List window will be displayed and will have the the caption of:
List Of Active Windows.
But, in the list that is being displayed to you. You have the two AC Tool entries:
AC Tool 5.4.0 - Alchemy AHead.mac
AC Tool 5.4.0 - C:\AC Tool\Macros\Alcemy AHead.mac
And there is not entry for the List of Active Windows window. WTF, if AC Tool display all windows/processes then why the List of Active Windows window not shown? OH, but it is.
The "AC Tool 5.4.0 - Alchemy AHead.Mac" is the application. And the "AC Tool 5.4.0 - C:\AC Tool\Macros\Alcemy AHead.mac" is the List of Active Windows window, (You just would not notice it unless you are looking at it from Divide and seeing the second one disappear when you close that window.)
At first I had thought this was because of some improper coding for the displaying of the child window in AC Tool. But, after checking the code I have found that there is nothing wrong with it. And to make it more mysterious, in newer versions of Delphi programming (XE and newer) this behavior is not seen, well at least it is not seen in my various tests. So, I can only assume it is a but in the earlier versions of the Delphi compiler. One that may still be present in newer versions. But, just has not shown itself in my testing.
With this in mind, I can only tell the users of AC Tool, and eventually Divide, to be careful of what windows/processes that are trying to use and what their names are.
For the first problem, the Title being different from the Caption, this can be compensated by adjusting what is displayed in the list. But, not always. And as for the second, watching the list for changes as you use the application and it's child windows to know what the actual child window title/caption is.
And none of this will have any effect on the SetActiveWindow command.
I have attached a file to this post. It is a Demo of the new List of Active Windows in Divide. Give it a try.