Out of curiosity, does anyone know if it's possible to actually recognise what the cursor display is when moved over a gauge? I tried pgauge->mouserect.cursor== but it never responded. It's no big deal but I can see it being useful if it's possible.-Dai

Since you define what the cursor is over a gauge, (unless you didn't write it), you should already know. If not, why would you be using someone else's gauge? Write your own, then you don't have this issue.

Patrick -I didn't ask for a reply that has - perhaps unfortunately - come across as snappy/irritable/abusive/whatever, when I asked a perfectly civil question. I'm not interested in the cursors used by anyone else's gauges and you are aware that, in general, I'm more than capable of writing my own. I have no wish to start a flame war, nor do I have any wish to have bad feeling on the forum, so I choose to assume that your reply did not come across in the way it appeared to do so.I had been trying to differentiate between CURSOR_GRAB and any other cursor within one of my own gauges. I couldn't differentiate between them, so I created a workround by doing something else. I was curious as to whether anyone else had had any luck in recognising the different cursors as they are changed by FS as opposed to being deliberately changed witin the gauge code.-Dai

>Out of curiosity, does anyone know if it's possible to>actually recognise what the cursor display is when moved over>a gauge? I tried pgauge->mouserect.cursor== but>it never responded. It's no big deal but I can see it being>useful if it's possible.Dai,Perhaps you need to do a memcmp instead. Whenever I need to compare a fixed 'string of characters' with a variable, this technique works:memcmp(RTU1_params,"RTU1 VC",7) == 0In the case above, I'm reading the 5th parameter read from the gauge's panel.cfg entry, and comparing it with the fixed string "RTU1 VC"... If they match exactally, the result is ZERO... ;)

Dai,Yeah didn't mean it that way at all. Are you trying to do this from within code within that very gauge, or from another gauge in a multi-gauge, or from a completely different gauge?I do something similar, but I'm not sure what you are talking about for sure.Are you asking if you do something like this: MOUSE_CHILD_FUNCT(0, 0, 50, 104, CURSOR_HAND, MOUSE_LEFTSINGLE, someSwitch_mcb)to be able to later lookup what you have set?

Sorry for the slow reply guys.....stupid-busy at the moment.Bill: I'm not sure that would help with the question; however, read on.Patrick: What I have is a set of drag'n'drop speedbugs on an ASI. The cursor changes to CURSOR_GRAB while a bug is being moved; once the drag action is stopped (i.e the mouse button is released) the cursor switches back to default - in this case, CURSOR_HAND. I was hoping to be able to know when the cursor is back at default (CURSOR_HAND) so that I could use that to fix the position of the bug; as it is, I settled for a right-click to 'drop' the current bug before a left click selected the next bug.I've tried all sorts of variants of (pgauge->mouserect[1].cursor==)and(pgauge->mouserect.mouseflags,MOUSE_)in the update section but all return a permanent 1. There's probably a syntax error on the last code snip; I'm not at home at the moment.-Dai

Ok, now I have more of an idea of what you are trying to do.Maybe you could just capture the actual mouse position in the mouse callback for the drag, and then check that when it is released.BOOL FSAPI Bug_mcb(PPIXPOINT relative_point, FLAGS32 mouse_flags){ if(mouse_flags & MOUSE_LEFTDRAG) { // Drag happening, so keep saving the position mypoint = relative_point; // Keep track of mouse position } if(mouse_flags & MOUSE_LEFTRELEASE) { // The drag has ended }}of course, you'll have to declare mypoint somewhere where it will be in scope when you need it.

>MOUSE_LEFTRELEASEThanks Patrick - that did the trick. A bit too obvious for me... :)-Dai