07-22-2009 11:19 AM
07-23-2009 12:22 AM
Ya, even I was struggling with the same problem.
So is it recommended that we remove any of the scripting based VIs before building an exe ?
07-23-2009 12:28 AM
Since they mostly won't do anything but cause an error when executed, why leave them in an let your application be blown up by their size, even if you do never execute their code path for any reason inside the executable?
Rolf Kalbermatter
07-23-2009 07:26 AM
Look in the LabVIEW Help for VI Server Property and Method Characteristics. This is a description of all the characteristics a property or method can have. Now navigate to any property or method. These characteristics, and their values for that property, are listed in a grid. This will tell you whether or not you can use the property or method in an EXE or on RT, for example (the issue is not limited to scripting properties and methods).
Unfortunately, most scripting properties are not listed in the LabVIEW help. However, the pertinent characteristics are usually listed in the context help (hit Ctrl-H on Windows or select Help»Show Context Help to show context help, hover your mouse over the object to see it.). If the property or method is not documented correctly, try it out, but also post a message to the scripting message boards so we can be sure to correct the issue.
09-08-2009 12:39 PM
Thanks for this thread, and the codes that you've shared.
I also agree with Andre in the second post.
Likewise, it was interesting to read the latest posts in this thread which highlight an "issue" that not all methods can be included in an EXE or using RT. I didn't know/think this is also possible.
So thanks Dr Gray again for mentioning about the list of such methods.
Have bookmarked the thread, and will dig into it more once I am done with my present work.
Kudos to many above.
09-08-2009 02:08 PM
All these properties and methods are hidden for a very good reason. They were almost inaccessible for a long time outside NI. Some of this stuff is able to trash your system, others just crash, and everything is undocumented. And it is really a waste of time if you are learning how to write code. If you want to trash your system, I would advise using a big hammer instead of scripting. This has the advantage, that you can call the support of the hammer manufacturer to assist you. As far as I know, there is no official support on scripting by NI (There always has been some kind of unoffical, sometimes yelling: 'No, don't do that!').
But:
It is essential for those how need to interfere with the Developement environment (IDE) to write autogenerating code or test routines for their software. But most of the times the code stays small for the reasons stated above.
And:
If you go to these wild lands, make sure you are hanging around at LAVA in the night.
Felix
09-08-2009 02:22 PM
That was a practical advice and thanks for that Felix.
Initially I understood that some of the methods and properties that we use "officially," cannot be included in the EXE or RT. As for the experimental codes and scripting, yea that's a wild call. But I would certainly go there once I make myself equipped with proper knowledge of basics, so that I don't get confused so easily. 🙂
09-08-2009 02:39 PM
1. There are several properties the H-Window lists as not available in the RTE.
2. Scripting is not about getting confused, but about getting lost. You suddenly get 1000 of properties some developer inside NI did need for some very specific thing. 90% you don't need (that's confusion + lost), 9% will crash because you don't know how to use them and it's not documented (lost), 0.9% are the things that give you benefit but the remaining 0.1% will be destructive.
I actually decided to use 'scripting' after this thread, when I knew why I want it and what I want to do. Still I am lost too many times even with the help of NI R&D (and I guess they sacrifice some free/unpaid time). And I also do it apart from my work project (won't risk).
Felix
09-08-2009 02:56 PM - edited 09-08-2009 02:58 PM
F. Schubert wrote:1. There are several properties the H-Window lists as not available in the RTE.
2. Scripting is not about getting confused, but about getting lost. You suddenly get 1000 of properties some developer inside NI did need for some very specific thing. 90% you don't need (that's confusion + lost), 9% will crash because you don't know how to use them and it's not documented (lost), 0.9% are the things that give you benefit but the remaining 0.1% will be destructive.
I actually decided to use 'scripting' after this thread, when I knew why I want it and what I want to do. Still I am lost too many times even with the help of NI R&D (and I guess they sacrifice some free/unpaid time). And I also do it apart from my work project (won't risk).
Felix
Ditto that!
Why I attempted to use scripting followed by what I hope to use it for
Why I attempted to use scripting:
Application required I monitor SCRAMNet memory space that was mapped by a book documenting every field its type and it usage (and no I was not on that committee. They updated the book regularly). This translated into about 30 clusters with a gran total of 50,000 fields. Since the book was in standard form I parsed it and created cluster to match along with an Aection Engine for each cluster. I was excited, brought it to work deoed for my boss, it threw an "insane object error". I have not gotten serious with scripting since then.
What I hope to do:
I think in state machines. There are many enhancements I always wanted to add to the old State Diagram editor. I want to re-write the SDE with all of my enhancements included.
Ben
09-08-2009 03:26 PM
Ben wrote:What I hope to do:
I think in state machines. There are many enhancements I always wanted to add to the old State Diagram editor. I want to re-write the SDE with all of my enhancements included.
Ben
Now what is that?? You mean Control Editor to change the type def of the states enum?