[LH4583|LH4582] "Document target" Tab navigation unpredictable & deleted count returns

[Ati2]

I was advised to post bugs here, and not in the bugs section, for some reason. So here we go:

- the tab order in the Document Target window is totally messed up
- when the text fields get focus, it should highlight the text in the field, and delete it as soon as you type something. Right now, opening the Document target window, and typing 1000 will result in the document having a target word count of 10,000 words—the zero that's in there initially is not deleted, but you type stuff in front of it. When you have "900" there, and want to change it to 800, you type 800, and end up with 800,900, close to a million words as target. Definitely not what one wants when typing 900.
- when I delete a value, such as overrun allowance, that's because I want it gone. Right now what it does if I delete it, is bring it back as soon as I hit the OK button.

Scenario: I have "600" in the overrun allowance field. I highlight this value and delete it, since I don't want this tracked. I click "OK."

Expected behavior: Overrun allowance gets deleted.

Actual happening: The previous "600" gets reset, as if I didn't even delete it.



Scenario 2: I have "600" in the overrun allowance field. I click in this field and use the backspace button to delete it, since I don't want this tracked. I click "OK."

Expected behavior: Overrun allowance gets deleted.

Actual happening: The overrun allowance gets changed to "6".

Details in the bug forum: viewtopic.php?f=32&t=61226

[devinganger]

I was advised to post bugs here, and not in the bugs section, for some reason.

Because the bugs forum is for the *released and supported* versions, as was already explained to you. The beta forum here is for all communication about the beta versions. That way we aren't spamming people who are just using the release and don't want to worry about the new version until it's generally available and supported.

[Ati2]

These issues still exist in RC6.

[MimeticMouton]

Thanks for the report. The Tab key navigation issue and the confusing behvaiour of the deleted counts returning have been filed. To clear your values for the time being, enter "0" as the desired count.

To overwrite the current value in a field, double- or triple-click rather than single click into the text to select it all before entering the new value.

[Ati2]

This is somewhat better in RC7, but clicking the "Document Target" icon, any typing "900" will still result in the target being set to "9000" instead of the 900 I typed. The "0" that's in the field by default should get automatically selected when the window pops up, so anything I type overwrites it, not writes before it and keeps the current value there.

[MimeticMouton]

The "0" that's in the field by default should get automatically selected when the window pops up, so anything I type overwrites it, not writes before it and keeps the current value there.

This isn't the standard behaviour for this type of field. You can double-click to select the existing text before typing if you want to overwrite it.

[Ati2]

The "0" that's in the field by default should get automatically selected when the window pops up, so anything I type overwrites it, not writes before it and keeps the current value there.

This isn't the standard behaviour for this type of field. You can double-click to select the existing text before typing if you want to overwrite it.

I don't know of a single Windows program where this is not the standard behavior.

[devinganger]

I don't know of a single Windows program where this is not the standard behavior.

It isn't about the *program*, it's about the display widget (also known as controls in some developer frameworks).

A widget/control is the interactive GUI element that you see on the screen -- one button of a radio button selection, a spinner control, a text label, a text box, etc. Those widgets are provided by the developer framework(s) that the programmer is using, and provide a pre-written chunk of code. Some of the behaviors are hardwired into the code, some can be modified via properties.

There are, in fact, several input controls that do NOT select the current contents when you click inside them to activate them, and there are usually good reasons for why this behavior is desired (or at least tolerated as an allowable side effect of some other desired behavior that drives the decision of which widget to use).

You have a bug number assigned. That means the developers do consider at least part of the behavior you have reported to be a bug and will be fixing the undesired behavior at some point. These may not be very high priority bugs at this point, however, and they have already warned us that they will not be fixing every bug before the 3.0 release -- some will get to wait until subsequent bugfix releases come along. Again, there are many reasons why they may triage these bugs in this fashion.

Until then, though, you do have a valid workaround for this particular behavior and it works 100% of the time, so patience would seem to be in order.