Typing a number in creature split/recruit screen replaces the value instead of appending

[modo-lv]

Fixes #1631.

[Districh-ru]

Hi @modo-lv, could you please fix the code style issue.

[Districh-ru]

Well done, @modo-lv !

[ihhub]

Hi @modo-lv , I left just one very minor suggestion here. Can you please take a look at it?

[ihhub]

We don't use any Doxygen like comments. I suggest to make it simpler:

// "replace" parameter is used to replace the existing value with a newly entered digit rather than appending a new digit.

[modo-lv]

I can change it, of course, but what's the reason for not using doccomments? They allow for quickly checking a function's documentation without having to leave the call site, among other things. I find this feature extremely useful, and wish more people would use it.

[oleg-derevenetz]

They allow for quickly checking a function's documentation without having to leave the call site

Plain comments allow this as well:

But, unlike Doxygen-like comments, plain comments are readable in plaintext viewers and editors (e.g. joe or mcedit) without having to dig through all that XML. Doxygen is good for auto-generating the documentation, but we don't do that anyway.

[modo-lv]

Plain comments allow this as well:

Oh, cool, I didn't know that. I have changed the comment to plain syntax (and added a method summary).

[oleg-derevenetz]

Hi @modo-lv I'm currently thinking about some more extensive modernization of these input fields. For example, they have such a problem that although it is possible to erase the value completely (using the Backspace), this will not be visible. In addition, if, for example, the minimum value for an input field is 20, then it will be very difficult to turn it to 100 by editing - you can erase the value (although this will not be visible), but as soon as 1 is entered, the value will become 20 again. Etc.

[modo-lv]

I agree, the numeric inputs could be better. I think a couple things could really improve it:

• A blinking cursor so that the player knows that he can type, just like in other input fields. This would intuitively let people know to try backspace, which doesn't happen now (I never realized that's what I needed to do, I just tried entering numbers and when it always went to max by pressing 1 I just assumed it was some bug and stopped bothering.)
• Add Delete for fully clearing the input with a single keypress (assuming that the cursor can't move to the left of numbers, where people might expect it to delete the digit on the right).
• Don't apply min/max clamps while the user is typing, only do it when he clicks somewhere else or tries to confirm the number. Alternatively, don't apply clamps at all, but enable/disable the confirmation button (and, of course, the Enter key) depending on whether the number is valid.
• Not directly related to the initial input field, but it would be nice if keyboard worked in the popup numpad as well.

All of these are lot more work though, so I made this PR as a quick-fix for now, to let people with keyboards have a more efficient and less confusing way of quickly typing a number while a full-fledged solution is being worked on.

[oleg-derevenetz]

Hi @modo-lv

Not directly related to the initial input field, but it would be nice if keyboard worked in the popup numpad as well.

I suggest going this way - we will automatically get the keyboard input almost everywhere, even where it did not exist before due to the presence of several input fields in one window at once. Consider:

fheroes2.engine.version_.1.1.7.2025-03-26.16-53-29.mp4

I made the necessary changes immediately as part of this PR for now. @Districh-ru @zenseii what do you think about this approach?

P.S. Please note that the keyboard input is currently available for numeric keyboards only.

[oleg-derevenetz]

Hi @Districh-ru @zenseii I also noticed that, in the recruit dialog, the recruit dialog is closed when I use the Enter key to close the virtual keyboard (but if I press the OKAY button in that virtual keyboard, this doesn't happen). This happens in the master branch as well. Consider:

fheroes2.engine.version_.1.1.7.2025-03-26.17-05-50.mp4

Is this behavior intentional?

[modo-lv]

I suggest going this way - we will automatically get the keyboard input almost everywhere, even where it did not exist before due to the presence of several input fields in one window at once.

I agree, although in windows with only one input field, I would still like it to also be editable directly with a keyboard (or else a keyboard key to open the numeric input, something like Tab or Insert). For players who split and merge their armies frequently, every saved click in that process is a noticeable UX improvement.

[oleg-derevenetz]

I agree, although in windows with only one input field, I would still like it to also be editable directly with a keyboard

In this case, we still face the same numerous issues as we face now. BTW, in the original game you need to click on the input field to enter digits. Also, for certain windows (like the recruit window), we can open the virtual keyboard with an empty value, so the user will be able to save some time by avoiding the "backspacing".

[modo-lv]

In this case, we still face the same numerous issues as we face now.

Yes, good point. It's better that all input fields work the same way, and having the popup numpad is a good solution. A shortcut key for opening it using a keyboard would also be nice, but isn't crucial.

[oleg-derevenetz]

Since the recruiting is a "hot path", I made it so that you didn't have to press Backspace in the corresponding window:

fheroes2.engine.version_.1.1.7.2025-03-26.18-14-45.mp4

A shortcut key for opening it using a keyboard would also be nice, but isn't crucial.

Yes, that's a good idea. But we need to think separately about which windows and under which sauce it can be served. There are multiple windows that support the virtual keyboard, and in some of them you can still enter the value right away (e.g. the "save game" window), so you generally cannot use the "Spacebar" key to open the virtual keyboard, for instance.

[modo-lv]

so you generally cannot use the "Spacebar" key to open the virtual keyboard, for instance.

Yes, I would definitely suggest something that isn't also a typing key. Insert might be a good candidate — it's typing-related without being an actual character key, and is not generally used for anything. It even works semantically (somewhat, at least) — you want to insert some text into the input field, so press the insert key and it opens up a window where you type what you want to insert. It's the closest thing to a "edit" key there is on the standard keyboard, without going into key combinations (something like Ctrl+Space could be an approach as well, but a single key is better I think).

[oleg-derevenetz]

For now, we can use the hotkey just to open the numpad - because, if you need to open the "full" virtual keyboard, you most likely just don't have the "real" keyboard to press the hotkey :) I added the support for this in some windows:

fheroes2.engine.version_.1.1.7.2025-03-26.18-40-10.mp4

I believe, later this can be added to more places (it depends on how many input fields of this type there are in the same window).

without going into key combinations (something like Ctrl+Space could be an approach as well, but a single key is better I think).

Our hotkey config doesn't support the key combinations so far, so I used just the Spacebar button. It doesn't get in the way in these windows.

[Districh-ru]

Hi @oleg-derevenetz, thanks for fixing the Enter key bug for the Recruit dialog, but now it is a bit harder to edit numbers in dialogs with one numeric input field due to the lack of fheroes2::processIntegerValueTyping().
So I prefer the master build, where for example in Battle Only mode when adding a troop I press backspace once and type in the desired number of creatures and press enter once. While in this PR I have to open the virtual keyboard (while I don't need it because I have a real keyboard :) ), press backspace, type in the desired number and press enter twice.
Having a hotkey to open the numeric virtual keyboard looks questionable, since you need a real keyboard to press the hotkey, and if you have the real one, the virtual is not needed.

I suggest to keep all improvements but return back the ability to quick edit numbers in dialog_selectcount and in the Recruit dialog because these dialogs are with a single numeric input field and we can do input there.
Maybe we should add the numeric virtual keyboard to the dialog_selectcount...

[oleg-derevenetz]

Hi @Districh-ru

but now it is a bit harder to edit numbers in dialogs with one numeric input field due to the lack of fheroes2::processIntegerValueTyping().

Now at least you will get what you see, and there is no problem with typing in any number. In addition, the solution with fheroes2::processIntegerValueTyping() is just not viable if there is more than one input in a window.

While in this PR I have to open the virtual keyboard (while I don't need it because I have a real keyboard :) ), press backspace, type in the desired number and press enter twice.

There is no problem to make the same behavior in the Battle Only mode as in the recruit dialog (press the spacebar instead of backspace and get the empty field). You will need just to press spacebar instead of backspace, that's all.

Maybe we should add the numeric virtual keyboard to the dialog_selectcount

??? But it already has the virtual numeric keyboard... You can see it in my videos.

[Districh-ru]

Now at least you will get what you see, and there is no problem with typing in any number. In addition, the solution with fheroes2::processIntegerValueTyping() is just not viable if there is more than one input in a window.

I was talking about dialogs with single input field and in master build it works almost normal. Yes, when you delete all digits it will show the minimum available number (0 for the recruit dialog and 1 for split troops and add troop). But its behavior is maybe not not very obvious, but after a couple of uses it becomes more clear. For the more clear input in the master build a player can click the input field to open a virtual numpad dialog.

And we can try to use the logic from the virtual numpad for these dialogs: allow to enter any number and if it is out of the given limits (or empty) - warn the player on clicking OK. The number are mostly short so there is no need to show the cursor or to position it.

??? But it already has the virtual numeric keyboard... You can see it in my videos.

Not exact - on the videos there is an ability to open a new dialog with a virtual numpad.
Sorry for not clear suggestion. I meant something like this:

[oleg-derevenetz]

@Districh-ru

OK, I moved my changes related to the keyboard support in the virtual numpad to #9690 and reverted my changes here.

I was talking about dialogs with single input field and in master build it works almost normal.

I believe that even if the current implementation of the keyboard input maybe sometimes works "almost normal", it is fundamentally broken in general, as I already mentioned before. I really suggest you try to set in the Dialog::SelectCount() min to 20 and max to 1000 and try to enter the number 100 from the keyboard. You won't be able to do that.

I suggest thinking about how this can be fundamentally fixed rather than introducing an ad-hoc workarounds. I believe that the correctness is important, even if it entails some complication of the UI. In the original game, you need to click on the input field first, then enter the number, then press Enter, and only then you will be able to close the window (even the mouse cursor was hidden during the editing process) - and that was okay, no one died from a few extra actions, but it looked consistent and worked correctly. If you have any ideas on how to implement this in fheroes2 consistently and correctly for the general case, let's get these ideas done.

Sorry for not clear suggestion. I meant something like this:

IMHO, first of all, it looks kind of scary :) And secondly the following quite logical question arises: "what about the rest of the places where these input fields are used?" This cannot be used in a unified way.

BTW, when testing the virtual numpads in different places, I noticed the following issue:

fheroes2.engine.version_.1.1.7.2025-03-26.22-38-12.mp4

Here, the Enter key closes both the virtual numpad window and the event details window. Could you please take a look how it can be fixed in a most "conventional" way according to the rest of the Editor's code?

[Districh-ru]

@oleg-derevenetz,

I believe that even if the current implementation of the keyboard input maybe sometimes works "almost normal", it is fundamentally broken in general, as I already mentioned before. I really suggest you try to set in the Dialog::SelectCount() min to 20 and max to 1000 and try to enter the number 100 from the keyboard. You won't be able to do that.

I understand this case and know that if min is more than 1 there will be problems with the input. So, yes, currently it works "almost normal" for the current min and max.
I'll consider how to improve the logic of such input and open a new PR.
For all such inputs we have the ability to open the virtual numpad. And also for dialogs with one input we have this "quick edit" as a feature.
IMHO the Dialog::SelectCount() and Recruit dialogs were designed to get a single number. And I don't like the idea to additionally open the other dialog for the same purpose.
As I stated earlier - what if we try to use the rules from virtual munpad to these dialogs: allow to enter any number and if it is out of limits warn the player when he presses OKAY button.

no one died from a few extra actions, but it looked consistent and worked correctly.

Yes, but we already have a quick edit feature for numeric input fields, and there are no big complaints about it.
Let's try to improve the current implementation and use of fheroes2::processIntegerValueTyping() (in a new PR). :)

Here, the Enter key closes both the virtual numpad window and the event details window. Could you please take a look how it can be fixed in a most "conventional" way according to the rest of the Editor's code?

Sure, I'll take a look. The problem is that both dialogs use the same hotkey for confirmation. And we need to reset the hotkey state after it's processed and not accept it until it is pressed again.