Re: Combining Slider and SetterBar in Manipulate
- To: mathgroup at smc.vnet.net
- Subject: [mg115250] Re: Combining Slider and SetterBar in Manipulate
- From: AES <siegman at stanford.edu>
- Date: Tue, 4 Jan 2011 18:53:35 -0500 (EST)
- References: <email@example.com> <firstname.lastname@example.org>
In article <ifup6c$cnr$1 at smc.vnet.net>, JohnH <ununquadium113 at yahoo.com> wrote: > > Also...a bit of unsolicited advice. Your use of Block is a *bad* idea. > > It's > > always bad to reference Block-scoped or Module-scoped variables declared > > outside > > of a Manipulate or Dynamic from within that Manipulate/Dynamic. If you're > > wanting to localize the variable 'someData', then Manipulate offers you an > > easy > > way to do that. Add someData as a control variable, but no control > > appearance. John, I haven't followed the earlier part of this thread (and scoping is something I try to think about as little as possible!), but could you expand on this a little? As an old Fortran programmer, I think in terms of subroutines. So, in building a Manipulate I want to first define a "subroutine" (that is, a Module) which depends on, say, 2 or 3 explicit arguments, plus maybe a few global parameters which will have already defined values. This subroutine will then return a numerical value or maybe a graphics object. Then I want to build a Manipulate in which some or all of the explicit arguments are controlled by Controls (others may be explicitly set within the Manipulate); call this subroutine (or maybe several such subroutines) within the Manipulate; and Plot or Show the object returned by the subroutine, or something that depends closely on it, still within the Manipulate. I guess the primary objective of this approach is brevity of code within the Manipulate, plus just general modularity. Is the above a bad approach? -- especially assuming that the overall notebook containing the Manipulate will be relatively brief and self-contained, and one needn't worry about side effects after the Manipulate has been used.