Igor Pro Wish List
| jamie | August 20, 2007 - 11:23 | ||
|---|---|---|---|
|
TabControl Procedure support in Igor Pro Both Adam Light and I have developed nice tabcontrol packages, that minimize the code needed to show and hide controls as tabs are clicked. Both work by making databases of which controls belong to which tab of a tab control. I think it would be nice if there was better support for that built right into Igor Pro. That is the methods to make and use tab control databases should be built into Igor Pro. You should be able to select controls for each tab from the dialog for editing tabcontrols, and the function to show and hide controls for each tab should be compiled C code part of Igor and run automatically when the tab control is used, with provisions for user overrides and additions, of course. Dr. Jamie Boyd, Ph.D. |
|||
| cdejoseph | August 23, 2007 - 07:17 | ||
|---|---|---|---|
|
|
|||
| cjmilne | August 25, 2007 - 03:31 | ||
|---|---|---|---|
|
Long filename support on Mac OS X. Yeah, I know this is a fairly long-standing 'feature request' that requires an enormous amount of re-coding on the part of Wavemetrics, but I still think it's important to emphasize how lovely it would be to not have to deal with imported data folders with 'corrupted' filenames or truncated wave names in the Data Browser. As of right now this is, by far, the most common reason my functions & procedures break. Probably more of a sad comment on my Igor programming skills then anything else. Chris |
|||
| August 28, 2007 - 14:41 | |||
|---|---|---|---|
|
|
|||
| jjweimer | September 3, 2007 - 18:43 | ||
|---|---|---|---|
|
It would be useful if escape codes would also be parsed in the unit designations. For example, doing the following ... SetScale d, 0, 0, "g/cm\\S3\\M", mywave followed by the equivalent of ... LabelAxis bottom, "Density [\\U]"would then automatically set the units with superscripting. One could then programmatically change super/subscripted units without needing to change the entire axis label. Also, in the Information that appears for waves in the Data Browser, the units of the wave scaling are shown, however the units of the data contents of the wave are not. The latter would be helpful for reviewing non-scaled data (such as might be used to plot a wave of density versus a wave of atomic mass). |
|||
| andyfaff | September 16, 2007 - 21:50 | ||
|---|---|---|---|
|
I would love Global fit to be able to handle multivariate fits, it only handles 1D data at the moment. Handling multivariate data would allow me to perform resolution smearing. The fitting routines funcfit and gencurvefit can already handle this. e.g. function myfitfunc(w,yy,xx,dx) Wave w,yy,xx,dx //set y as a function of x and dx //dx cannot be passed in directly at the moment. end |
|||
| September 28, 2007 - 10:48 | |||
|---|---|---|---|
|
I would love Global fit to be able to handle multivariate fits, it only handles 1D data at the moment. Handling multivariate data would allow me to perform resolution smearing. The fitting routines funcfit and gencurvefit can already handle this.
Andy- you're not the first to ask for this. Selecting the data sets would represent a significant effort in writing the GUI so I haven't tackled it yet. I've also been asked for structure fit functions in Global Fit, which is even harder :) At the moment I'm engaged in a top-to-bottom re-write of the multi-peak fit package... |
|||
| jjweimer | October 1, 2007 - 13:47 | ||
|---|---|---|---|
|
I sugggest extending the principle of using "one wave designation" for operations on scaled waves to a method of "linking" two (or more) waves via command such as
A simple example is that
would work as
or even simply
This would help streamline code that otherwise requires explicitly branching to different nomenclature in cases of scaled versus unscaled waves. |
|||
| tony | October 11, 2007 - 13:18 | ||
|---|---|---|---|
|
I'd like to be able to set an image plot so that pixels remain square. I don't want to use per unit absolute scaling because I want to be able to zoom in on arbitrary areas. But I can't find a way to make it work for log axes, because the axis range isn't linearly related to the number of image pixels, so when I zoom in the pixels end up being rectangular. So I'm looking for something like the ModifyGraph height or width plan mode that keeps image pixels square, regardless of axis scaling. I can think of workarounds involving multiple axes, but they're ugly. |
|||
| bech | October 20, 2007 - 13:10 | ||
|---|---|---|---|
|
As a general area where Igor could grow, I would suggest adding to the types of analysis that are supported by analysis-type environments. Currently, some of Igor's analytic capabilities -- FFTs, wavestats, filtering, histograms, image processing, etc -- have such support. But there are many other capabilities -- optimization, ODEs, PCA, wavelets, neuralnets, etc. -- that can be relatively complex and somewhat daunting for a beginner to use. My sense is that code for advanced algorithms such as those offered within Igor is commonly available and what distinguishes good programs is their ability to make these advanced algorithms available to a less-specialized audience. There is a much larger community of users who would apply these techniques if they had help. Even for people with more experience, ease of use counts. For example, I almost never use Igor to integrate ODEs "casually" (i.e., just to quickly see what the solution looks like) because it is much faster to do this in Maple. On the other hand, Igor is my first choice for curve fits because it's so fast (even before QuickFit). Of course, WM has limited resources, and one role a user community can play is in suggesting priorities. Of the capabilities that would best benefit from menu support, my vote for immediate priority would perhaps go to "optimize", as it is a common numerical operation, is complex to set up (requiring external function, specification of tolerances, methods, constraints), and often needs to be done in an exploratory, interactive way. John Bechhoefer |
|||
| jjweimer | January 3, 2008 - 14:48 | ||
|---|---|---|---|
Request for New /W=(...) BehaviorAs I posted on the Igor Pro mailing list, I would like to be able to use PLATFORM-AGNOSTIC, RELATIVE sizing values to set window and panel positions. As an example ... Display/W=[5,5,50,95] ... NewPanel/W=[50,5,95,95] ... (or an equivalent) ... would put up a panel occupying the right 50% of the screen and a graph occupying the left 50% of the screen, with 5% offsets all around the screen edges, regardless of MacOS or WinXX system used. Also, the behavior of /W=(...) for the above two commands (as well as Edit/W=(...)) is currently inconsistent between panels and graphs. In graphs (and tables), the /W=(...) inputs are required in points, whereas in panels, the inputs are required in pixels. Conversion is via points = pixels*72/ScreenResolution On MacOS, ScreenResolution usually *always* returns 72. Therefore, graphs and panels defined with /W=(10,10,100,100) will always both be the same size. On WinXX, ScreenResolution can return 96 or 120 (or some other funky value), so that /W=(10,10,100,100) graphs and panels will be different sizes. This (platform+object)-dependent behavior plays havoc when trying to code object-placement routines that are both general purpose and cross-platform compatible. -- [ last edited January 3, 2008 - 15:42 ]
|
|||
| jjweimer | January 10, 2008 - 15:14 | ||
|---|---|---|---|
Feature Requests for Edit Windows/Procedure FilesProcedure edit windows have buttons to Show Info, Lock/Unlock, and Magnify Window (in addition to popup menus). Also having a button to Save Procedure would be helpful. In addition, perhaps procedures could be Password Protected against editing, not just locked. -- |
|||
| newbielol | February 2, 2008 - 19:49 | ||
|---|---|---|---|
|
|
|||
| nleclercq | February 5, 2008 - 07:37 | ||
|---|---|---|---|
|
TabControl Procedure support in Igor Pro
Both Adam Light and I have developed nice tabcontrol packages, that minimize the code needed to show and hide controls as tabs are clicked. Both work by making databases of which controls belong to which tab of a tab control. I think it would be nice if there was better support for that built right into Igor Pro. That is the methods to make and use tab control databases should be built into Igor Pro. You should be able to select controls for each tab from the dialog for editing tabcontrols, and the function to show and hide controls for each tab should be compiled C code part of Igor and run automatically when the tab control is used, with provisions for user overrides and additions, of course. Dr. Jamie Boyd, Ph.D. +1 [ last edited February 5, 2008 - 07:39 ]
|
|||
| nleclercq | February 5, 2008 - 07:42 | ||
|---|---|---|---|
|
|
|||
| February 5, 2008 - 09:57 | |||
|---|---|---|---|
|
I have a dream... a 100% thread safe Igor implementation!
Everything should be thread safe so that we could add some highly threaded XOPs dealing whith the asynchronous nature of the real world! I'm afraid you will need to keep dreaming for some time. Anything relating to the user interface (all windows) is not happening any time soon. |
|||
| jjweimer | February 11, 2008 - 17:39 | ||
|---|---|---|---|
Feature Request to Hide Procedure File NamesAs I develop more stuff, my list of included procedure files is beginning to over-flow to a frustrating level. I am aware that procedures developed as Independent Modules do not normally show in the list, however Independent Modules have their own limitations in interacting with other packages. I am also aware, I could lump all my code into one long procedure file, however that is also limiting in development. I would therefore like to have another way to hide the name of a procedure file from being shown in the Windows: Procedure Windows menu list (ie, #pragma ListName='normal (default)' or 'hidden'). This would also serve as a first step to keep the procedure from accidentally being changed by other users, since it would not show up in their lists either. -- [ last edited February 11, 2008 - 17:40 ]
|
|||
| aclight | February 11, 2008 - 18:03 | ||
|---|---|---|---|
|
I would therefore like to have another way to hide the name of a procedure file from being shown in the Windows: Procedure Windows menu list (ie, #pragma ListName='normal (default)' or 'hidden'). This would also serve as a first step to keep the procedure from accidentally being changed by other users, since it would not show up in their lists either. Jeff: Have you looked at DisplayHelpTopic "Invisible Procedure Files"? |
|||
| jjweimer | February 11, 2008 - 18:26 | ||
|---|---|---|---|
|
...
Jeff: Have you looked at DisplayHelpTopic "Invisible Procedure Files"? And therein I find ... This section is for very advanced Igor programmers. Everyone else can skip it. If you create a package of Igor procedures to be used by novice Igor users, you may want to hide the procedures to reduce clutter or to eliminate the possibility that they might inadvertently change them. You can do this by creating invisible procedure files. ... which I will argue only goes to show that I am still not an advanced enough Igor programmer :-) Thanks!!!! -- |
|||
| jjweimer | March 13, 2008 - 12:27 | ||
|---|---|---|---|
|
Jeff: Have you looked at DisplayHelpTopic "Invisible Procedure Files"? I've played with this option a bit more. My request still stands for being able to have a #pragma directive within a procedure file itself as a less problematic way to hide the procedure file from showing in the procedure menu list. -- |
|||
| RGerkin | March 22, 2008 - 17:08 | ||
|---|---|---|---|
|
For panels with a lot of controls, Igor does a pretty good job of placing each control after the previous one, while fitting it in the dimensions of the panel, in the absence of specifying positions with the "pos" keyword. However, when I want to change one of them, I have to first figure out its exact position, and then enter some variation of that into the code manually. If a control above that is changed, inserted, or deleted, I will once again have to set new absolute coordinates. Playing around with control locations in tools mode is good for certain things, but the subsequently generated windows recreation macro will have values hardcoded that I previously used constants for, which makes for inflexible code. So, I propose the following additional syntax for controls: In contrast to pos={x,y}, the += syntax would just move the control x and y pixels away from the default position as guessed by Igor. Since Igor's guesses always depend on the controls that came before the controls in question, this would always put my controls in the correct place with little effort. In fact, writing the code for a new panel would be as simple as ignoring all the "pos" keywords in my controls on the first pass, then looking at the mostly reasonable Igor-generated locations, and then adding a few pos+={x,y} additions to controls as needed. This syntax is not unprecedented, as ListBoxes already have both width= and width+= keywords for a slightly different application. |
|||
| andyfaff | March 22, 2008 - 20:16 | ||
|---|---|---|---|
|
Ricks suggestion is a good one. However, I want to go one step further. I've always been impressed by the layout managers in things like Java. I'm wondering if it would be possible to have such a thing for IGOR? We can already have subpanels, what we need is some way of packing controls into the subpanel, then packing the subpanels together. This layout manager would control all the resizing aspects, etc. This would be a hell of a lot of work, but well worth it in the end. I even reckon it would be possible to do something in an IGOR procedure that would achieve this, but one would have to be a smokin' programmer. |
|||
| jjweimer | March 24, 2008 - 07:43 | ||
|---|---|---|---|
|
...
So, I propose the following additional syntax for controls: pos+={x,y} In contrast to pos={x,y}, the += syntax would just move the control x and y pixels away from the default position as guessed by Igor. ... To which I add the request for a command of the style ... ModifyPanel origin={x,y} as a way to set a "default position" (origin) for such pos+={x,y} commands. -- |
|||
| jjweimer | March 26, 2008 - 13:31 | ||
|---|---|---|---|
Request Change in New:Notebook Dialog BoxI request an improvement be made in the New:Notebook dialog box to include the ability to set Title AND Name, KILL status, and Show/Hide Ruler (when formatted is selected) up front. Additions in the dialog box for setting left, right, top, bottom coordinates (or perhaps just width and height) would also be appreciated. An IgorMenuHook code segment that shows part of this is here. A package that shows a sample desired format is here. -- [ last edited March 26, 2008 - 14:48 ]
|
|||
| jjweimer | April 10, 2008 - 08:26 | ||
|---|---|---|---|
|
I sugggest ...
An package that addresses this issue using functions (rather than operations) is now posted as Link Display. -- |
|||
| jjweimer | May 19, 2008 - 13:18 | ||
|---|---|---|---|
Request Features in Data BrowserThe following would be useful as settings in the preferences: 1) A checkbox to Show/Hide the Packages folder 2) A way to sort ascending/descending over two or three sequentially selectable options, ie three rows of two popups ... 1st -> [Name/Creation Date/Modification Date/Type] -> [Ascending / Descending] Having these settings remembered across all instances and being able to set/change them programmatically would be great too! -- |
|||
| May 21, 2008 - 14:20 | |||
|---|---|---|---|
Request Features in Data Browser1st -> [Name/Creation Date/Modification Date/Type] -> [Ascending / Descending] Having these settings remembered across all instances and being able to set/change them programmatically would be great too! What would the second and third menus do? And are you referring to the Data Browser (from the Data menu) or to the Dialog Wave Browser that appears in various dialogs? John Weeks |
|||
| jjweimer | May 22, 2008 - 14:57 | ||
|---|---|---|---|
|
What would the second and third menus do? And are you referring to the Data Browser (from the Data menu) or to the Dialog Wave Browser that appears in various dialogs? I am referring to the Data Browser. The second (and third and ...) menu selections would allow sequential sorting, first on names, then on creation dates, then on ... Now that I think about it for this case, since data folders cannot contain objects of the same name, I am likely thinking of a situation where "hiding" of parent folders is possible, so that a DataFolder structure ... root could be "collapsed" to show just the (sequentially sorted) waves ... .. file01 (2008.May.12) (perhaps I've been spending too much time at my PDA ToDo list ... :-) ) -- [ last edited May 22, 2008 - 15:06 ]
|
|||
| tony | June 9, 2008 - 18:03 | ||
|---|---|---|---|
|
|
|||
| jjweimer | June 19, 2008 - 13:24 | ||
|---|---|---|---|
Check for StructureI have a procedure file A that only serves to define a structure GlobalParams. I have another procedure file B that includes a function UseGPStructure to access the structure. The problem is, I also want procedure file B to be able to stand on its own (ie, not have to #include "A"). Most likely, I would like a way to check for a STRUCTURE so as to do ... #if(StructExists("GlobalParams")) Function UseGPStructure(gPS) STRUCT GlobalParams &gPS ... end #endif As a work-around, I might put an empty static function at the top of procedure file A (as a module) and check for its existence. -- |
|||
| wholmgren | July 21, 2008 - 14:08 | ||
|---|---|---|---|
|
|
|||
| patarroyo | July 30, 2008 - 15:53 | ||
|---|---|---|---|
|
A few requests: 1. It would be nice to be able to use the data browser in such a way that it limits which waves it displays based on a user-entered string. I typically have a lot of waves in a given experiment, so browsing through all of them to find the ones I want for graphing or curve-fitting can be tedious, especially since there is no scroll-functionality via the mouse wheel. Instead, I have to click on the arrows and hold it while it scrolls. I'd like to enter the part of my waves' names that is unique to subset of waves so that only those waves are displayed. 2. Curve fitting parameter memory- why is it that in Igor 6, when I curve fit, and want to go back to change a setting (say which function I use, or the fit range) I have to manually reselect my x and y waves, as well as any weighting waves? Igor 4 did not do this, it kept the previous waves in memory. Is there an option that I am somehow missing here? 3. A better/easier way to control font sizes in Annotations. It gets tedious to manually have to enter tags to enlarge or shrink fonts over and over again. Again, maybe I am missing out on already existing functionality. |
|||
| jeff | August 7, 2008 - 08:03 | ||
|---|---|---|---|
|
|
|||
| August 8, 2008 - 17:29 | |||
|---|---|---|---|
|
A few requests:
2. Curve fitting parameter memory- why is it that in Igor 6, when I curve fit, and want to go back to change a setting (say which function I use, or the fit range) I have to manually reselect my x and y waves, as well as any weighting waves? Igor 4 did not do this, it kept the previous waves in memory. Is there an option that I am somehow missing here? Hm. It's supposed to remember them. Perhaps you could send me a detailed example illustrating the problem. You would probably need to send me an experiment file with the data, also. John Weeks |
|||
| RGerkin | August 12, 2008 - 14:09 | ||
|---|---|---|---|
|
|
|||
| RGerkin | August 14, 2008 - 09:56 | ||
|---|---|---|---|
|
|
|||
| August 16, 2008 - 07:13 | |||
|---|---|---|---|
|
I would like to see Checkboxes be linkable to waves as can be done with SetVariables (e.g. SetVariable mySet variable=myWave[3]). You can sort of get around this with ListBoxes, but they can only be so small, and aren't always appropriate.
I looked into this but it looks to be pretty painful. It might be easier to make SetVariable look and act like a CheckBox. I suggest not using any global object -- just query the CheckBoxes directly. |
|||
| RGerkin | August 20, 2008 - 14:55 | ||
|---|---|---|---|
|
I have been moving in the direction of querying my controls directly, especially now that SetVariables can be unattached. The only downside to this is storing the information in the event that the window containing the control is killed. I have been dabbling in StructPut/StructGet to store control information as in the Graph Browser example. In general, I'd like to use Structures more often, especially to facilitate saving and loading preferences, but looping through structure fields in user functions is problematic since structure fields can't be accessed with $ syntax. Is it reasonable to just put all controls of a similar type in an array? e.g. Structure MyControlPanel And then access with MyControlPanel.Checkbox[i]. The decision here would be how to determine that array index "i" corresponds to the checkbox for, e.g. "High-Pass Filter". I suppose this information could also be stored in the structure, or possibly in the window user information. Any thoughts? |
|||
| aclight | August 20, 2008 - 18:03 | ||
|---|---|---|---|
|
Rick: I've taken to using a method similar to what's found in the GetGrfBrowserGlobals() function of GraphBrowser.ipf. You may need to issue the following on the command line to be able to view this procedure, since it's an independent module. SetIgorOption IndependentModuleDev=1 The actual data values are stored in global variables within a data folder, but a structure is used to make accessing them in control action procedures and other functions quite easy. |
|||
| RGerkin | August 22, 2008 - 15:05 | ||
|---|---|---|---|
|
I would like to be able the option to have layouts track changes in graph names. As far as I know, the current best way to do this is to search (old object name) and replace (new object name) in the layout recreation macro and recreate the layout. I could make this myself if I only I had access to an operation that created a list of recent name changes. Since I always use DoWindow /C for graph name changes, even simpler would be a flag for DoWindow to create S_oldname, S_newname, with I could access with a layout hook function to regenerate the layout with the correct object names. I am always changing graphs from names like "Figure5A" to "Figure 5C", and I want this to reflect in the layout "Figure5". A huge time-saver for producing figures for journal articles, a process which usually involves changing figure panels and locations a zillion times before submission. Rick |
|||
| aclight | August 22, 2008 - 16:13 | ||
|---|---|---|---|
|
I would like to be able the option to have layouts track changes in graph names. As far as I know, the current best way to do this is to search (old object name) and replace (new object name) in the layout recreation macro and recreate the layout. I could make this myself if I only I had access to an operation that created a list of recent name changes. Since I always use DoWindow /C for graph name changes, even simpler would be a flag for DoWindow to create S_oldname, S_newname, with I could access with a layout hook function to regenerate the layout with the correct object names.
I am always changing graphs from names like "Figure5A" to "Figure 5C", and I want this to reflect in the layout "Figure5". A huge time-saver for producing figures for journal articles, a process which usually involves changing figure panels and locations a zillion times before submission. Rick You might be able to do what you want to do by creating a named hook function (structure based) that responds to the "renamed" event. You'd want to make sure that all graph windows in your experiment are attached to this hook. That's easy to do for graphs that already exist. For future graphs, you can either add this hook to the graph after you create it from a function, or use the AfterWindowCreatedHook. |
|||
| cjmilne | August 30, 2008 - 08:23 | ||
|---|---|---|---|
|
Chris: Long file names is on my short list of things to do. I've had trouble getting to it because of other things on the short list though.
Well I'm not sure if this is the first item on this wish list to be fulfilled, but in yesterday's mailing list digest I happened across this happy news from a certain Howard Rodstein:
To which I say Huzzah ! This is absolutely brilliant news & I would like to sincerely thank Wavemetrics & Howard for doing something that must have been extraordinarily painful. I will be alpha-testing this version immediately & with great joy. Chris EPFL/PSI [ last edited August 30, 2008 - 08:24 ]
|
|||
| September 3, 2008 - 16:25 | |||
|---|---|---|---|
|
I would live being able to load 24bit binary sample files, not only the 8-16-32 bit samples. You can do this by loading the data as unsigned byte data and then combining the bytes. Assuming that wave0 is unsigned byte, this will combine it into wave1: Variable numBytes = numpnts(wave0) This assumes that your original data was little-endian (least-significant byte first). If it was big-ending, swap the Also this assumes that your data was unsigned. If it was signed then you need a more complex approach that tests the high bit of the high byte to determine the sign. |
|||
| September 3, 2008 - 16:31 | |||
|---|---|---|---|
|
I would like to be able the option to have layouts track changes in graph names . . .
I am always changing graphs from names like "Figure5A" to "Figure 5C", and I want this to reflect in the layout "Figure5". Rick It will track it if you can remember to recreate the layout before changing the graph name. |
|||
| September 3, 2008 - 16:33 | |||
|---|---|---|---|
|
would like to sincerely thank Wavemetrics & Howard for doing something that must have been extraordinarily painful.
It was pretty painful. It took two months and thousands of changes to the program. I'm glad to have it behind me. Now we'll see how many bugs I introduced in the process. |
|||
| RGerkin | September 5, 2008 - 11:51 | ||
|---|---|---|---|
|
I would like to be able the option to have layouts track changes in graph names . . .
I am always changing graphs from names like "Figure5A" to "Figure 5C", and I want this to reflect in the layout "Figure5". Rick It will track it if you can remember to recreate the layout before changing the graph name. Sorry, I don't understand what you are saying here. If I recreate the layout before changing the graph name, I have an identical copy of the layout I had before, which still won't update other than to show an empty placeholder. |
|||
| September 5, 2008 - 17:51 | |||
|---|---|---|---|
|
|
|||
| September 6, 2008 - 08:17 | |||
|---|---|---|---|
|
It would be useful if escape codes would also be parsed in the unit designations. For example, doing the following ...
SetScale d, 0, 0, "g/cm\\S3\\M", mywave followed by the equivalent of ... LabelAxis bottom, "Density [\\U]"would then automatically set the units with superscripting. One could then programmatically change super/subscripted units without needing to change the entire axis label. This is now available in the latest pre-beta of 6.1. |
|||
| fabrizio | September 10, 2008 - 15:23 | ||
|---|---|---|---|
|
- *nix-style tab autocompletion (of procedure, function, wave, variable names) in the command window would be sweet - not sure if thats a wish, if I just didn't find out how to do it, or if it's an OS issue: a function that lets the user select multiple files (with 'shift' and 'ctrl') in a file dialog and returns a list containing the selected filenames for further processing; for now I use 'open/R' and 'S_filenames', which seems a bit overkill and does (naturally) not allow multiple files to be selected at once. I am aware of the 'Multiple file loader front end' posted on this website, but I think it would be nice to use the OS file selection tools |
|||
| September 10, 2008 - 18:50 | |||
|---|---|---|---|
|
|
|||



Joined: 2007-06-21
Location: United States
This topic will serve as the IgorPro wish list. Feel free to make suggestions for features that you think would improve Igor Pro.
Note: This discussion is for Igor Pro suggestions only. To make suggestions for IgorExchange.com, please see the IgorExchange.com Wish List discussion.