Cursor cursing

General JUCE discussion
1

why would the hourglass cursor keep appearing while mouse hovering over my app?

comes about every second, stays for a second. repeat ad infinitum…

it’s a simple dialogwindow based app with no Timers of my own making.

bloody annoying.

2

I’ve noticed the same thing. It doesn’t happen when you actually do somehing with it, just when you hover for a while.

3

it’s something to do with MessageManager::inactivityCheckCallback()

I thought I maybe had lot’s of silly repainting on the go but me “coloured boxes” seem well behaved.

4

i noticed the same thing also, although i remember not following thru with a thought i had to see if it happened in release build too… i was mostly working in debug mode and forgot to check when i built release

5

It’s only supposed to do it if it’s stuck in the message callback for too long… Are you using any strange sorts of message loops or anything?

6

no. this apps quite simple. click GUI - thing happens - waits for next interaction. I noticed the “time taken” was 800 and something in the MessageManager, while the threshhold was 500 I believe.

7

oh and release build does it too.

8

would total component count have anything to do with it? got about 160 :smiley:

9

Nah, 160 components is nothing…

I can only think that there aren’t any messages actually going through, which is odd, though could be because of the optimisations I made to the Timer code recently.

I’ll do some investigations, but I bet in the meantime you can get it working by just having a dummy timer object running somewhere.

10

I realised that after thinking about it! Fook all really is it.

11

It happens even with a blank window without anything on it. (Using Haydns demos.)

…though not with the big JUCE demo it seems! Are you basing your stuff off of Haydns thingies too Karb?

edit: Recompiled jucedemo to make sure its not a version thing, but jucedemo is still good.

12

[quote=“Pukeweed”]It happens even with a blank window without anything on it. (Using Haydns demos.)

…though not with the big JUCE demo it seems! Are you basing your stuff off of Haydns thingies too Karb?

edit: Recompiled jucedemo to make sure its not a version thing, but jucedemo is still good.[/quote]

Nah, got my own independantly evolved framework. pretty similar though but.

13

Did anyone ever work out what is going on with this? 'cos my app has just started to doing it, and it’s never done it before.

I did upgrade to juce 1.21[1] last week on my work machine, 'cos I’d let it get a version or two out of date. I don’t know if the problem started after that, but I can’t think what other changes I have made that could cause it.

It’d doing it when completely idle. I put break point in all of my message handlers to see if any were being fired incorrectly, and I can’t see anything untoward.

[1] some of the changes to the image class with the two latest JUCE releases need me to do a little rewriting, so I’m holding off until I have a free window to implement them.

14

In juce_Timer.cpp in the member “run”, change the line that reads:

if (now - lastMessageManagerCallback > 400)

to:

if (now - lastMessageManagerCallback > 2000)

This will increase the time between idle callbacks to 2 seconds.

  • kbj
15

I’ve already done that by simply placing a :

MessageManager::getInstance()->setTimeBeforeShowingWaitCursor(5000);

in my DialogWindow’s subclass constructor. Probably a little safer that editing the JUCE code.

Mainly I’m just wondering why JUCE seems to think it is doing buys work in the message handling thread, when application level messages are being generated (or at least as far as I can tell). :?

2 seconds is perhaps more reasonable than 5 though, I was just in a bad mood. :wink: