I suggest using the Perl instead of the legacy UltraEdit regular expression engine for searching for strings to display in the Function List view. The Perl regular expression engine is much more powerful and there are supported multiple capturing groups within a search expression. The strings found by the expressions inside the capturing groups are concatenated by UltraEdit to one string to display in the Function List with a space between the strings from the capturing groups.

Example:
The first Perl regular expression results in getting displayed in the group Tool Call just the string CUTTER 12 for the posted example.

There could be also displayed in the Function List the string 74 CUTTER 12, i.e. line number a single space and the string in double quotes found in the file with the double quotes not displayed in the view. That would require just adding ( and ) around the expression matching the line number as shown below.
74 TOOL CALL GUTTER 12 would be displayed in the Function List view with:
The second Perl regular expression would find for the Function List for the posted example:
Modify [0-9]+ to ([0-9]+) for getting also the line number displayed in the view.

(?:…) is in Perl regular expression syntax a non-capturing group as used in the first search expression for an OR expression.

I suggest having the syntax highlighted file and the syntax highlighting wordfile opened in same instance of UltraEdit. After making a change in the syntax highlighting wordfile and saving it, switch to the syntax highlighted file, right click into the Function List view and click on context menu item Refresh function list. That triggers a new function list search with the expressions in just saved wordfile and the view is updated with the found strings.

There is in context menu of the Function List view also the menu item Sort list to get the found strings either listed in the order as found in the file or sorted in alphabetical order (not in alphanumeric order). It is most likely better having the Sort list option toggled off on listing the strings with line number in the function list.

Sorry, I should not write a reply late in the evening after 13 hours of work on computer. I made some mistakes.

I wrote to use ([0-9]+) for capturing the line numbers but used ([0-9])+ in two examples with the multiplier + outside the capturing group causing just one digit being captured and listed in the function list instead of the entire line number. I corrected that mistakes in my previous post.

I thought, it is possible to use an OR expression with a capturing group for the entire first expression matching the number after TOOL CALL and a second group for a part of the second expression matching just the string between the double quotes after TOOL CALL without the double quotes. That results in first capturing returning no string to UltraEdit on a TOOL CALL with a double quoted string which results in an undefined behavior of UltraEdit. The function list is weird filled in this case. It is necessary to use two search expressions, one for TOOL CALL followed by a number and another one for TOOL CALL followed by a string in double quotes.

