Having editable text on screen, and pressing the "i" key breaks it

[Jesper Juhl]

p.s. Jesper, there's only one event type here so there's nothing to switch 

I know. I read the code.
I just saw that "if foo && bar" followed by another "if foo && baz" and thought "well, if it is foo, then check for that once".. As I said; not important. It's just so common to see newbies write functions with multiple if statements that are mutually exclusive and should be 'else if's or switch'es that one gets allergic to the pattern..

[DraGun]

Ok well I think I figured it out, then I saw the last 2 replies XD here's what I got:

void type(sf::Clock & clock, sf::String & string, sf::Event & event)
{

        if (event.type == sf::Event::TextEntered && clock.getElapsedTime() >= sf::milliseconds(130) && event.text.unicode != '\b')
        {
                clock.restart();
                string.insert(string.getSize(), event.text.unicode);
        }

        if (event.type == sf::Event::TextEntered && event.text.unicode == '\b' && clock.getElapsedTime() >= sf::milliseconds(130))
        {
                clock.restart();
                string.erase(string.getSize() - 1, 1);
        }

}
 

Can you not nest the conditions so that they are a bit clearer

For whatever reason, whenever I try to use else it just never works, so i usually don't nest them, or I have else ifs. But Your code looks good as well.

 Thanks everyone for your help. On a bit of a side note, what's the unicode for the return key? That's gonna go in the same function, so it's somehwat relevant.

[Hapax]

I just saw that "if foo && bar" followed by another "if foo && baz" and thought "well, if it is foo, then check for that once".. As I said; not important. It's just so common to see newbies write functions with multiple if statements that are mutually exclusive and should be 'else if's or switch'es that one gets allergic to the pattern..

The code did actually have two types but it was incorrect and didn't need them both so you probably subconciously spotted that 

For whatever reason, whenever I try to use else it just never works, so i usually don't nest them, or I have else ifs.

Nesting and if/else is very different. Nesting is putting ifs inside other ifs. Else is for things that will occur when the result of the if did not.
The nesting I was talking about was the event type (and timer) as both ifs checked for the same thing.
You can do the same thing without the else that I used if you prefer. You use:

if (event.text.unicode != '\b')

instead of "else", if that helps you to see what's going on. (Although I would recommend using "else if" for each specific character for which you test (backspace, return, tab etc.) and then "else" for everything else (the actual text).
Maybe Jesper's suggestion of a switch could help clarity for you 

On a bit of a side note, what's the unicode for the return key? That's gonna go in the same function, so it's somehwat relevant.

I believe that this varies from system to system and the two possibilites are '\n' and '\r' (meaning newline and return respectively or, more accurately, linefeed and carriage return). Have a look through my ASCII include. The aliases for newline and return are a bit lower.

[DraGun]

That's true. I guess I never bother cuz either way it's gonna end up in multiple if statements, and this way you can see what each if is testing for, and they're independent of each other and can't cause the other to mess up.

[DraGun]

Oh, for posterity and clarification,  the major thing I realized why the backspace and return keys weren't working probably is because the code wasn't treating them like KeyPressed, it was treating them like TextEntered. Once I changed, it started working fine. Strange but *shrug* whatever, so long as I got it to work.

[Redee]

You are very welcome - coding is very hard path in life )).
And one secret too >
if you have one variable comparison - much much faster - switch(..){case:..;break;} construction instead if(..){}else if(..){}else if(..){}

[Hapax]

if you have one variable comparison - much much faster - switch(..){case:..;break;} construction instead if(..){}else if(..){}else if(..){}

I'm not sure I agree with switch being faster. I don't find it quicker to code than if-elseif-elseif-else and I'm not sure that switch would execute faster. I may be wrong; it's not something I've questioned 

[dabbertorres]

Personally, if a switch can be used, I use it, as I find it a bit easier to read.

In some cases, if the case values are not spaced out (ie: 1,2,3,4,5 vs 1,4,7,12), a compiler can optimize a switch to be a bit more performant (jump tables). But good compilers could also do the same with a series of if-else statements, so it's kinda up in the air.

Really just comes down to personal preference of readability.

[Redee]

Someone did tests far far away in 2007 )
http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx