Talk:IGOR Pro Developers Working Group - Revision history

Ajj at 20:51, 12 December 2007

2007-12-12T20:51:41Z

← Older revision		Revision as of 20:51, 12 December 2007
Line 39:		Line 39:

	*this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.		*this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.
			** [ AJJ 2007-12-12 ] This has been started : [[:Category:Data Format Archive \| Data Format Archive]]

	''For "Like" #1:''		''For "Like" #1:''

Ajj at 20:44, 12 December 2007

2007-12-12T20:44:04Z

← Older revision		Revision as of 20:44, 12 December 2007
Line 11:		Line 11:
	'''What do we want? - things we really need to be able to do'''		'''What do we want? - things we really need to be able to do'''

	~~(1) avoid~~ code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.		#Avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.
			#documentation of file formats, so we can read each others' data (reduced data, ready for analysis)
	~~(2)~~ documentation of file formats, so we can read each others' data (reduced data, ready for analysis)		#...

	~~(3)~~...


	'''What would we like? - things that would make our lives easier (maybe)'''		'''What would we like? - things that would make our lives easier (maybe)'''
			#code to share - common readers, analysis models/modules, so we can all save some work.
	~~(1)~~ code to share - common readers, analysis models/modules, so we can all save some work.		#common internal data handling***
			#...
	~~(2)~~ common internal data handling***

	~~(3)~~...

Ajj at 20:41, 12 December 2007

2007-12-12T20:41:48Z

Ilavsky: /* Irena Data selection tool (JIL, 12/11/07) */

2007-12-11T22:24:33Z

Irena Data selection tool (JIL, 12/11/07)

← Older revision		Revision as of 22:24, 11 December 2007
Line 82:		Line 82:
	string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"		string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
	string UserNameString="Test me" //this is name for the user data type checkbox...		string UserNameString="Test me" //this is name for the user data type checkbox...
	string XUserLookup="r_:q_;" //~~wthis~~ is matching pattern for q vector name		string XUserLookup="r_:q_;" //this is matching pattern for q vector name
	string EUserLookup="r_:s_;" //this for error		string EUserLookup="r_:s_;" //this for error
	variable RequireErrorWaves =0 //do ~~nto~~ require error		variable RequireErrorWaves =0 //do not require error
	variable AllowModelData = 0 //disable generating of model data		variable AllowModelData = 0 //disable generating of model data
	//and this creates the controls.		//and this creates the controls. More description is in the package about other parameters....
	IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int~~;R_Int;SMR_Int;M_SMR_Int~~;","~~SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution~~;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)		IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;","AllCurrentlyAllowedTypes;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
	end		end

	This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...		This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...
	Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.		Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.

Ilavsky: /* Irena Data selection tool (JIL)*/

2007-12-11T22:21:06Z

Irena Data selection tool (JIL)

← Older revision		Revision as of 22:21, 11 December 2007
Line 58:		Line 58:
	''Items #3 and beyond are to be determined...''		''Items #3 and beyond are to be determined...''

	== Irena Data selection tool ==		== Irena Data selection tool (JIL, 12/11/07)==

	This is my attempt to document Irena data selection tools.		This is my attempt to document Irena data selection tools.
Line 65:		Line 65:
	Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.		Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

	Features:		'''Features:'''
	Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).		Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
	Know number of "default" data types: USAXS data, QRS data type, Irena results, user ~~defined~~ (passed as lookup list by programmer)~~, can~~ generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).		Know number of "default" data types: USAXS data, QRS data type, Irena results. But also enable programer to define user type (passed as lookup list by programmer). Can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
	Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.		Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
	Created controls can be moved or even hidden by programmer as appropriate.		Created controls can be moved or even hidden by programmer as appropriate.

	Files necessary:		'''Files necessary:'''
	IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.		IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.

Ilavsky: /* Irena Data selection tool */

2007-12-11T22:18:16Z

Irena Data selection tool

Ilavsky at 22:11, 11 December 2007

