Even if that’s true, you still have to find the location of the window. The window could be anywhere on the screen. After all, you want to be able to move the window. When I write macros like this, I like my macro to handle different window locations. In this case, finding the location is as simple as using the token %FrontWindowFrame%. From there, we have to decide which PART of the window to search for the arrows (plus the blocks.) You haven’t shown the entire app’s window, but it sounds to me like it’s on the right side of the window, and always the same width. Right? I could give much better advice if you showed the whole window rather than just the part of the window where the tabs/arrows are.
This sounds important. Are you saying that the frame is a floating/focussable window, and not fixed in the app? This is extremely important, and it would really help if you show us, instead of using paragraphs of text to explain it. It’s hard for me to come up with the correct answer when I can’t see what I’m dealing with. I need to see the app’s entire window to help you find the location of the frame that you are working with.
That’s why I said earlier that you will have to find the location of the window. I need to be able to see the screen in order to give you good advice here.
I can see two different solutions here. One, you can get the mouse to click on the open down arrow, then move the mouse down about 20 pixels, then click on where the next right arrow is (this method assumes there is one, so it may not be the best method.) Two, do another search, using your Find Image action to search ONLY the area directly below the right arrow that you found, and make sure you search for the “topmost” right arrow below the arrow that you already found. That’s what I was trying to explain in my original post. I might have drafted some code for you, but since I can’t see the entire app’s window yet, I can’t draft any code.
For creating the UP macro, you don’t have to search downwards. You just have to move up about 20 pixels for the next right arrow. So upwards is easier, although you MIGHT have to handle the case when the first arrow is the expanded one.
That’s exactly how the Find Image action works. The documentation for the Find Image action will explain how you save it in a variable. I think the problem here may be that you think that Find Image works only as a condition, whereas it actually also is an action. (Even as a condition, it DOES return its value in a token called %FoundImage%. But I don’t recommend that you do that here. Use the action, not the condition.)
In case you didn’t grasp one of my points earlier, I will re-iterate here that you aren’t going to be searching for right arrow, you are going to be searching for the following image. That’s because this is a far more reliable image to search for than a simple right arrow. I can see that all your right arrows have a double box to their right, which is a very helpful situation for you.

The first thing you should probably do is write a macro to test how reliable this search is. If it cannot find the down arrow reliably, then we have to discuss new approaches. I cannot do this testing for you, partly because you haven’t shown the app’s window. If you can do a test like this and tell us if it’s reliably finding the location of the right arrow, it’s a win for us all. But finding the window to do the search is something I can’t help you with until I see the entire app’s window.
P.S. I’m neither the clearest writer nor the smartest person on these forums, but I write macros that use Find Image actions every day, so I’m experienced with this topic. And lately I’m also using a lot of OCR action work, and I can almost see a solution using OCR, or at least in this case, I might use OCR to validate that we have the location of the frame, like this: