Descriptive Problem Summary:
The screenshot (F2) dialog doesn't hold keyboard focus properly anymore. When attempting to type in the file name input the interface's default input control will keep fighting with the dialog for focus resulting in half of what you type going into the input control and half going into the dialog's input.
Numbered Steps to Reproduce Problem:
1) Take a screenshot by pressing F2.
2) Get super annoyed as you try to name the image something else.
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
The dialog to hold keyboard focus until it's closed.
Actual Results:
The dialog fights with the game's interface for focus.
Does the problem occur:
Every time? Or how often? Every time.
In other games? I'm not sure if it's limited to projects effected by the input bugs we've had fixed over the last few builds, but my test project for those does show this.
In other user accounts? Yep
On other computers? Yep
When does the problem NOT occur?
Unsure, I'm pretty limited on what I can do with this netbook so I couldn't do much heavy testing.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Works in 510, not able to easily test other 511 builds, sorry.
Workarounds:
Unknown.
ID:2234623
 Apr 9 2017, 8:45 pm
|
|||||||||||||
Resolved
| |||||||||||||
|
Apr 12 2017, 2:45 pm
|
|
Lummox JR
  |
I tried to test this but my screenshot dialog is modal; input isn't allowed to steal focus from it. The code confirms this to be true.
|
Lummox JR changed status to 'Unverified'
| |
It happens consistently for me while playing Eternia and running the input bug test I sent you previously.
 That's what happened when I tried typing "tryingtonamethisimage" into the file name box. Should be noted that I'm opening the dialog by right-clicking the titlebar and selecting screenshot from the menu that's under the "Client" menu. | |
I'm not able to reproduce this in your project either, whether the input is a default or not.
Is there anything on your system that's possibly interfering here? It shouldn't be possible for an input control to steal focus from a modal dialog unless something is trying to force it. | |
Can confirm this is a thing. Happens all the time when using the following code:
mob/verb/buildiconfromunderlay(icon/b as icon|null) Every 2-3 characters entered into the popup dialog, the input steals focus. System OS is Windows 7 Professional 64-bit. | |
Try changing the interface's input's 'default' from true to false.
| |
FKI, can you throw together a test for me? I'd like to be sure I'm on exactly the same page.
Also I should point out the icon popup is modeless, unlike the screenshot dialog. | |
I spoke too soon; changing the only input's "default" to false didn't help.
Download test case: https://www.dropbox.com/s/s4tvfikqs9461sj/ Test%20Environment.rar?dl=0 Run the project, use the "test" verb, spam a key(s) and observe the input (below the map). You should see the occasional key press sneak into the input. I also just discovered the new file manager doesn't seem to work as far as new uploads go. I removed my previous upload of a test case. Then I tried drag-and-dropping the new file to upload it, and nothing happened. I also tried selecting the file using the file menu, still nothing happened. | |
I just re-tested uploads and had no issue. What browser are you using? And if you open up developer tools and inspect network activity, do you see evidence of the upload?
| |
Google Chrome is the browser.
Some errors that popped up: member-files Failed to load resource: the server responded with a status of 500 (Internal Server Error) The second appears consistently as I attempt an upload. | |
I fixed the upload issue you were having, but we have a different problem. Your test case is not a simple one and includes NullQuery's common operations library with the .dll. I'm not going to run that as a test. I need something simpler than that. Please pare it down.
| |
Must have uploaded an old archive.
Here you go. Run the project, use the "test" verb, spam one or multiple keys and observe the input (bottom left). I've noticed it's much less frequent in a simple project as opposed to my game project, but nonetheless. | |
Lummox JR resolved issue with message:
Input controls could sometimes steal control from a popup dialog (e.g. file selection). | |
I found the problem. The issue in brief was that the mechanism for an input to grab focus normally is called during regular message processing, but in certain situations the timer will try to clear out a bunch of waiting messages, which causes this to be processed at a weird time. The WM_CHAR message meant for the popup is seen as likely belonging to an input instead.
I added sanity checks for WM_CHAR and WM_KEYDOWN to avoid any special behavior when the focus is in a popup that isn't one of the interface windows. | |
Thanks for helping me narrow that down for Lummox, FKI. Being stuck on this terrible computer and unable to do things like that easily are driving me insane.
And of course, thanks for fixing it, Lummox. :) | |