Game Development Community

Where is the cursor ACTUALLY set in the MissionEditor..

by Dusty Monk · in Torque Game Engine · 05/03/2007 (9:46 am) · 1 replies

(Caveat -- I'm posting this from memory, as I'm at work and all my source is at home. Advance apologies if I've misnamed/mispelled any of the classes I'm referring to. Hopefully you know which one's I'm talking about.)

So I've derived my own control from guiTSCtrl, as both MissionEditor and TerrainEditor do (actually, they derive from EditTSCtrl I think, which in turn is derived from guiTSCtrl), and I want to do some of the swank things they do with the cursor. Now both of these classes set up arrays of cursors, so the cursors are all initialized at loadtime, and then whenever they "setCursor", they're simply changing the mCurrentCursor point to point to the appropriately pre-loaded cursor from the array.

What I *can't* seem to find is where these classes actually inform the canvas that this is the cursor to use. That is, I see all the places in code where they set mCurrentCursor to be the cursor of choice based on mouse location or other actions, but I can't find anywhere the equivalent of a
gCanvas->setCursor(mCurrentCursor). And cause I think the cursor handling in MissionEditor and TerrainEditor is pretty swank, I want to set mine up to work like theirs. Is there some lower level thing that's picking up mCurrentCursor and setting it, or maybe some script code I'm missing that's actually turning mCurrentCursor into the canvas' cursor?

Thanks in advance.

D.

About the author

Dusty Monk is founder and president of Windstorm Studios, an independant game studio. Formerly a sr. programmer at Ensemble Studios, Dusty has worked on AAA titles such as Age of Empires II & III, and Halo Wars.


#1
05/04/2007 (12:07 pm)
I figured this out for anyone that ever wonders something similar.

Turns down at the basic GuiControl level, each control can have a notion of its own cursor. The RenderFrame method will query the current control that has focus for its cursor per update, and use that if it's available. If it's not available, then it uses the canvas' default cursor (which is what you set when you call
canvas->setCursor(blah). The canvas queries the control through the virtual "getCursor" method. SO, WorldEditor and TerrainEditor both override this function to return their current cursor, and that is the cursor that is displayed whenever that control is active. Swank huh? No canvas->setCursor necessary!