Z-Order Issue: "New window" on Ribbon Drop fails to come to front with 1-step delay (OLE Drag&Drop)

[rakunavi]

Hello all,

I have filmed and completely isolated a very specific window activation issue where a newly opened window fails to come to the front correctly (Z-order issue) during OLE Drag & Drop under the "Open each new document in a new window" setting.

Prerequisites / Crucial Step to Reproduce

• Preference: "Open each new document in a new window" option must be ENABLED.
• Drop Target Area: The file must be dropped specifically onto the Ribbon Toolbar area.
  (Note: Dropping onto the document area opens it as a tab, which seems to use a different, working handler).
  • figure.png

Crucial Finding: Focus Scenarios & The "1-Step Delay" Phenomenon

• Through video verification using 4 specific PDF files ("1. Red.pdf", "2. Green.pdf", "3. Blue.pdf", and "4. Yellow.pdf"), I discovered that the visual Z-order update is consistently lagging behind by exactly one file window under specific conditions.
  
  
  • SampleFiles.zip

• Case A: Fails with a 1-Step Delay
  
  
  1. "1. Red.pdf" is already open and its window is active.
  2. Click Windows Explorer to make it active.
  3. Drag and drop "2. Green.pdf" onto the Ribbon of the "1. Red.pdf" window. → The new "2. Green.pdf"
     window opens, but it stays visually BEHIND the "1. Red.pdf" window.
  4. Click Windows Explorer again to make it active.
  5. Drag and drop "3. Blue.pdf" onto the Ribbon of the active window. → Suddenly, the previous "2.
     Green.pdf" window comes to the front, while the new "3. Blue.pdf" window stays behind.
  6. Click Windows Explorer again to make it active.
  7. Drag and drop "4. Yellow.pdf" onto the Ribbon of the active window. → The previous "3. Blue.pdf"
     window comes to the front, while the new "4. Yellow.pdf" window stays behind.
  • Animation1.gif
  • Analysis:
    It appears that the window activation handler (SetForegroundWindow / SetWindowPos) is mistakenly referencing the window handle (HWND) of the previous instance instead of the newly spawned one, or the timing is blocked by the OS due to the drag-source focus switch.
• Case B: Works Perfectly (Direct drag without focusing Explorer)
  
  
  • PDF-XChange Editor remains active.
  • Without clicking Windows Explorer, directly drag a file from a partially visible background Explorer window and drop it onto the Ribbon. → WORKS PERFECTLY EVERY TIME. The new window comes to the front instantly because PDF-XChange already holds the foreground rights, preventing the OS handshake lag.
  • Animation2.gif

Environment Factors Tested

• This race condition is highly triggered by PC performance and rendering load. On a high-performance PC (GMKtec Nucbox M7 Pro powered by AMD Ryzen 9 PRO 6950H), Case A always fails. However, throttling the CPU via UEFI (Disabling Core Performance Boost) or increasing display rendering load (switching to Duplicate Display Mode on lower-end PCs) slows down the window creation just enough for the OS focus to catch up, fixing Case A.

• Alternative Proof via Graphics Load (Tested on GMKtec Nucbox M7 Pro):
  Instead of changing UEFI settings, simply playing a 4K video on YouTube in full-screen mode on one of the secondary displays generates just enough GPU/DWM rendering overhead. This intentional micro-delay acts as a buffer and successfully fixes Case A on the primary display as well, allowing the new window to come to the front perfectly.

The Severe Practical Impact under Maximized Window & Hidden Taskbar Workflows

• This issue becomes extremely frustrating under typical multi-display workflows where the original PDF-XChange Editor window is maximized.
  When a new window opens directly behind a maximized window, it shares the exact same screen coordinates. To the user, it visually appears as if the drag-and-drop action was completely ignored and the file failed to open.
  Furthermore, if the user operates Windows with the "Automatically hide the taskbar" option enabled, there is absolutely zero visual indication on the screen that a new window has spawned. Users are left entirely in the dark, forced to manually bring up the taskbar or open Task Manager just to verify if the file was processed, causing a major disruption to seamless multi-display workflows.

In other applications, such as Microsoft Word, this process always works flawlessly, regardless of PC performance and rendering load. Could the development team please review the Ribbon area's OLE Drag & Drop handler to ensure the newly spawned window's handle is correctly targeted and synchronized for visual activation?

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
Note:
Also, as mentioned in the prerequisites, dropping on the main document area opens a new tab instead of a new window, ignoring the preference. On the other hand, if the “Open each new document in a new window” option is disabled, documents will open in a new tab not only when dropped into the main document area but also when dropped into the Ribbon toolbar area.

• figure.png
  
  
  Animation3.gif

If you double-click a group tab on the Ribbon toolbar or use the F8 key to hide the Ribbon toolbar (including the group tabs), the drop area where you can open files in a new window becomes even smaller. Conversely, the document area—where files are always opened in a new tab when dropped there—ends up taking up almost the entire window.

You may want to review if this is intentional or a separate UI consistency issue.
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

Hoping that the above information will be of some help to you.
Thank you for your hard work on this great software.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 11.0.1
- OS Version: Windows 11 Pro / Home 25H2 Build 26200.8875
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL / HP All-in-One 22-c0xx

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the report, I have escalated it to the Dev team for review!

Kind regards,