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

Jacek Antonelli jacek.antonelli at gmail.com
Fri Oct 19 19:43:52 PDT 2007

On 10/12/07, Richard Nelson <richard at lindenlab.com> wrote:
> 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
> >

WARNING: This is a totally ugly hack, and it smells very bad, and I
wouldn't touch it with a 256m megaprim. That said...

The global setting BuildBtnState seems to become TRUE whenever the
Tools/"Build" floater is open (you can watch it change in the Client >
Debug Settings floater). I'm not sure how safe it is to assume that
"build button enabled" will always imply "build mode active", but it
seems to be the case right now.

However -- and this is just a guess, since BuildBtnState doesn't have
a documentation string associated with it (*tsk tsk*) -- I suspect
that the original intent of BuildBtnState was to determine which way
to render the Build button, one specific UI element. I would be very
wary of attaching extra significance to it by making new features
dependent on its behavior.

 - Jacek

More information about the SLDev mailing list