![]() ![]() You could imagine having a SetVariable control or global variable as input for function 1, but transferring the values to functions 2 and 3 is best done with local variables. The example you use is just a temporary transfer of data from function 1 to functions 2 and 3. ![]() You either end up with a huge number of global variables, or you end up using the same global variable for several different things, which increases the chance of two functions simultaneously using the same variable for different things. Using global variables to transfer temporary data between functions is usually not a good idea. Creating global variables in data folders other than root: might help to distinguish different global variables. It does mean the value is lost when the window hosting the control is closed, you will have to use a global variable to avoid that. I like that solution because it keeps the number of global variables low. With SetVariable value=_NUM:xxx and SetVariable value=_STR:"xxx" you have the option to store the value in the control instead of in a global variable. I like to use SetVariable controls in a graph or panel for such input strings and variables. However, as your procedure grows and includes hundreds of functions it can become difficult to keep track of all the global strings and variables, especially if your are also using Igor procedures written by other people. If you have input data that is shared between many functions then it makes perfect sense to me to use global string and variables for that input data. Wide-Angle Neutron Spin Echo Spectroscopy.Any of these mistakes could leave the code "hanging" for lack of a proper reference point to wave, because that wave will not really exist at run time or it will exist somewhere in some location that is not the current data folder or it will not even be defined in the right way even when it does exist where it is supposed to exist. This is confusing at best and potentially damage prone at worse. ![]() Also, your Pulse code plays jostles around with "$" references to strings as wave names. This means, they are basically non-existent references. * Observations: Your panel/graph display code has no definitions for the "$" waves that are to be displayed in the graphs. Graphs must operate independently of a panel anyway (as you have now learned). * Suggestion: Display your graphs separately and debug their operation BEFORE you embed them in a panel. Secondly, as for the question about updating graph displays, I have a suggestion and some observations. They are only there when the panel is being generated in a "one-step-at-a-time" approach as per a command line entree. * Correspondingly remove all the unnecessary PauseUpdate, DelayUpdate, and Silent 1 commands in the ShowPulseInfoPanel() function. * Replace the Window PulseInfo() with a function call that is a bit more understandable, e.g. * Put return values at the end of the Functions (e.g. These references to folders will help keep the code "transportable" as you move from one folder to another or one experiment to another and accidentally change the location of the current data folder. * Learn to use DataFolderDFR functions to set or define locations of waves. I believe Macros are mostly considered obsolete except for backward compatibility. ![]() ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |