jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

Filter: Show/hide filter window #922

Closed reaperaccessible closed 1 year ago

reaperaccessible commented 1 year ago

Hi, 2 users have reported to me that the following action no longer works with OSARA in the MIDI editor. Filter: Show/hide filter window... I tested here on 3 machines, indeed, the focus of NVDA no longer goes in the filter window on 2 of the 3 machines tested. All tests were performed with the latest version of Reaper and OSARA on Windows 10. But it works perfectly on one of my 3 PCs, why, no idea. I asked a sighted person and he confirmed that there is no window blocking access or error message on my 2 problem PCs. The filter is well displayed on the screen but the focus of NVDA does not move in the window. I then moved the REAPER.ini file to another location so that Reaper builds a new .ini file and I have exactly the same result on both machines. On the other hand, the machine that works is a machine on which I always have a fresh installation of Reaper. As soon as the new version of Reaper is available, I completely uninstall Reaper and delete all files including those in Roaming folder. This allows me to do tests with a clean installation in order to compare strange behavior. I then tried with a portable version of Reaper and I have the same behavior on both machines. So, I don't know what to do anymore to solve this problem. Any ideas?

Thanks.

jcsteh commented 1 year ago

This focus hack looks for a dialog called "Filter Events". Is that what the dialog is labelled on your system? Do you have a langpack installed that might be altering its name?

Making this support other languages is tricky because we have no guarantee that the user's langpack matches the OSARA language pack.

jcsteh commented 1 year ago

FWIW, it does work for me here.

reaperaccessible commented 1 year ago

Oh! you found the problem, indeed, the only machine which has the good behavior is the one which is configured in English. I activated the French LangPack and I now have the same problem as on the other 2 machines. The window name is ( Filtre d'événements ). Is it possible to add this window name in the OSARA code? Thanks.

ScottChesworth commented 1 year ago

Hmm, adding the window names for every lang pack is kinda messy. Is there some other thing we can check Jamie? An ID that'll stay consistent irrespective of the langpack being used?

RDMurray commented 1 year ago

Failing a better way of identifying the window, `LocalizeString("Filter Events", "midi_DLG_128") should return the window title I think.

jcsteh commented 1 year ago

Is there some other thing we can check Jamie? An ID that'll stay consistent irrespective of the langpack being used?

I was sure we'd discussed this kind of thing with Justin in the past... and I was right. Here was my suggestion to Justin:

Cockos might be able to help here by providing a reliable way to detect specific dialogs, but the approach I have in mind is pretty hacky and very specific to OSARA. They could set a window prop on the dialog HWND (SetProp) with a value indicating which dialog it is.

Justin didn't love that idea:

Perhaps we should add an API:

HWND GetREAPERWindow(const char *name), and allow passing it things such as:

"FXAdd"

"TrackFX:0"

"TrackRecFX:0"

etc, and it would return NULL if the window was not open?

I know it's more work to scan all of the tracks, but it's probably preferable on our side than adding a window property (and would be useful to have in ReaScript)

IMO, his counter-proposal is going to be way too expensive, especially if we start using it for all sorts of things. I guess we can push back on that, but it's rare that Justin pushes back on a proposal from us, so I figure he must have a good reason for doing so.

jcsteh commented 1 year ago

Failing a better way of identifying the window, `LocalizeString("Filter Events", "midi_DLG_128") should return the window title I think.

That's a great idea and probably the easiest solution at this point. I discarded that idea myself because I thought we'd need to do a lot of extra work to access REAPER's localisation framework, since we use our own, but it looks like it's just a matter of requesting the API function in the normal way.