Moving sf::Text using setPosition inconsistent amounts

[Crown]

Hello, I am trying to dynamically position a sf::Text up and down based on keyboard input.  The problem is, when I set the position by incrementing its location, I get different values of movement when I move it up or down even if I increment/decrement by the same amount.  Here is a simple version:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(500, 500), "Move Text Test");
        sf::Font fontMovable;
        fontMovable.loadFromFile("arial.ttf");

        sf::Text txtMovable;
        txtMovable.setFont(fontMovable);
        txtMovable.setString("Testing");
        txtMovable.setColor(sf::Color::White);
        txtMovable.setCharacterSize(20);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
                        if (event.type == sf::Event::KeyPressed)
                if(event.key.code==sf::Keyboard::Up){
                                        txtMovable.setPosition(txtMovable.getGlobalBounds().left, txtMovable.getGlobalBounds().top - 10);
                                }else if(event.key.code==sf::Keyboard::Down){
                                        txtMovable.setPosition(txtMovable.getGlobalBounds().left, txtMovable.getGlobalBounds().top + 10);
                                }
        }
        window.clear();
        window.draw(txtMovable);
        window.display();
    }
    return 0;
}
 

As you can see, I increment by 10, but when I move the sf::Text up, it actually goes up by 5 and going down actually goes down by 10.  These numbers change based on the size of the font.  I know there is probably something I am not understanding about the getGlobalBounds().

I am using SFML 2.1 and Visual C++ Express 2010.

Any help would be appreciated.   Thanks.

[Hapax]

I believe this is the result of the text object's origin not being at the top-left of it's bounding box. Since its origin is not at the actual top of the text, but the top of the global bounds is from where you base the new position, you are setting the new position (and therefore the origin) based on its actual bounds. I'm making myself confused 

First solution would be to just use txtMovable.move(0, -10); and txtMovable.move(0, 10);
Second would be to take into account the origin by using getLocalBounds.top and putting that into the calculation (I think you would subtract it here but I've forgotten).

EDIT:
Just tested it and I can confirm that you need to subtract it.
Therefore, the current y position is: txtMovable.getGlobalBounds().top - txtMovable.getLocalBounds().top
and the new y position when moving upwards would be:
txtMovable.getGlobalBounds().top - txtMovable.getLocalBounds().top - 10

[Crown]

Thank you for taking the time to get back to me, I really appreciated it.  I made the change and it works now.

Now, to understand this correctly, when I am setting the position, it sets the position of the origin?  But, getLocalBounds() returns the bounding box of the string text within the sf::Text?  The top left coordinates of this local bounds is therefore NOT the origin of the sf::Text?  How are these local bounds calculated?  Are they changing every time the string of the text changes?  I'm sure there is a reason, so why is the top left of the bounding box not at the origin?

Edit: Upon closer look at the documentation I see that there is also a getPosition() function which I assume then get's the global origin.  Another solution to the two above would then be: txtMovable.getPosition().y - 10.

[Hapax]

No worries. Glad I could help 

Just to clarify, when you set the position of a text object (or any graphical object), it moves the object so that its origin is at that position; you aren't changing the origin in relation to the object. It just happens that most objects have an origin at the top-left corner (unless you change it.) The text object, however, has an origin that isn't necessarily top-left.
I've read a lot about this, as many people run into this problem, and I still don't fully understand it