I think I found a bug with sf::Mouse::getPosition

[carton83]

Compiler: MinGW
IDE: CodeBlocks 13.12
Platform: Win7, 64bit
Repeatability: Always
Any special compiler settings: None
Version of SFML being used: Using 2.1, grabbed from the official downloads page.

This is the bug:  When calling

mouseCoord = sf::Mouse::getPosition(window)

and the mouse cursor enters a region around (37,n+) (n+ being any positive number) for what ever reason

event.key.code == sf::Keyboard::Escape

becomes true.  I am not sure why and I simply don't have enough skill to find out why.

Putting

mouseCoord = sf::Mouse::getPosition(window)

after the even code loop still causes

event.key.code == sf::Keyboard::Escape

to register as true. 
I've actually noticed that the results are different depending on the key used.  A couple of keys I've tested are listed at the bottom.
Using the global version of getPosition() doesn't seem to reproduce the bug.


Image used. The red part is generally where the "problem area" is.

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if(!texture.loadFromFile("test.png"))
    {
        return -1;
    }

    sf::Sprite image(texture);
    sf::Vector2i mouseCoord(0,0);


        while(window.isOpen())
    {

        mouseCoord = sf::Mouse::getPosition(window);
        std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";

        sf::Event event;
        while(window.pollEvent(event))
        {

            if(event.key.code == sf::Keyboard::Escape)
            {
                window.close();
            }

        }

        window.clear();
        window.draw(image);
        window.display();

    }

    return 0;
}

These are the keys I tested, but I'm sure it affects far more, maybe even all of them
A: Always marked as true
B, C, D, E, F, G, H, I, J, K, L, M: The problem area seems to be around 0,n
Pause: The problem area seems to be around n,0
End, Home: 62,n+

[FRex]

You are using sf::Event wrong: http://www.sfml-dev.org/tutorials/2.1/window-events.php
Fix the bugs in your code and then see if the SFML bug still manifests itself.

[carton83]

Still happens.

And, if I'm not mistaken, functionally there isn't much different from what I have and the switch statement used in the first example area other than pollEvent() is used to process every pending event.

[FRex]

The problem is you don't check if event.type == sf::Event::KeyPressed first, did you correct that?

[carton83]

In the added switch statement? Yes.

The statement is

switch (event.type)
{
    case sf::Event::KeyPressed:
    {
        if(event.key.code == sf::Keyboard::Escape)
        {
            window.close();
        }
        break;
    }
}

EDIT:

So when is the switch suppose to be used and when is pollEvent used?  Or are you saying that my while loop should have had a if loop that checked sf::Event::KeyPressed  first?

[FRex]

If this code causes problem then it's SFML or files/compiler problem:

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if(!texture.loadFromFile("test.png"))
    {
        return -1;
    }

    sf::Sprite image(texture);
    sf::Vector2i mouseCoord(0,0);


    while(window.isOpen())
    {

        mouseCoord = sf::Mouse::getPosition(window);
        std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";

        sf::Event event;
        while(window.pollEvent(event))
        {

            if(event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
            {
                window.close();
            }

        }

        window.clear();
        window.draw(image);
        window.display();

    }

    return 0;
}

The point is you should never ever read from any field of sf::Event before checking its type field.

[carton83]

That seems to fix it, but why would it still appear here even though it is checking.  Or am I not seeing something?

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

    sf::Texture texture;
    if(!texture.loadFromFile("cb.bmp"))
    {
        return -1;
    }

    sf::Sprite image(texture);
    sf::Vector2i mouseCoord(0,0);

        while(window.isOpen())
    {

        sf::Event event;
        switch (event.type)
        {
            case sf::Event::KeyPressed:
            {
                if(event.key.code == sf::Keyboard::Escape)
                {
                    window.close();
                }
                break;
            }
        }

        mouseCoord = sf::Mouse::getPosition(window);
        std::cout << mouseCoord.x << " " << mouseCoord.y <<"\n";

        window.clear();
        window.draw(image);
        window.display();

    }

    return 0;
}

And even then, I don't get why getPosition would have an affect on event.

[FRex]

Your switch(event.type) should be in while(window.pollEvent(event)) loop, as show in tutorial.

I don't get why getPosition would have an affect on event.

It doesn't, unless there is a bug in SFML which we are trying to confirm or bust, but your code is not correct in a way that allows anything to happen but usually will yield garbage or wrong values, as explained in the tutorial.

[G.]

And even then, I don't get why getPosition would have an affect on event.

Because Event is an union.

Please note that the event parameters are defined in a union, which means that only the member matching the type of the event will be properly filled; all other members will have undefined values and must not be read if the type of the event doesn't match. For example, if you received a KeyPressed event, then you must read the event.key member, all other members such as event.MouseMove or event.text will have undefined values.

And sf::Key::Escape is around the 37th value in the enum. So if you're checking event.key.code while not checking you're in a keyboard event, it can be ~37 because of mouse move events.

[carton83]

Thanks everyone!  I'm not much of a technical person so some of the concepts are hard for me to grasp properly.