2007-12-11T22:11:41Z

← Older revision		Revision as of 22:11, 11 December 2007
Line 92:		Line 92:
	This creates following panel:		This creates following panel:
	[[Image:Example.jpg]]		[[Image:Example.jpg]]

	~~== Irena Data selection tool ==~~

	~~This is my attempt to document Irena data selection tools.~~

	~~'''Purpose of these tools (what are they suppose to do):'''~~
	Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

	~~'''Features:'''~~
	Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
	Know number of "default" data types: USAXS data, QRS data type, Irena results, user defined (passed as lookup list by programmer), can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
	~~Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.~~
	~~Created controls can be moved or even hidden by programmer as appropriate.~~

	~~'''Files necessary:'''~~
	~~IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.~~


	~~'''Use (code snippet):'''~~
	~~Window TestPanel2() : Panel~~
	~~PauseUpdate; Silent 1 // building window...~~
	~~NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"~~
	~~//this example sets User data type to QRS system and enables use of Q and intensity only~~
	~~string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"~~
	~~string UserNameString="Test me" //this is name for the user data type checkbox...~~
	~~string XUserLookup="r_:q_;" //wthis is matching pattern for q vector name~~
	~~string EUserLookup="r_:s_;" //this for error~~
	~~variable RequireErrorWaves =0 //do nto require error~~
	~~variable AllowModelData = 0 //disable generating of model data~~
	~~//and this creates the controls.~~

	~~IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","~~
	~~SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString~~
	~~,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)~~
	~~end~~

	~~This creates following panel: well, I would include it here, but I seem to be not allowed to upload it...~~

	OK, so in text... You get panel with 4 checkboxes for data type selection (Indra 2 = USAXS), QRS, Irena results, and "Test me" which is also QRS since we defined the user type this way here. Bellow is Popup with Folder selection and below that are 3 popups :"Wave with X axis data" and Y and Error. These create and set strings and variables in root:packages:testpackage2 folder, where your routine can pick them up. I usually have button with "Graph" or "Copy data" on the panel and that picks up the folder name and wave names and does what I desire.

	~~I'll try to add more later... First need to figure out the formating of this text here...~~

164.54.216.51: New section: Irena Data selection tool

2007-12-11T22:09:34Z

New section: Irena Data selection tool

← Older revision		Revision as of 22:09, 11 December 2007
Line 92:		Line 92:
	This creates following panel:		This creates following panel:
	[[Image:Example.jpg]]		[[Image:Example.jpg]]

			== Irena Data selection tool ==

			This is my attempt to document Irena data selection tools.

			'''Purpose of these tools (what are they suppose to do):'''
			Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

			'''Features:'''
			Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
			Know number of "default" data types: USAXS data, QRS data type, Irena results, user defined (passed as lookup list by programmer), can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
			Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
			Created controls can be moved or even hidden by programmer as appropriate.

			'''Files necessary:'''
			IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.


			'''Use (code snippet):'''
			Window TestPanel2() : Panel
			PauseUpdate; Silent 1 // building window...
			NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
			//this example sets User data type to QRS system and enables use of Q and intensity only
			string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
			string UserNameString="Test me" //this is name for the user data type checkbox...
			string XUserLookup="r_:q_;" //wthis is matching pattern for q vector name
			string EUserLookup="r_:s_;" //this for error
			variable RequireErrorWaves =0 //do nto require error
			variable AllowModelData = 0 //disable generating of model data
			//and this creates the controls.

			IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","
			SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString
			,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
			end

			This creates following panel: well, I would include it here, but I seem to be not allowed to upload it...

			OK, so in text... You get panel with 4 checkboxes for data type selection (Indra 2 = USAXS), QRS, Irena results, and "Test me" which is also QRS since we defined the user type this way here. Bellow is Popup with Folder selection and below that are 3 popups :"Wave with X axis data" and Y and Error. These create and set strings and variables in root:packages:testpackage2 folder, where your routine can pick them up. I usually have button with "Graph" or "Copy data" on the panel and that picks up the folder name and wave names and does what I desire.

			I'll try to add more later... First need to figure out the formating of this text here...

