Hi Marcus,
Your careful wording of "no automatic listing of functions..." leads me to suspect that you already know this, but let me mention it anyway in case others looking at this request don't already know. In the DIAdem SCRIPT panel, where the script editor that ships with DIAdem is housed, you can either hit the <Ctrl-Space> key sequence or right-click and choose the "CodeCompletion" context menu item to pop up a list much like what you request. I agree that this is more elegant in other editors where it pops up without having to explicitly invoke it, but at least it's there as an option.
It is very true, as you assert, that code completion does not show the methods and properties of custom object variables which have been declared in an external library and dynamically included at run time with the ScriptInclude() command. This would indeed by an excellent improvement in the script editor that ships with DIAdem, and I would personally love to see this happen.
The bottom line, though, in all deliberations regarding the merits of possible future features in the DIAdem script editor, is that with the advent of python scripting in DIAdem, the focus is definitely shifting away from editing DIAdem scripts in the DIAdem SCRIPT panel and moving toward editing DIAdem scripts in external script editors, such as Visual Studio Code or PyCharm, etc. R&D is choosing to focus its efforts on core DIAdem strengths and not on reimplementing the excellent script editing features that are already available for free. R&D will, however, be introducing DIAdem features that make it easier to navigate the shift from DIAdem execution/display to external script editor and back. For years, customers who wanted serious DIAdem script debugging have been using external script editors and connecting DIAdem execution with them via the just-in-time debugging stack. We are now formalizing this approach and making it more accessible with improved integration, new icons, documentation, etc.
We're sorry to disappoint you on your request, but we wanted you know the reasons behind this choice, as well as the potential benefits you might receive by NI taking this alternative path.
Thank you for your feedback,
Brad Turpin
Principal Technical Support Engineer
NI
Hi Marcus,
Your careful wording of "no automatic listing of functions..." leads me to suspect that you already know this, but let me mention it anyway in case others looking at this request don't already know. In the DIAdem SCRIPT panel, where the script editor that ships with DIAdem is housed, you can either hit the <Ctrl-Space> key sequence or right-click and choose the "CodeCompletion" context menu item to pop up a list much like what you request. I agree that this is more elegant in other editors where it pops up without having to explicitly invoke it, but at least it's there as an option.
It is very true, as you assert, that code completion does not show the methods and properties of custom object variables which have been declared in an external library and dynamically included at run time with the ScriptInclude() command. This would indeed by an excellent improvement in the script editor that ships with DIAdem, and I would personally love to see this happen.
The bottom line, though, in all deliberations regarding the merits of possible future features in the DIAdem script editor, is that with the advent of python scripting in DIAdem, the focus is definitely shifting away from editing DIAdem scripts in the DIAdem SCRIPT panel and moving toward editing DIAdem scripts in external script editors, such as Visual Studio Code or PyCharm, etc. R&D is choosing to focus its efforts on core DIAdem strengths and not on reimplementing the excellent script editing features that are already available for free. R&D will, however, be introducing DIAdem features that make it easier to navigate the shift from DIAdem execution/display to external script editor and back. For years, customers who wanted serious DIAdem script debugging have been using external script editors and connecting DIAdem execution with them via the just-in-time debugging stack. We are now formalizing this approach and making it more accessible with improved integration, new icons, documentation, etc.
We're sorry to disappoint you on your request, but we wanted you know the reasons behind this choice, as well as the potential benefits you might receive by NI taking this alternative path.
Thank you for your feedback,
Brad Turpin
Principal Technical Support Engineer
NI