5 ms·
Pressing the arrow keys on their own does nothing, but pressing DEL (no title update) then an arrow key does.
by thesuitonym 6y ago
Pressing the arrow keys on their own does nothing, but pressing DEL (no title update) then an arrow key does.
- tyingq 6y agoHuh (confirmed), trying to imagine that code path. Edit: Played around a bit, it's odd. For example <del> then click on a different window (release focus) does trigger the update.
- beaconstudios 6y agoif(key !== KEY_DELETE) { testForChanges(); }
- sova 6y agoprobably a range on the numerical index of the keys, non?
- beaconstudios 6y agoYeah I don't think that will literally be the code, but that's the outcome. Something like a range, or the del key being handled separately, I would assume.
- jan_Inkepa 6y agoIt checks for updates when you press the arrow keys, but not delete?
- tyingq 6y agoRight. Trying to understand why you would check for an update for a key that doesn't change data and not check for one that does. It also checks when the window loses focus, so <del><click somewhere else> works.
- jan_Inkepa 6y agoIf I absolutely had to guess, it'd be that there's an early out/special code path for the delete key where they forgot to add the "checkupdate" before the break/return/whatever ^^
- anothermoron 6y agoAs I commented somewhere else, I think it's related to the caret moving not the keypress. Deleting a letter doesn't move the caret but using an arrow does, but not if you use, for example, the right arrow key while being at the end of a line, in that case the title doesn't update. Somebody else commented that using delete on a newline changes the title and in that case the delete forces the caret to move.
- veltas 6y agoI think the point is that the arrow keys update the status, if a change has indeed occurred, and delete key does not update status but does change the text.
- banana_giraffe 6y agoJust looking at the messages received, it looks like they're triggering off a few different things to fall into the code path that looks for changes (the missing numbers are due to me deleting uninteresting messages): <00133> 002A1272 P WM_KEYDOWN nVirtKey:VK_DELETE cRepeat:1 ScanCode:53 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 <00150> 002A1272 S EM_POSFROMCHAR wCharIndex:0 <00152> 004E0A18 S WM_COMMAND wNotifyCode:EN_CHANGE wID:15 hwndCtl:002A1272 <00154> 002A1272 P WM_KEYUP nVirtKey:VK_DELETE cRepeat:1 ScanCode:53 fExtended:1 fAltDown:0 fRepeat:1 fUp:1 <00155> 002A1272 P WM_KEYDOWN nVirtKey:VK_RIGHT cRepeat:1 ScanCode:4D fExtended:1 fAltDown:0 fRepeat:0 fUp:0 <00174> 002A1272 S EM_POSFROMCHAR wCharIndex:1 <00182> 002A1272 S EM_GETMODIFY <00184> 004E0A18 S WM_SETTEXT lpsz:02EDCAF8 ("*Example.txt- Notepad") The one that seems to get triggered the most, indeed the one triggering it here, is the code path that also updates the position indicator, hence why Del isn't doing anything. Interestingly enough, they seem to be ignoring the EN_CHANGE message, and instead looking for changes explicitly after some events. Given the long history of Notepad, I'm sure there's some historical reason for that. They do seem to be covering the bases checking for changes before anything that might lose data, like any path I can find to close the window, so it's a minor bug. They also check for changes on each and every mouse move message, so I think for most users, this state won't last long.
- tyingq 6y agoAh, yes...that's what I was getting at. Notepad is mostly a wrapper around a rich edit control, and rich edit controls already emit "EN_CHANGE" when the content changes. So I suppose this must be some historical thing where an earlier version of notepad didn't have something like that to tee into.
- Stratoscope 6y agoNotepad is a wrapper around a plain text control. WordPad is a wrapper around a rich text control.
- tyingq 6y agoAh, yes, thanks. Though it's still the same EN_CHANGE event.