Tips on using the Programmer's Reference

[ted]

Q: "The Programmer's Reference contains a lot of stuff, and there's a lot of other
documentation about NEURON too, but I only need an answer to a very specific
question. How can I drill down to just the items I'm interested in?"

A: Frequently the key to solving a programming problem is knowing the name of a
variable procedure, or object class. If you can make a reasonable guess about the
name you're interested in, try the alphabetical listing of keywords
http://www.neuron.yale.edu/neuron/stati ... index.html
or the "Quick Index"
http://www.neuron.yale.edu/neuron/stati ... rence.html

But if you don't have any idea what something is called, those indices may not be very
helpful, because it may be a long time before you accidentally stumble on what you need.
When you are clueless, a better place to look is in the hierarchical index
http://www.neuron.yale.edu/neuron/stati ... /hier.html
especially near the bottom, where you'll find these entries

Code: Select all

      neuron.exe
         general
            ObjectOrientedProgramming  functions  syntax  
            button-menu-panel  keywords   
            classes        predeclared-variables  
         neuron
            CompileTimeOptions  functions  keywords      
            Section        globals        mechanisms     
            classes        ion            pointprocesses

The items under neuron.exe / general pertain to general programming issues, and
the items under neuron.exe / neuron have more to do with building and managing
models of neurons per se. For example, if you want to know if there is a function that can
be used to change the working directory, you'd look at
neuron.exe / general / functions
but if you are looking for a class definition that can be used to display the branched
architecture of a cell, you'd look at
neuron.exe / neuron / classes

[ted]

Rule I: When all else fails, read the Programmer's Reference.
It contains many working examples that you can cut and paste into your own programs.

Rule II: Read the Programmer's Reference again.

Rule III: If something in the Programmer's Reference seems unclear, make your best
guess about what it means, and then write a short program to see if you guessed
correctly.
And please let us know if you find anything that is unclear or incorrect, or if you have a
suggestion for improving the documentation.