ProSelect Dialog issue. it can not be top.

Hello @CHASEONHO, 

Thank you for your question. 
Your question appears to be well documented, however I'd like to recommend to bring more details and context to your initial inquiry. 

It also helps to have screenshot(s) to better understand what you are trying to do in your process. 

This will increase your chances to receive meaningful help from other Community members. 

Regards,

Community Moderation Team.

I don't see a way using official PTC API (TK/OTK). But the following should work (I did not test it yet).
The Windows Taskmanager is probably using same techniques for the functions "Switch to" or "Bring to front", applied to windows (forms/dialogs of processes):

Method A) Use the Win32 API window message system to send a message to the Creo select dialog window that triggers the window to come to the foreground, WM_SHOWWINDOW sounds like it should do it. See https://learn.microsoft.com/en-us/windows/win32/winmsg/window-notifications

Method B): Use Win32 API function SetForegroundWindow() (or similar).

For both methods, the current window handle (of the select dialog) is required: xtop.exe does not have too much windows, so one can assume the window with the title "Select" is our target. Get the list of all windows (handles) of the xtop.exe, for each window: get the window title and take the handle of the matching ("Select") window. Tools like MS Spy++ might help during development.

Microsoft Spy++ showing Creo's Select dialog

Since we do not know when the action of bringing the Creo Select dialog to front is necessary (at least without further examination of the window state), I would do it every ~3..5 seconds (even if it already is in front). To be able to do this parallel to the Creo TOOLKIT application's main flow (which is then blocking in the ProSelect() call), an extra thread is required which only purpose is to bring the Select dialog to front. Create this thread before a call to ProSelect() and terminate it afterwards. (I used extra threads from within synchronous TOOLKIT applications successfully for similar tasks. This is OK as long as the TK/OTK APIs are being called only from one thread and nothing too "fancy" happens there.)

Its not a 3-liner, but sounds feasible.