Re: NotebookGet/Read/EvaluateSelection Issues

*To*: mathgroup at smc.vnet.net*Subject*: [mg106643] Re: NotebookGet/Read/EvaluateSelection Issues*From*: Paul <pkshreeman at gmail.com>*Date*: Wed, 27 Jan 2010 01:41:40 -0500 (EST)*References*: <hj98as$g52$1@smc.vnet.net> <hjmjf1$d9$1@smc.vnet.net>

On Jan 26, 6:25 am, David Bailey <d... at removedbailey.co.uk> wrote: > Paul wrote: > > My fellow Mathematica'ians... > > > I am having difficult time figuring out whether it's my programming or > > the bugs:... I have first notebook called xy.nb that simply has > > > y=x+3 > > > and then I have another notebook that has the following: > > > test=NotebookOpen[xy.nb]; > > NotebookRead[test]; > > x=7; > > SelectionMove[test,All,Notebook]; (*Seems I have to force selection= , > > even though there's only one cell in the entire notebook xy.nb?*) > > SelectionEvaluate[test]; > > Print["y equals to ",y] > > > Naturally, I'd expect the output to read, "y equals to 10" but the > > output is "y equals to y"...the variable "y" remains unevaluated or > > unassigned. If I re-evaluate the y (either redoing the whole thing > > with kernel still running, or manually calling variable "y" by typing > > in frontend, "y" and hitting shift-enter. > > > This is simple example of my project, I wanted to develop a modular- > > style programming instead of really long single notebook to do my > > Dissertation work..and be able to call certain functions in separate > > notebooks (optional mathematical calculations, for instance)..and keep > > all global variables intact to be used in all calculations (AND be > > immediately usable once evaluated!). Right now, I can't call xy.nb t= o > > do calculations, and take the value of "y" to do another type of > > calcuation since the value of "y" remains unassigned. > > > Thank you! > > To answer your original question, the code doesn't do what you think > because SelectionEvaluate stacks an evaluation to be done after the > current evaluation completes! > > I have seen people use fairly exotic functions such as SelectionEvaluate > for the same reason you are doing, and I wish the documentation would > somehow warn people from doing this - these functions are useful for > notebook manipulation. > > Either consider using packages - as suggested, or simply set your code > up as a set of functions spread across multiple notebooks, and read an= d > execute each notebook in turn. The final notebook might end with a call > to a function to kick off the actual calculation. > > Remember that a .m file doesn't need to hold a package - just any > Mathematica code, and it can sit anywhere in your file space if you use > Get with the appropriate pathname to evaluate it. Get can also read > notebook files according to the documentation - I have not tried it. > > You really don't want to use top-level definitions for variables like > 'y' (i.e. things that look like algebraic variables) because they > invariably stick around and bite back further down when you have > forgotten them. Rather than writing y=3, I would use a replacement rule > on an expression: > > expr /. y->3 > > That way, the replacement of y by 3 is localised. > > David Baileyhttp://www.dbaileyconsultancy.co.uk Mr. Bailey, That's one of the answers I was looking for...the stacking effect. I have done <<note.nb, and it does "get" the notebook. However, as you have mentioned, those notebook commands is not practical for my application. It seems to me that those things are actually designed to be "internal" commands...perhaps as a button function that opens a new notebook, "paste" stuff in it, move the "selection" around...somewhat like GUI application-development tools. I'm sure these things have drastically improved in Mathematica7 by now. Paul