[sldev] [VWR] How to determine Build mode status reliably?

Richard Nelson richard at lindenlab.com
Fri Oct 12 12:41:15 PDT 2007


Unfortunately, there is no great way to do that (especially because "Build  
mode" isn't a formal mode per se, but rather a fuzzy context).

LLTool::inEdit() looks broken to me.  It relies on global knowledge of  
which tools are available and of those, which are for "editing" vs "other  
stuff."  Since it doesn't acknowledge the mouselook tool, it reports the  
incorrect mode.  Much better for the individual tools to report their own  
semantics.  There is an LLTool::isEditing() but that logic looks wrong, as  
it relies on currently having an object selected.

In the past, I know we've relied on gFloaterTools->getVisible().  This  
usually does what you want, as long as you realize the window will  
disappear while using a manipulator (rotating an object, for example).

This is really something we need to clean up.

Richard

On Thu, 11 Oct 2007 11:59:42 -0700, Ettore Pasquini  
<ettore_pasquini at 3dconnexion.com> wrote:

> What's the right method to detect that we are in Build mode?
>
> I thought LLToolMgr::inEdit() was the one, as its usage is accompanied  
> with
> comments like "see if we're in build mode" in the code.  However, I found
> out that the method returns "true" (i.e. "yes, we are in build mode")
> everytime I am in Mouselook mode.  Is this intended?  If so I fail to
> understand the logic behind it, and in any case inEdit() is not the right
> one for my problem.
>
> I have found an alternative condition to determine Build mode status, but
> I'm not sure how stable this is:
>
> (gToolMgr->getCurrentToolset()->getSelectedTool() == gToolCreate)
>
> It seems to work so far, but can that be used reliably? What should I use
> instead?
>
> Thanks,
>
> Ettore
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html




More information about the SLDev mailing list