I don't really understand what you're trying to achieve with the 2nd charSprite line. It just doesn't make any sense. The parameters will be evaluated first:
Get the sprite's X
Get the sprite's Y
Then those will be passed back in to Set Position.
You're just telling the sprite to be where it already is.
Remove that line and see if matters improve.
Additionally, moving the sprite by 0.25 probably won't get it very far. SFML uses Vector2f because of OpenGL peculiarities, but positions need to be represented by whole numbers. And 0.25 * 1 will round down to 0. Try taking out those multiplications.
If you're making a game with this, moving your sprite in this manner will look pretty weird: you'll have to wait for the key repeat delay before the sprite starts moving. But take it one step at a time. Once you've cracked this problem, you might consider setting a flag when the key is pressed and resetting the flag when it's released. In your main loop, if the flag is set, you move the sprite by n. If the flag is not set, you stop moving the sprite. Then it can get a bit more interesting and you can use a velocity.
Down to why your setPosition line might be working with the call to yReset, it might be some side effect of the way the compiler is building your code crossed with the inner workings of SFML. If the compiler can see two calls to getPosition next to each other and no expectation of change of value (if the getPosition method is marked const in the SFML source) then it will optimise out one of the calls and only call it once. When it's calling yReset, there's no telling what you've done with that method and it'll be calling getPosition twice. Now, SFML will internally have made some change based on your call to move, and that will have changed the position.
I still don't really get how it's been working at all with moving by 0.25 though.
(If Vector2f is a struct, as it in the .Net bindings, you won't need to initialise it.
sf::Vector2f key;
will be sufficient.)