Igor Pro Wish List

Share icon

Mon, 07/09/2007 - 07:38 pm

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.
Larry Hutchinson wrote:
jjweimer wrote:
It would be useful if escape codes would also be parsed in the unit designations....


This is now available in the latest pre-beta of 6.1.



Thanks! This will be of special and immediate benefit to the SpXZeigR routines.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAH

September 10, 2008 at 07:06 pm - Permalink

Request to show current function/macro when editing a procedure.

When dealing with many functions/macros that are often very long it would be nice if the procedure window would show the name of the function/macro you are currently editing. This would be especially handy when jumping into the middle of some code from a search query.

September 26, 2008 at 06:31 am - Permalink

I would like to see an Igor error generated whenever a dimension label is not found when accessing waves. Whilst the numerical access choice that that WM made all those years ago, to clip to legal values, can be made useful (e.g. wave0[INF] accesses the last element irrespective of wave0's size), the current behaviour of silently defaulting to element zero whenever a dimension label doesn't exist, is almost never what is wanted. This introduces hard-to-find bugs in code when a dimension label is mispelled, but is otherwise expected to exist without need for testing.

Having to test for dimension label existence with findDimLabel() takes away most of the utility of labels.
An alternative strategy would be to have a similar flag to NVAR SVAR WAVE checking in the debugger, but I would prefer an error to be generated.

Regards,
Patrick.

October 25, 2008 at 08:03 pm - Permalink

I would like to see another line option for Tag annotations, with the line arrow from the attachment point to the tag (opposite from current mode). Perhaps this could be done with a /L=3 flag, or a new /TL = linespec definition.

October 28, 2008 at 05:37 am - Permalink

s.r.chinn wrote:
I would like to see another line option for Tag annotations, with the line arrow from the attachment point to the tag (opposite from current mode). Perhaps this could be done with a /L=3 flag, or a new /TL = linespec definition.


Granted. Will be in next beta of 6.1.

And 4 will be both directions.

But unless I add some fairly complex code, it will not be useable with Middle Center anchor mode as the arrow will be underneath the tag.

November 3, 2008 at 11:44 am - Permalink

Larry Hutchinson wrote:
jjweimer wrote:
It would be useful if escape codes would also be parsed in the unit designations....


This is now available in the latest pre-beta of 6.1.





Thanks -- this will be really useful...

Another request; in notebooks have control return execute the current line.

Thanks again for the escape codes

Jim

November 6, 2008 at 11:20 am - Permalink

Jim_Reid wrote:

Another request; in notebooks have control return execute the current line.

Thanks again for the escape codes

Jim


Huh? Isn't that what it already does?

November 7, 2008 at 09:39 am - Permalink

Larry Hutchinson wrote:
Jim_Reid wrote:

Another request; in notebooks have control return execute the current line.

Thanks again for the escape codes

Jim


Huh? Isn't that what it already does?



Er - yes it does. I'll blame an extended moment of stupidity when I've been pressing apple-return...

Jim

November 8, 2008 at 12:42 am - Permalink

hrodstein wrote:
... Feel free to make suggestions for features that you think would improve Igor Pro. ...


When editing graphs, Igor lists the name of each y-wave, but does not show against which x-wave each y-wave was plotted. When editing graphs I created a year ago, I often have difficulties reconstructing what exactly I plotted, and I find this a severe disadvantage compared to other x-y plotting software.

Suggestion: show the name of the x-wave used to plot the y-wave in the "Modify Trace Appearance" dialogue, because the connection between the x-wave and the y-wave is really a Trace property. You may make it visible via a button - similar to the "Set as f(z)..." button - where one enters a new dialogue to change to another x-wave, to shift or multiply the x-wave by a freely selectable value, make the x-y wave pair visible as a table, etc.

Pietro (a happy user)

November 16, 2008 at 11:06 am - Permalink

hrodstein wrote:
... Feel free to make suggestions for features that you think would improve Igor Pro. ...


When editing Tags, TextBoxes etc. in the "Modify Annotation" dialogue, make all Tags, TextBoxes etc. selectable at the top left of the panel similar as you make all Traces selectable in the "Modify Trace Appearance" dialogue. This would save a lot of time when editing a few annotations in a row. A problem may be the naming of Tags etc. My suggestion is, to quote the beginning of the Annotation. By selecting several Tags etc. at once, one may be able to change a few of their properties at once, similar as it is possible with Traces.

Pietro

November 16, 2008 at 11:16 am - Permalink

Pietro_Altermatt wrote:

When editing graphs, Igor lists the name of each y-wave, but does not show against which x-wave each y-wave was plotted. When editing graphs I created a year ago, I often have difficulties reconstructing what exactly I plotted, and I find this a severe disadvantage compared to other x-y plotting software.

Suggestion: show the name of the x-wave used to plot the y-wave in the "Modify Trace Appearance" dialogue, because the connection between the x-wave and the y-wave is really a Trace property. You may make it visible via a button - similar to the "Set as f(z)..." button - where one enters a new dialogue to change to another x-wave, to shift or multiply the x-wave by a freely selectable value, make the x-y wave pair visible as a table, etc.

Pietro (a happy user)

Actually, this is already the case. When you click on a trace in the Modify Trace Appearance dialog, in the box in the bottom of the dialog the full paths of the y vs x waves is given (or, if it's just a single wave you plotted, the path to that wave is displayed). In addition, if you're using windows, you can Shift-F1 and click on a trace in a graph, and a yellow window will pop up that displays information about the trace.

November 16, 2008 at 01:18 pm - Permalink

I would like access to static structures using the "modulename#staticStructure" paradigm used for static functions. Then I can safely name a structure "global" or "data" in any package, like I do for "main", "init" and other common names in functions.

I suspect the 'constant' and 'strConstant' variables don't really exist after compilation so it is less likely they are available in this way.

Patrick

November 20, 2008 at 10:12 pm - Permalink

patg wrote:
I would like access to static structures using the "modulename#staticStructure" paradigm used for static functions. Then I can safely name a structure "global" or "data" in any package, like I do for "main", "init" and other common names in functions.
Patrick


According to Programming.ihf, in the "Structures in Functions" topic,
The Structure keyword can be preceded with the Static keyword to make the definition apply only to the current procedure window. Without the Static designation, structures defined in one procedure window may be used in any other.


This is using Igor 6.10B03, but I think I've also used static structures for some time now in some of my procedure files, so I think Igor can already do what you want.

November 21, 2008 at 07:37 am - Permalink

It is correct that static structures exist (and I use them widely). What is not available is access to these static structures from another module. e.g. if a static structure called 'foo' is defined in a different module called 'OtherModule', then

#pragma moduleName thisModule

FUNCTION test()
   STRUCT OtherModule#foo      ss;
END

will not compile ("no such structure exists", highlighting the word 'OtherModule').

A similar situation applies to FUNCREF declarations, but in that case you can allocate the reference to a static function, using a nonstatic stub function for the declaration:

   FUNCREF nonStaticStub   ref = OtherModule#staticFunction;

which gets around any problems.

November 23, 2008 at 05:46 pm - Permalink

a flag for MoveWave that can overwrite a name how already exists at the destination.

December 1, 2008 at 12:36 pm - Permalink

purozongo wrote:
a flag for MoveWave that can overwrite a name how already exists at the destination.

That would add consistency with most other wave manipulation commands. In the interim the pair of commands
  duplicate/O srcWave, destWave; killWaves srcWave;
can be used, and could be made into a small utility function.
Regards, Patrick.

December 4, 2008 at 02:31 pm - Permalink

I think some simple UDP/IP functionality would be useful for real-time data acquisition.

December 15, 2008 at 10:12 am - Permalink

UDP communication may be possible, as far as I can see setting up a socket like that requires little modification to SOCKIT. However I would need to think about implications towards the synchronous communication operations.

If the original poster could contact me that would be great and we could work something out.


Andy

December 15, 2008 at 07:51 pm - Permalink

patg wrote:
I would like access to static structures using the "modulename#staticStructure" paradigm used for static functions. Then I can safely name a structure "global" or "data" in any package, like I do for "main", "init" and other common names in functions.

I suspect the 'constant' and 'strConstant' variables don't really exist after compilation so it is less likely they are available in this way.

Patrick


I have run into a similar problem. To the best of my knowledge, you can't access a structure declared in an independent module from outside of that module. Shouldn't it be possible to implement the moduleName#structureName syntax for independent modules much as we can already use the moduleName#functionName syntax?

January 8, 2009 at 08:55 am - Permalink

The use of structures is limited in a few ways. One is that I can't use $ syntax to access structure members, but Larry has indicated that the compiler really needs to know at compile time what kind of a member is being accessed. Does it need to know both the position and the size of the element being accessed? In other words, what if we specified the type, e.g. int16, at compile time, but the name at run time?

Some others I think can certainly be implemented and would be useful. One is the ability to put default Structure values in the structure declaration, e.g.:

Structure myStruct
int16 myInt=5
char myStr[10]="Hello"
EndStructure

Another is the ability to list the members of a structure and their types, with a function like StructInfo that would return a StringByKey-able string.

January 8, 2009 at 09:10 am - Permalink

Hi everyone. I wanted to let you know that I'm locking this thread, because I've created a new Igor Pro wish list forum for discussing Igor Pro wish list items. This will allow each suggestion to be its own thread and should make the discussion much easier to follow.

January 10, 2009 at 10:54 am - Permalink