I would like to build an application using Mathematica 10. I would very much like to structure the application for maximum maintainability. To this end I would like to segregate controls and user interfaces to one set of source code files and calculations to another set of files. The basic idea being that the calculations are UI agnostic. They receive data and return the results of calculations and know nothing of UI code. The he same calculation .m files may be used from multiple user-interfaces (CDF, Web, Unit Test,.net, etc.).

Scope is important. I would like to minimize the risk of changing a variable in a calculation that unintentionally sets a variable value in UI or if I call a function that wraps a custom control, I want to keep all Manipulate variables local to the Manipulate or function that wraps the Manipulate.

I have tried using DynamicModule and LocalizeVariables->True but find that variables used by Manipulate are completely visible and settable in the notebook calling my DynamicModule where my control is defined. (I may be working with a set of assumptions and definitions of scope from application development languages that are not the same in Mathematica...)

Ideally I would like the ability to decide which variables are global and which variables are local to the manipulate.

I would like to build a set of re-usable custom controls in Mathematica 10 with the following criteria:

  1. Would like to wrap my control(s) in a function or module in a .m or .wl file under specific contexts.

  2. Variables are local to Manipulate and not visible or settable from the calling notebook.

  3. Would like to package user settings and return them from the module that wraps Manipulate. Something along these lines:

    mySettings = MyControl[]

    Where MyControl[] encapsulates the manipulate and returns a dataset or array of settings selected by the user. I would also like the Manipulate variables to be local to MyControl[] and not visible or settable in the calling code or notebook.

Again, I'm probably working under scope definitions of local and global used in application development languages.

Below is an example:

EKSWaveFormControl[] := 
                Plot[ ctrlVdc + ctrlVac  ctrlgFunc[ 2 \[Pi] ctrlf t + ctrlPhi],{t,0, 0.4}],
                    {{ctrlgFunc,Sin,""},{Sin,Cos, Tan, Cot }},
                    {{ctrlVac,1.5,Subscript["V","ac"]}, -10,10},
                    {{ctrlVdc, 0.5, Subscript["V","dc"]}, -1,1},
                    {{ctrlf, 10, "Frequency"}, 0.001,100},
                    {{ctrlPhi, 0, "\[Phi]"}, 0, 2 \[Pi]},
                         treatmentSpecRow = Dataset[ Association @ { Func -> ctrlgFunc, 
                                                                  Vac -> ctrlVac,
                                                                  Vdc -> ctrlVdc,
                                                                  \[Phi] -> ctrlPhi,
                                                                  \[Omega] -> 2 \[Pi] ctrlf }]],
                    ControlPlacement->Left, Paneled->True, LocalizeVariables->True]

When a user clicks the "Update" button, I would like to return a Dataset or array of the settings. But otherwise keep all variables used by Manipulate local to the Module.

  • $\begingroup$ You can build your own interface without usage of Manipulate. DynamicModule allows you to build dynamically updating interfaces using any available controls like sliders, checkboxes etc. Just put for example DynamicModule[{x},Panel@Column@{Slider[Dynamic@x],Dynamic@x}]; Dynamic@x You will see, that x is localized inside the DynModule. $\endgroup$ – Rom38 Sep 4 '14 at 14:00
  • $\begingroup$ Thanks Rom38 - I will give this a try. I am really not understanding the Mathematica version of local. I was expecting local variables to only be visible inside of the Module. However, they are defined and accessible everywhere. I tried moving the control function to a private context - same result - all Manipulate variables are global. Completely confused... $\endgroup$ – Doug Kimzey Sep 4 '14 at 14:16
  • $\begingroup$ What I am seeing is that if I define the control in a .m file, as soon as the Needs[] is executed in a Notebook all of the variables used in Manipulate - (even when LocalizeVariables->True is used) are global and visible. Furthermore, if I Remove[] each of the Manipulate[] variables directly after the Needs[] all Manipulate variables are global, visible and settable. Moving the control code to the Private context has no effect - same behavior. $\endgroup$ – Doug Kimzey Sep 4 '14 at 14:33
  • $\begingroup$ As I understood, the localizable variables in Manipulate are just manipulation parameters which are present as a {param,min,max,step} at the end of Manipulate definition. $\endgroup$ – Rom38 Sep 4 '14 at 15:46
  • $\begingroup$ They are parameters, however, if I have a Manipulate wrapped in a Module in a .m file, that includes {xParam, 0, 10, 0.5}; xParam is defined in a notebook following the Needs[] statement. Using the LocalizeVariables->True does not keep the variables local to the Manipulate. xParam is visible in the notebook and a value may be assigned to it outside of the Manipulate[]. $\endgroup$ – Doug Kimzey Sep 4 '14 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.