164.54.216.51: New section: Irena Data selection tool

2007-12-11T21:59:10Z

New section: Irena Data selection tool

← Older revision		Revision as of 21:59, 11 December 2007
Line 57:		Line 57:

	''Items #3 and beyond are to be determined...''		''Items #3 and beyond are to be determined...''

			== Irena Data selection tool ==

			This is my attempt to document Irena data selection tools.

			'''Purpose of these tools (what are they suppose to do):'''
			Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

			Features:
			Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
			Know number of "default" data types: USAXS data, QRS data type, Irena results, user defined (passed as lookup list by programmer), can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
			Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
			Created controls can be moved or even hidden by programmer as appropriate.

			Files necessary:
			IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.


			Use (code snippet):
			Window TestPanel2() : Panel
			PauseUpdate; Silent 1 // building window...
			NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
			//this example sets User data type to QRS system and enables use of Q and intensity only
			string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
			string UserNameString="Test me" //this is name for the user data type checkbox...
			string XUserLookup="r_:q_;" //wthis is matching pattern for q vector name
			string EUserLookup="r_:s_;" //this for error
			variable RequireErrorWaves =0 //do nto require error
			variable AllowModelData = 0 //disable generating of model data
			//and this creates the controls.
			IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
			end

			This creates following panel:
			[[Image:Example.jpg]]

129.6.122.149: New page: Hello All, Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excite...

2007-12-11T17:03:20Z

New page: Hello All, Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excite...

New page

Hello All,

Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...

Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.

--Steve

---------------------

'''What do we want? - things we really need to be able to do'''

(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.

(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)

(3)...

'''What would we like? - things that would make our lives easier (maybe)'''

(1) code to share - common readers, analysis models/modules, so we can all save some work.

(2) common internal data handling***

(3)...

'''What do we do about these things?'''

''For "Want" #1:''

- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

''For "Want" #2:''

- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

''For "Like" #1:''

- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

''For "Like" #2:''

- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

''Items #3 and beyond are to be determined...''

← Older revision		Revision as of 20:41, 12 December 2007
Line 31:		Line 31:
	''For "Want" #1:''		''For "Want" #1:''

	~~- the~~ suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.		*The suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

	- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.		*Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

	- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.		*So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

	- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.		*Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

	- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.		*XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

	''For "Want" #2:''		''For "Want" #2:''

	- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.		*this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

	''For "Like" #1:''		''For "Like" #1:''

	- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.		*If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

	- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.		*We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

	''For "Like" #2:''		''For "Like" #2:''

	- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.		*ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

← Older revision		Revision as of 22:18, 11 December 2007
Line 76:		Line 76:

	Use (code snippet):		Use (code snippet):
	Window TestPanel2() : Panel		Window TestPanel2() : Panel
	PauseUpdate; Silent 1 // building window...		PauseUpdate; Silent 1 // building window...
	NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"		NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
	//this example sets User data type to QRS system and enables use of Q and intensity only		//this example sets User data type to QRS system and enables use of Q and intensity only
	string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"		string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
	string UserNameString="Test me" //this is name for the user data type checkbox...		string UserNameString="Test me" //this is name for the user data type checkbox...
	string XUserLookup="r_:q_;" //wthis is matching pattern for q vector name		string XUserLookup="r_:q_;" //wthis is matching pattern for q vector name
	string EUserLookup="r_:s_;" //this for error		string EUserLookup="r_:s_;" //this for error
	variable RequireErrorWaves =0 //do nto require error		variable RequireErrorWaves =0 //do nto require error
	variable AllowModelData = 0 //disable generating of model data		variable AllowModelData = 0 //disable generating of model data
	//and this creates the controls.		//and this creates the controls.
	IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)		IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
	end		end

	This creates ~~following~~ panel:		This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...
	~~[[Image~~:~~Example~~.~~jpg]]~~		Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.