setVisible call not returning until mouse moves off screen

[robmar]

Dev sys:- Windows 7 64-bit, VS 2010

After Irrlicht is up and running in its own thread, started from an CScrollView::OnDraw call, a call to setVisible made from that thread does not return while the mouse is over the MFC CSCrollView window, handle of which was passed to create the Irrlicht device.

All other functionality works correctly.

Code: Select all

 
pCursor->setVisible( theApp.m_bFullScreen ); // Disable cursor if fullscreen <<<< FAILS TO RETURN UNTIL MOUSE MOVES OFF SCREEN!!!
 

[CuteAlien]

Could try adding the following line in CIrrDeviceWin32.h in setVisible as first line inside the while ( gotCursorInfo ) before the CURSOR_SHOWING test:

Code: Select all

 
if ( info.flags ==CURSOR_SUPPRESSED ) break;
 

Then recompile the engine and your application.

If that isn't the problem then please try to create a complete example (as source) which I can use to reproduce this.

[robmar]

Thanks for the tip! I´ve checked that through, but today its working! Nothing worse than a sporadic bug!

Maybe its because I´m using VS 2010 on Win 7 64-bit as its just unstable, the linker crashes VS completely every 2nd or 3rd compile, VS often fails to redraw its own screen correctly, and with an NVidia GPU, if its not set to permanently enabled none of the GLSL stuff works as it reverts to the basic Intel graphics! (the web is full of these reports).

With Microsoft its always one step forward, 3 steps back, get out your wallet and buy an upgrade, which of course has newer bugs (how else do they manage to resell the same product for 10+ years?!)!

Will be moving my 3D aquarium to Linux soon I think!!

[CuteAlien]

Hm, I suppose that line still might make sense. Guess I have to figure out a testcase for that at some time.

If you manage to reproduce it again some time, I would be glad about having an example to reproduce it. But blaming VS is also fine - I have often enough reason to do that as well :-)

[robmar]

... maybe unplug the mouse, MS docs say the internal counter then gets set to -1 ...

as a fail-safe, maybe just add a loop counter, decrementing from say 100, and breaking on zero, to protect against a driver or kernel issue..

[robmar]

... um, yes I sorta don´t like MS very much, marketing and revenue driven software comapnies makes our lives hell, and block innovation!

[CuteAlien]

... maybe unplug the mouse, MS docs say the internal counter then gets set to -1 ...

as a fail-safe, maybe just add a loop counter, decrementing from say 100, and breaking on zero, to protect against a driver or kernel issue..

Internal counter < 0 is checked already (showResult < 0 ).
And I'd prefer it to be correct to using a loop-counter :-)

[robmar]

Yes, I apprecaite how you feel about it, I think, for sure its a very crude protection,but it would work and ensure a return under all conditions.

As I understand it, the issue is not in setting the cursor active, as any positive value returned would confirm that status, but to ensure that the cursor is disabled, which requires a zero or lower count, hence the need for a loop to continue calls to decrement the value.

Microsoft´s coding seems sort of wooly, with no clear on/off control, and I guess this is to cope with multiple requests from multiple apps to enable/disable the cursor, but still, I don´t like the concept for its lack of clarity, something which the structure of Irrlich has in its favour.

So every call to setcursor with a zero value will decrement the value, but if there is another app calling to enable the cursor, it will be a war of time-slice, with no certain winner, and the possiblity that the call may never return.

The only way to prevent that is to use a loop counter limit, and abandon the attempt to disable the cursor after 100 or so cycles, IMHO.

Nasty as that is to any purist software engineer*, its how it seems to be, to me, but I´m open to alternative ideas!

[CuteAlien]

The alternative is having a test-case and figuring out the real problem...

[robmar]

Yes, its clear that if another app was trying to setvisible (true) while my app was trying to setvisible ( false ), that both apps could hang.

Hopefully that doesn´t happen, but if two apps had the same implementation within a loop, without a time-out, thats what would happen, no?

[CuteAlien]

Oh well - I suppose so. Counter it is (when I find some time).

[robmar]

I think its a practical solution. I know we´re not meant to mix topics, but is there anywhere any news on irrlicht 1.8?

[CuteAlien]

No news, I spend last 2-3 weeks mostly on figuring out why so many tests are currently failing as I don't want to continue without having working tests.

[robmar]

Must be hard going, if you want a hand, maybe with a specific area, maybe I could take a look, although I´m far from being an expert, I can do debug testing.