[FIXED] Problems with Jump to File

[OldPaprika]

I have serious problems with Jump to file, which I use a lot so this makes the program unfortunately unusable to me. I think this started one or two public preview releases back.

Issue: Just whenever I use 'Jump to file', select a file and press enter or double click there is a ~75% risk that WACUP visuals freeze, I hear the song play but all windows are frozen. And after a few seconds it releases, but then it switches to the next track (as if I had pressed Next track). There is also a ~50% chance when this occurs that WACUP does not recover at all and the freeze is permanent (the track is still played in the background though), the process then needs to be killed.

I've tested a bunch of things to help you narrow down the issue.
- I get it with latest version (1.99.51.24568) x64 AND latest x86 as well
- just did a clean install ('Full experience') and wiped AppData\Roaming\WACUP\ so all settings where default, still have the issue
- In the Jump to File window, if I press the button "Jump to file" instead of pressing enter/double clicking I experience no issue

[dro]

Have you applied the post-release updates to 24568? And if the process enters a hung state that requires you to force kill it, you need to get a process dmp via task manager, compress it & send it to me as I otherwise cannot replicate & so cannot attempt to fix.

[OldPaprika]

I have applied the post release update ("Build data Jun 29 2026").

I have created a dump and sent it to you in a DM.

[dro]

For those following along, there's now post-release updates for the jtfe & in_wave plug-ins with build 24568 which fixes the 2 aspects behind the issue reported.

The main problem was with how the search control dealt with the enter / return key action when the search box was focused due to an old core bug related to keyboard navigation in dialog windows that had already been resolved a while back but the jtfe plug-in hadn't been updated to avoid having to do some of the manual reprocessing it was doing to workaround that issue. It meant it was causing duplicate quick stop+play actions which could cause either a main UI thread deadlock or it hitting a timeout within in_wave's playback stopping handling. tl;dr: having less code fixed the problem.