Re: Re-virginating Manipulates?
- To: mathgroup at smc.vnet.net
- Subject: [mg114320] Re: Re-virginating Manipulates?
- From: Yves Klett <yves.klett at googlemail.com>
- Date: Wed, 1 Dec 2010 02:10:00 -0500 (EST)
- References: <id2emh$d7s$1@smc.vnet.net>
Also, on the issue of localization, I had some success using With[] to run several Manipulates (spawned from one template) in parallel. John Fultz mentioned something about the importance of With[] during this year's tech conference, but I forgot specifics except that one should keep an eye on With in terms of localization. Of course I may remember wrongly and would be happy to be corrected and/or educated on the issue. Regards, Yves Am 30.11.2010 10:04, schrieb Ingolf Dahl: > This interaction between different Manipulate cells can be a pest, > especially in the authoring notebook for a new demonstration, where you > should have the same Manipulate cell in several variants, as thumbnail and > as snapshots. If you manipulate one of them, the other cells might interact, > especially if some variables are defined in the Initialization option. I > denote this problem "the Isolation Problem". The Manipulate command puts all > controls inside a DynamicModuleBox, (hopefully) isolating them from > interaction with other cells. However, variables defined by the > Initialization option are defined outside the DynamicModule, and they might > interfere with outside code and other Manipulate cells, if the same variable > names are reused. According to my current understanding, there are three > measures you could take: some combination of them could be effective. > Please correct me if I am wrong, I would very much appreciate that. > > 1) One way to avoid interaction between Manipulate cells is of course to use > strictly different names in the different cells, maybe containing some > cell-specific string in such a way that it easily replaced. > > 2) Another method is to use an option CellContext, which might be set to > Cell for the whole notebook. Then, a unique default context is used for > every cells in the notebook. > The CellContext option can be set by selecting Format -> Option Inspector -> > (Selected Notebook, by Category) -> Cell Options -> Evaluation Options -> > CellContext. It might alternatively be set by the command > SetOptions[EvaluationNotebook[ ], CellContext->Cell]. > However, I am not sure that this always is effective to stop interaction > between the cells. > > 3) If we do Show Expression on the Manipulate cell (Shift+Ctrl+E in > Windows), we see that all variables are defined in the $CellContext` > context. Do Find&Replace and replace $CellContext` with something else, e.g. > CellContext01`. Close Show Expression and open the next Manipulate cell, and > replace in the same way with CellContext02`, and so on. > > Measure 1 and 3 might break down if we then do "Update thumbnails and > snapshots" in a Demonstrations authoring notebook. > > Best regards > Ingolf Dahl > ingolf.dahl at telia.com > >> -----Original Message----- >> From: AES [mailto:siegman at stanford.edu] >> Sent: den 29 november 2010 12:07 >> To: mathgroup at smc.vnet.net >> Subject: Re-virginating Manipulates? >> >> Let's define the label "virgin" for a Mathematica notebook as referring >> to the condition and content of a notebook file that's been opened for >> the first time, had some cells typed into it, maybe been Saved, but none >> of its cells have ever been executed. >> >> How can one re-virginate such a notebook (and also the currently >> running Mathematica app and kernel, if necessary) after any (or all) of >> the cells in this notebook have been executed one or more times -- >> especially if the notebook contains one or more Manipulates? >> >> [If you want more detail, the objective is to code a number of >> (potentially multi-cell) "demos" -- call them demo_a, demo_b, ... -- >> each of which contains a Manipulate, and all of which are totally >> independent of each other (no transfer of info between different demos >> needed or wanted); and then be able to jump around randomly amongst >> these demos, executing or re-executing them, and getting identical >> results each time a given demo is executed, regardless of what's >> happened before it is selected and executed. >> >> Each demo is, preferably, a separate notebook (a separate file), or >> multiple demos could be cascaded in a single notebook, in the form >> >> <<Header cell>> >> demo_a >> <<Header cell>> >> demo_b >> <<Header cell>> >> demo_c >> <<Header cell>> >> >> What initial cells does each demo_x need to make that demo execute as a >> virgin demo when jumped to?] > >