It is just necessary to move ( of the capturing group to the left in the search expression for the function group Other to get captured also the whitespaces after * - and listed them in the function list too.

Here is the updated function string definition block for the wordfile:
The first search expression should be deleted if there is never a TOOL CALL followed by a number instead of a double quoted string in any syntax highlighted file as in this case the first expression is useless and just wastes CPU power for searching in files for a string never existing in the files.

The expressions above result in an alphabetic sorted function list for the attached file as follows:

Tool Call
Other

There could be used for a hierarchical function list the following find strings definition:
For each TOOL CALL found in the active file is searched next in the block from this TOOL CALL to either next TOOL CALL OR end of file referenced with \z for a line with a line number and * - and exactly three normal spaces and listing everything after the three spaces on these lines in the subgroup Other of the current TOOL CALL. There should be of course used a better name for the inner function strings than Other.

The function list can be sorted alphabetically or unsorted on using this function string definition.

More simple is:
This produces a flat function list. But in this case the option Sort list must be toggled off in the context menu of the Function List view as otherwise it is not visible which string after * - and exactly three spaces belongs to which TOOL CALL block.

The UltraEdit regular expression %*^{[^}^{[^} is not good although it looks like it worked somehow for you. It means start each search at the beginning of a line, find zero or more characters except newline characters non-greedy followed by an opening square bracket OR an opening square bracket. The OR expression ^{…^}^{…^} makes no sense on specifying twice the same string. Another issue here is that [ is also in UltraEdit syntax the beginning of a character class definition and needs to be escaped with ^ for being interpreted as literal character. I am really wondering that you get strings in the function list displayed with that UltraEdit regular expression at all as when I run it manually from the Find and Replace dialog window, it does not find the lines as shown on the attached image at all.

There can be used in Perl syntax the following to find any string within the first pair of opening and closing square brackets on a line.
The escape character in a Unix/Perl regular expression is \ instead of ^ as in an UltraEdit regular expression. The character [ is interpreted as beginning of a character class definition, except it is escaped with \ to be interpreted literally or the opening square bracket is used inside a character class definition like the first character class definition in the search expression above. The character ] is interpreted literally by default, except a character class definition is opened where it marks the end of the character class definition.The character ] must be escaped with \ if this character should be one of the characters of the character class definition.

The expression must be read as follows:

^ … start each search at the beginning of a line.

[^…] … that is a negative character class definition because of ^ after the opening square bracket beginning the character class definition to find a character which is NOT one of the characters defined next.

\r\n[ … There should be found a character which is NOT a carriage return, NOT a line feed and NOT an opening square bracket.

There is applied to the negative character class definition the multiplier * which means zero or more times (greedy which is not relevant here). So the first negative character class definition with multiplier * matches zero or more characters in a line up to either finding an opening square bracket or a new line character or reaching the end of the file.

\[ … there must be found next literally the character [ for a positive find. If there is a newline character like carriage return or line feed or the end of the file is reached, the find is negative for this line resulting in stopping the search for this line and ignoring the line without an opening square bracket.

( … begins the capturing group to define which part of the entire found string should be displayed in the function list. The opening round bracket can be moved left to \[ to get the opening square bracket also displayed in the function list as with the function string definition below.
 
[^\r\n\]]+ … is again a negative character class definition to find a character which is NOT a carriage return, NOT a line feed and NOT a closing square bracket (instead of an opening square bracket) with the multiplier + for one or more such characters. In other words a line with [] as first square brackets pair with no characters between the two square brackets is ignored as the entire expression is not positive for such a line.

) … ends the capturing group to define which part of the entire found string should be displayed in the function list. The closing round bracket can be moved right to \] to get the closing square bracket also displayed in the function list as with the function string definition below.

There must be found next ] for a positive match. A line with having just [ but no ] is ignored for that reason.

The function string definition with the square brackets also displayed in the function list is:
Well, easier to read and also working is:
.*? … matches any character except newline characters zero or more times non-greedy. This expression matches also all characters (from the beginning of a line) up to first occurrence of [ specified next in the expression.

.+? … matches any character except newline characters one or more times non-greedy. This expression matches also all characters (after [) up to first occurrence of ] specified next in the expression.

The function string definition with the square brackets also displayed in the function list.
Which of the four variants is used is up to you. They all find the same string without or with the square brackets for the function list.

Last, a special hint: Save a screenshot showing text as PNG or WEBP image. Both are supported by web browsers and many other applications (especially PNG) and use a lossless compression producing for a screenshot nevertheless a much smaller file than the JPG image format.

Please attach a file or add to your post a code block with lines to find and also some lines to ignore. It is impossible for UltraEdit to apply a regular expression on binary data of an image. I do not want to type text manually what you have in text form but share with us in graphic form.

Hint: Replace the multiplier * by + and lines with [ at beginning of the line are ignored as now there must be other characters left to first opening square bracket. There could be inserted also , left to \[ to get a positive match only if there is a comma left to the opening square bracket on using one of the two easier expressions using .+?.

PS: DeepL can be used for free translation of text from English to German and from German to English.

This function string definition lists all strings in first square brackets except those at the beginning of the line.
This definition lists all strings in first square brackets beginning with DEFINE or MYDEFINE.
The above definition can be extended to get displayed in a second group also strings in square brackets beginning with #.
Here is one more definition for additionally including the groups.

[…] is a character class definition to find one of the characters defined inside the square brackets. [<<] does not make sense as it defines a character class with specifying twice the same character and means therefore find one < or one <. That is not wanted. There should be found the string <<. A character class definition with a single character like [:] makes also no sense as in this case a character class is not necessary at all. The character to find can be specified directly in the search expression without the square brackets for a character class definition. [<<P1>] is also wrong as you do not want to find one < or one < or one P or one 1 or one > but the entire string.

The solution for the function list group Function Oper is:
The Perl regular expression means:

1. Find anywhere within a line a string beginning with <<.
2. (?:…) defines a non-marking group. The expression inside this non-marking group is P[0-9]+> which means to find the character P, followed by a digit in range 0 to 9 one or more times because of the multiplier + applied to the character class definition to find an entire number and not just one digit of the number, followed by the character > and a space character. There is with ? a multiplier applied on the entire non-marking group which tells the Perl regular expression engine that the expression inside the non-marking group must match after << a string either zero or one times. The multiplier ? after a non-marking group or a character class is for that reason often also name the optional multiplier because of the string or character matched by the preceding expression or character class can but must not exist in the entire matched string. In other words "P1> " or "P5832> " may optionally exist after <<.
3. [0-9]+: matches a number with one or more digits and there must be next a colon.
4. .*$ matches zero or more occurrences of any character except newline characters up to end of the line. $ is an anchor for end of line not matching (selecting) any character.

The entire matched string is enclosed with (…) in a marking group to get the entire matched string beginning from << to end of the line displayed in the function list.
The expression searches therefore for << anywhere in the file followed optionally by P and a number with one or more digits and > and a space before next must be found a number with one or more digits and a colon and matched are additionally all other characters up to end of the line.

The second wanted function string expression is:

1. ^ instructs the Perl regular expression to begin each search at the beginning of a line and not anywhere inside the file.
2. (…) defines again a marking group just to get the entire found line displayed in the function list.
3. .*? matches any character except newline character zero or more times non-greedy. In this case ? after the multiplier * (or the multiplier +) does not mean zero or one times as after a non-marking group or a character class but non-greedy matching behavior. The question mark has many different meanings in a Perl regular expression depending on what is left to the question mark. Non-greedy means that matching any characters except newline characters zero or more times should stop on first occurrence of the string which must be found next which is in this case the string (OP:. The default matching behavior of .* without ? would be to match first as much characters as possible including also multiple occurrences of (OP: which means always everything from the beginning of a line up to the end of the line as just the newline characters are not matched by . and then go back in the already matched character sequence (=line) and search for last occurrence of (OP:. The greedy matching behavior would not be optimal here as it would result in first always matching each line entirely and then search in each line back for (OP: to determine if the entire expression is positive on the line or negative as not containing (OP: at all.
4. There must be found in the line the string (OP: whereby the opening round bracket must be escaped with a backslash to be interpreted as normal character without its special meaning in a Perl regular expression.
5. .* matches now greedy after the string (OP: all other characters in the line up to end of the line.

The entire expression is for finding an entire line containing the string (OP: anywhere inside the line.