Login screen visibility increase

[srmalloy]

On the login screen, the white cursor against the off-white input field background is hard to see, making it easy, if you have 'save my login' checked, to start typing your password into the username field. In the interest of reducing the number of mistakes like this, could the cursor be changed to a dark color for the two input fields?

[captainstar]

1 hour ago, srmalloy said:

On the login screen, the white cursor against the off-white input field background is hard to see, making it easy, if you have 'save my login' checked, to start typing your password into the username field. In the interest of reducing the number of mistakes like this, could the cursor be changed to a dark color for the two input fields?

I think you can change this if you download the "CoH Modder" here. They have 4 types of cursor to pick. I think.

[srmalloy]

IIRC, that's the 'pointer' cursor (replacing the stock arrow pointer), not the narrow vertical bar that is the text input indicator in the login screen.

[Shaman Coyote]

This is an excellent idea and I agree completely. I think, however, that I would also like to have the cursor start in the PW field when you have remember UN  selected. For the login screen the thing I mess up the most is, as you said, typing over the UN.

[srmalloy]

Cursor color should just be a parameter (or two, if the fields are defined independently) that can be easily changed; altering where the input cursor starts depending on the state of another setting involves altering the client logic, and asking for a minimal change is more likely to be approved than asking for something that needs a more complicated code change.

[Shaman Coyote]

As a former software developer I can tell you that selecting a tab stop for an active input box based on content already populated in a different input box is next to nothing to code. From the small amount of research I've done into the source code, they're using C or C++ and those actions are inherent in both languages. Yes, it would require a slight change to the client, but so does anything involving new features. That's why any time a real update comes along the download includes so many extension files. Cursor color and such are generally things not included in settings files but are more commonly included in the code, especially on forms like Login or what are called Splash Screens. That's simply because the screens that come after that are completely separate forms with their own code-behind and interface code. The things that are done in settings files (what we used to call "ini" files) are things that change often or are user-settings. Things that aren't expected to change repeatedly are usually baked in. It's simply far less complex and requires fewer files.

 

Additionally, the code is actually already there. Have you noticed that if you tab between the UN and PW fields, any text already in the field you're entering is automatically highlighted? That code requires that on entering the field, the cursor is set to the beginning or end of the text and then the rest is selected. This means that when the code notices that the user has selected to remember the UN, it places the cursor on the first tab stop and enters the text. The only change would be that after that text is entered, the next tab stop is activated.  Maybe three lines of code added to the end of a single method.

 

To be specific:

 

<snip>

txtPassword.activate();

</snip>

 

Okay, maybe only one line although I don't know the actual object names being used.

 

The login screen isn't like the other code in-game; it's more static and therefore there's less in the way of iterative programming (which is, when a team isn't extremely diligent, what causes spaghetti code) and therefore should be fairly easy to modify with little risk of interfering with other aspects of the game. Obviously I could be very wrong, not having the source code myself--I really need to get that--but everything I've ever seen or heard since I2 when my Director of Development got me hooked on CoX says I should be pretty close to correct.

 

The only real obstacle would be getting it into an update which already happens every time a new page is released.