Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Accept background input" Does not work with Lua Console / Lua Scripts #671

Closed
weatherton opened this issue Jul 23, 2016 · 7 comments
Closed
Labels
App: EmuHawk Relating to EmuHawk frontend Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) Tool: Lua Console Relating to the Lua Console (not EmuHawk's Lua API) Working as intended (wontfix) Intended behaviour perceived as a bug, or an unreasonable feature request

Comments

@weatherton
Copy link

weatherton commented Jul 23, 2016

AcceptBackgroundInput_Test.zip

What steps will reproduce the problem?

  1. Open BizHawk, Tools -> Config -> Customize -> Check "Accept background input"
  2. Open a ROM and then switch focus to another application and hit frame advance hotkey and note that BizHawk does still respond
  3. Open the Lua Console and keep focus on the console, hit frame advance hotkey. BizHawk does not respond
  4. Run any Lua script that creates a window (example attached) and keep focus on the window, hit frame advance hotkey. BizHawk does not respond

What is the expected output? What do you see instead?
Expected: BizHawk would respond to input when focus is on Lua Console or Lua Script
(Ideally there would even be an option to "Accept background input from any BizHawk-generated window" or something to that effect. But at least it would be good to have the current option function across BizHawk generated windows.
Actual: BizHawk does not respond to input when focus is on Lua Console or Lua Script

What version of the product are you using? On what operating system?
Emuhawk 1.11.6 on Windows 10

@adelikat
Copy link
Contributor

adelikat commented Nov 9, 2016

I dont' think it should be expected at all that "Accept background input" works on tool dialogs of bizhawk itself. Each tool has to decide to accept mainform input. Tools like tastudio do this (and it is a very tricky thing to consider). If I could edit this ticket I would change it to request mainform input on the lua console and lua created dialogs.

@zeromus zeromus added App: EmuHawk Relating to EmuHawk frontend re: Lua API/scripting Relating to EmuHawk's Lua API (not the Lua Console) labels Jul 10, 2017
@YoshiRulz YoshiRulz added the Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) label Feb 4, 2019
@YoshiRulz
Copy link
Member

Persists in 2.3.1. Easiest "solution" is to change When this is set, the client will receive user input even when focus is lost to When this is set, the client will receive keyboard and controller input when another program is focused, or similar, and close as wontfix.

@YoshiRulz YoshiRulz added this to the 2.4 milestone Apr 30, 2019
@YoshiRulz YoshiRulz added Tool: Lua Console Relating to the Lua Console (not EmuHawk's Lua API) and removed re: Lua API/scripting Relating to EmuHawk's Lua API (not the Lua Console) Priority: Low labels Dec 25, 2019
@YoshiRulz YoshiRulz modified the milestones: 2.5, 2.5.1 Apr 28, 2020
@adelikat adelikat removed this from the 2.5 milestone Jul 5, 2020
@fenhl

This comment was marked as outdated.

@YoshiRulz

This comment was marked as outdated.

@YoshiRulz
Copy link
Member

YoshiRulz commented Nov 21, 2020

The hack has become a feature (as of 7596b97). Have your ext. tool form inherit FormBase and override BlocksInputWhenFocused, like Virtual Pads does (though see #3087 for why this naïve implementation had to be replaced):

public override bool BlocksInputWhenFocused { get; } = false;


Back on-topic, the Lua Console could override BlocksInputWhenFocused with something that returns true when the console textbox, script list, or menu bar is focused, but... that sounds really hard. I think we should wontfix this issue.

@TiKevin83
Copy link
Contributor

Open for 7 years? Yeah let's close wontfix

@YoshiRulz YoshiRulz added Working as intended (wontfix) Intended behaviour perceived as a bug, or an unreasonable feature request and removed Waiting on dev consensus labels Aug 29, 2023
@YoshiRulz
Copy link
Member

YoshiRulz commented Aug 29, 2023

Hotkeys are broken in other ways too, even on Windows... It's just hard to do this right with WinForms. Remember also the mouse isn't passed through (the prop should be BlocksKeyEventsWhenFocused I guess).

I'll be changing the setting's description as above.

@YoshiRulz YoshiRulz closed this as not planned Won't fix, can't repro, duplicate, stale Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
App: EmuHawk Relating to EmuHawk frontend Repro: Affects 2.3/2.3.1/2.3.2 (2.3.3 has its own label) Tool: Lua Console Relating to the Lua Console (not EmuHawk's Lua API) Working as intended (wontfix) Intended behaviour perceived as a bug, or an unreasonable feature request
Projects
None yet
Development

No branches or pull requests

6 participants