mouseDown coordinates for IBeamCursor

General JUCE discussion
1

Hi,

I’m new to JUCE, and I’m having a problem with unexpected behaviour for the I-Beam cursor.

When the cursor is an I-Beam, the x-coordinate passed to Component::mouseDown() is about two pixels left of where I’d expect it to be. To demonstrate this, I’ve put together a small test program that draws a vertical red line where the click was received (see attached screenshot of the program in action). I would have expected to red line to be perfectly aligned with the centre of the IBeam cursor.

Here’s a screenshot of how the application looks when it has received a click - note that the centre of the IBeam and the red line are not aligned:
[attachment=0]juce_2.png[/attachment]

Is this the correct behaviour, or am I missing something? (e.g. perhaps I’m grabbing the wrong coord, or maybe I should be offsetting the coordinates by some number of pixels for the window border, or maybe this is just how Windows returns IBeam coords? ).

Thanks,

M.

Some version info:
JUCE version: 1.52, and also today’s lastest from git
OS: Windows 7 64 bit

Here’s a minimal application that demonstrates what I’m doing:

#include "JuceLibraryCode/juce_amalgamated.h"

class MainComponent  : public Component
{
public:
    MainComponent()
			: m_lastClickPos()
	{
		setSize(600, 300);
		setMouseCursor(MouseCursor::IBeamCursor);
	}

    void paint (Graphics& g)
	{
		g.fillAll(Colours::white);
		if (!m_lastClickPos.isOrigin())
		{
			g.setColour(Colours::red);
			g.drawLine(
				static_cast<float>(m_lastClickPos.getX()),
				0.0f,
				static_cast<float>(m_lastClickPos.getX()), 
				static_cast<float>(getHeight()));
		}
	}

	void mouseDown(const MouseEvent& e)
	{
		m_lastClickPos = e.getPosition();
		repaint();
	}

private:
	juce::Point<int> m_lastClickPos;
};

//==============================================================================
class MainWindow  : public DocumentWindow
{
public:
    MainWindow()
        : DocumentWindow (T("JUCE Test"),
                          Colours::lightgrey,
                          DocumentWindow::allButtons,
                          true)
    {
        MainComponent* const contentComponent = new MainComponent();
        setContentOwned(contentComponent, true);
        centreWithSize(getWidth(), getHeight());
        setVisible(true);
    }

    void closeButtonPressed()				{ JUCEApplication::quit(); }
};

//==============================================================================
class JUCETestApplication : public JUCEApplication
{
public:
    JUCETestApplication()
        : mainWindow(NULL)
    {}

    void initialise(const String& commandLine) { mainWindow = new MainWindow(); }
    void shutdown()							{ mainWindow = NULL; }

    const String getApplicationName()		{ return "JUCE test"; }
    const String getApplicationVersion()	{ return "0.1"; }

private:
    ScopedPointer<MainWindow> mainWindow;
};

//==============================================================================
START_JUCE_APPLICATION (JUCETestApplication)
2

Well, your demo app works perfectly for me (in Vista). There can’t really be any problem with the actual position - this must be just the fact that in your windows set-up, the hot-spot for that cursor shape has been positioned off-centre - no idea how or why that’d happen though!

3

Hi Jules,

That’s strange! This is a standard Win7 install, and I haven’t done anything like modify the cursors etc.

Perhaps someone else who’s reading this and runs Windows 7 can try the demo app? That would allow us to determine is it’s something specific to Windows 7 or there is something strange going on locally…

I’ll do some googling too…

Cheers,

M.

4

I can also reproduce the x-offset with Win7/64-bit.

Chris

5

[quote=“ckk”]I can also reproduce the x-offset with Win7/64-bit.

Chris[/quote]

Thanks for trying that Chris, it’s useful to know that this is affecting other Windows 7 users. (I’m also using the 64 bit version of Win7 - I’ll edit my original post to mention this).

Not sure if it’s relevant, but I’m using an NVidia video card with the latest drivers (v270.61). The problem also occurs with older drivers (v258.96).

The problem occurs both with and without the Aero theme enabled.

Cheers

M.

6

I’ve just knocked up a quick windows API test app (using no JUCE code at all) and the problem is still present. See the following image:

[attachment=0]win32_2.png[/attachment]

So we’ve proved that JUCE isn’t involved in the problem.

7

Good old windows!

8

Yeah I have noticed some cursor weirdness in Windows 7 64-bit.

But I will stick to Windows for these reasons:

  • Intel Core 2 i7 985
  • Visual Studio > XCode
  • Falcon DRX laptops
  • Games
9

Hi Everyone,

Although we’ve established that this problem is not caused by JUCE, I’m pretty sure that finding the answer to this is in the interests of most JUCE developers targetting Windows 7 (as most of us need a pixel-accurate I-Beam pointer).

Therefore, I thought it’s worth mentioning that I’ve posted details of the problem in a question on Stack Overflow. If you’re interested in finding the answer, it would be very helpful if you could give the question on Stack Overflow an up-vote please, as this should attract more interest from people who can help. The question is here:

(A quick summary of the extra information that I’ve discovered since last posting about this on the JUCE forum: I’ve dumped out the hotspot information and the pointer bitmap for the I-Beam. There is indeed a two pixel discrepency between the x-coord of the hotspot and the pointer image in the bitmap. The big question is how could this discrepency occur on a default install of Windows 7 64-bit?).

Cheers,

M.

10

Why don’t we just create a correct i-beam cursor and include it in Juce using BinaryBuilder? Juce can have two cursors, one for the standard system provided and the other for the corrected version.

11

That would be a good workaround, but I think we’d first need to establish:

a) Is this problem definitely just a case of an incorrect I-Beam hotspot for the default system cursor set? (as opposed to programmer error)
b) If so, which versions of windows does this affect?

It feels slightly wrong to add things to JUCE if we don’t yet 100% understand the extent of problem we want to solve.