Winapi, someone else's application - problems with menus and windows being drawn only on mouseover?

Question

C++ / C#

Good afternoon,
My operating system is Windows 8.1, there is an application that is written in Java \ SWT, there is no access to source codes.
I need to do some automation, I do it through winapi calls.
The program is launched separately , not through CreateProcess from the program that does the automation (I don't know if this affects anything).
The program must be in the background , that is, the focus is on another window that has nothing to do with it.
Question 1:
The main menu, where File, Help I search through the GetMenu call - finds it perfectly, every time.
Then I call GetSubMenu and GetMenuItemID respectively to find the menu item.
The problem is just this. GetMenuItemID returns FFFFFFF - that is, it does not find the menu item until you click on a menu item such as File in the program itself to open a list of submenus.
As soon as you press, the list of submenus will open - it finds it normally until the program is idle for a while - then again the submenu disappears and issues FFFFFFF.
I tried many different commands to send to the program, but without success.
How can you reinitialize the menu so that you don't have to click to initialize it each time?
Question 2:
The application is in the background, the focus is on another window.
When clicking on menu items via SendMessage, a dialog should open with the class "#32770 (Dialog box)"
The problem is that sometimes it happens that dialog boxes don't open until... you move your mouse over the window area.
I'm testing from the console, the console is on top of the program window, the mouse is on the console. And exactly at the moment when the mouse is hovering over the back window (it's just hovering, without clicking and activating), all dialog boxes begin to be drawn ...
If you do SetForegroundWindow, then everything seems to be drawn normally, but then the window becomes active, but you need to to have it in the background.
Question 3:
How can I detect that the "#32770 (Dialog box)" dialog box has opened? I search the Internet for a long time, but almost all methods are just every N milliseconds to look for a window, and then do Sleep.
Question 4:
Why does the program work differently on different computers, all with Windows 8.1?
On some computers, SetForegroundWindow makes the window active, that is, the window pops up in the foreground.
On others, SetForegroundWindow is not made active, the program icon in the taskbar starts flashing, but the window does not pop up to the foreground.
Sometimes it finds a submenu item via GetMenuItemID, and sometimes it categorically refuses, even if the submenu is activated via a click.
Thank you.

Answer 1

Answer to question 4:
When the trees were small, and Windows just appeared, there was a SetActiveWindow function that made the selected window active - threw it to the fore. But programmers liked to make their windows always active and called this function too often, sometimes the system went into a carousel of active windows. To prevent this, the Windows API introduced the SetForegroundWindow function, which works almost the same, but in the case of frequent calls, the windows stop switching, but only start blinking in the taskbar. This is not a feature of computers or programs - this is an internal kitchen. If the system decides that you are switching too often, it will simply start flashing the buttons.
Waiting for the window to appear - in a loop, on a timer. There is nothing terrible in this. If desired, this can be organized in a separate thread.
In addition, there are complex methods of injecting code into the program, related to application hooks or interception of function calls, but I do not think that your task requires such a complex intervention.
Apparently the program has an event loop implemented in such a way that your SendMessage will not be processed until real events arrive - MOUSE_MOVE, for example. Or the dialog needs the current active window. Or many other similar reasons. Maybe before SendMessage another event should come.
In most cases, to simulate actions, you need the window to be active. If the window is not active, then the simulation may or may not work equally.
Most likely the menus are dynamic and are created by mouse clicks and menu opening. Therefore, you have no choice but to consistently simulate clicking on the File menu, running through the menu items, and selecting the desired menu item - so that the internal mechanisms for creating submenus work out.