Mike Ashe

The generalized version would be very useful, especially if we could "register" a control reference with it and thereafter whenever the mouse was over that control we would get the scrolling effect. I noted one funny behavior. If you move the mouse out of the listbox, scroll (the listbox does not move, good) and then move the mouse back into the listbox, you immediately get a scroll of one. It would be good if you flushed the previous scroll count when the mouse over event is detected for the control. Looking forward to that generic version. :worship:

Couldn't resist added the switch from verticle to horizontal. It is nice that this can be done on the fly rather than only at edit time. Cheers :beer: Mike Download File:post-45-1104432525.vi

Hmm, I should have scrolled down to the bottom of this topic before I coded up this example . Oh well, here is a simple example of using -2 to color alternating rows. Any more is an exercise left to the student... Cheers :beer: Download File:post-45-1104431973.vi

It would be nice if we could set a property on a text control that would define the allowable type of text in that field. This feature would initially be relatively simple, with predefined items in a definition string sort of like a regular expression, and later allow us to attach a reference to a user defined filter VI. We can effect something like this now using an event structure frame and a filter VI there, but having it built in and programmatic would really be nice.

It seems like with scripting we could now add the ability to save a LabVIEW icon as an ICO file. The ICO file format is known and we can now get references to the VI icon and connector pane, etc, along with the images, etc. It might be doable without to much effort, but I wonder if that is in the pipeline for LV 8? I have heard that NI is working on a lot more project type tools, but I don't know what versions they are expected to debut in.

Commenting out non-working subVIs (and whole trees below them) is exactly what we sometimes need during development of large projects. It would also be nice if we had a Find/Enumerate option that would show us all the places that had Comment Blocks and manage them selectively or as a whole. Hmm, maybe some of the new scripting stuff...

NI has a history of having major new features running internal to NI for several versions of LabVIEW before they are finally released to the public. They had UNDO running for a long, long time before they finally released it. While it is frustrating to wait so long, it is also nice that usually when they release a feature, it really is ready for prime time, unlike some companies we know in the U.L. corner of the USA...

I downloaded it and was impressed. I also spoke to my brother-in-law who is a senior programmer for Fidelity Investments in Boston. Some of Fidelity's internal work is now being done on Eclipse which has been officially approved by the company. Fidelity is very conservative about the tools they allow to be used. This speaks well for the stability and safety of the code. As to whether to try to put LabVIEW-Java plugins in or just use it as a model.... that is a very good question. I think for now we might want to continue to do our major tool development in pure G, but Eclipse should be added to OpenG/LAVA projects for three reasons: 1) development of those few cross-platform functions that might be better implemented in a text based language. (or for including existing open source text based code/libraries). 2) to get us into a good open source IDE since Microsoft has included verbiage in its Visual C/C++ license to try to preclude use for developing open source tools. 3) Future: for writing "OpenG" as an OpenG project in the next few years :thumbup:

Okay, Dave, if the only reason is messiness, could you consider releasing the code at this time. I absolutely, completely, honestly and truely promise that none of us will laugh. :laugh: Perhaps some of us could add an extra feature or so and do a little sweeping in the process. Your utility is cool, :worship: but it would save us :headbang: if we didn't have to recode it all Thanks in advance!

Great VI that you created. :worship: Yes, please upload. This would be very useful as a building block for creating other controls. I have a specific application that I could use this on right now and would be happy to post my mods at project end.

Does anyone know what the status of the beta test of the scripting toolkit is? Hmm, perhaps those who know cannot say, directly, and hence things must be "vague", but it would be nice to know which Christmas we are looking at for having this in our stockings.

Still working on this. It's been a while since I played around much with C. There are a few options: 1. Create LabVIEW VIs from header files from scratch. 2. Create CVI fp files from header files This option requires knowledge of the file format of .fp files. Does anyone know about this? I put out a call for help with the general parser portion of this utility. We need something to read a header file and 1. sort out what is and is not a function prototype. 2. parse the function prototype. There seem to be more types and pragmas than when I was last programming in C. 3. Related: parse and create LV clusters for structure definitions 4. For those that are to complex, either map or recommend mapping ideas for a shell DLL that will export datatypes that are simple LabVIEW datatypes. The CVI fp files appear to be binary, here is the NI reference to making a set of LabVIEW VIs from a DLL, but it is using CVI: http://www.ni.com/support/cvi/visa/default.htm Note sure if the CVI license agreement specifies if the format of the fp files is closed or open or if we are allowed to look. If not then we are stuck with having to go from header files from scratch. Any ideas, comments, help would be appreciated!

I agree, and am pretty disappointed zeus224, especially after I (and others) tried just recently to help you with a small problem: :arrow: http://forums.lavausergroup.org/index.php?...findpost&p=3123 I am also surprised, since I have worked with several projects and people in South American countries and have found them to be uniformly polite and well mannered. Please refrain from such comments about your fellow forum members. You might also want to rethink the icon you use as an avatar, it does not lend a good impression, especially combined with your recent comment.

If you use a variant in the Queue, one way to avoid the need to use the datatype descriptor is not to wire the variant out directly, but to use the Set Control - Variant method to input the data to a control on your target VI. This requires a little more work to achieve an elegant implementation, but is generic. Another option is to pass straight variant to each of your target VIs and make it their responsibility to decode their own data.

The latest edition of the OpenG Toolkit includes a nifty little utility that lets your restart LabVIEW from the LabVIEW File>Restart LabVIEW... menu. As part of this tool they have a "helper" application such as didierj refers too above. Seems that with a bit of judicious tweaking you could make it do what you want. And you would now be using the OpenG Toolkit as well. Get the toolkit (all packages 2.3.1): http://sourceforge.net/projects/opengtoolkit/ and the OpenG Package Installer: http://openg.org/tiki/tiki-index.php?page=...ckage+Installer Install the Installer first, then use it to install the OpenG Tookit. In addition to what you want, there are lots of other goodies. Merry Christmas...

T&Ms Database Toolkit looks pretty nice. Sorry, but I missed the price of the kit? Actually, I have been hopeing for some time that someone would add this type of functionality on top of the LabSQL open source toolkit and distribute it as more open source. Has anyone tested T&Ms kit yet?

Excellent utilities, both Michael's and Didierj's. Data Format: I have a dynamic menu bar menu creation utility from a friend that populates a user defined menu hierarchy from simple text. The format for nesting uses > characters, one for each nested level, as in: File >Open >New >Close Edit Tools >OpenG Tools >>Packaging Tools >>>OpenG Package Installer It's his code, so I'll have to ask permission to give it out. But the data format is obviously not proprietary. Nesting Implementation: It seems to me that this is an excellent use for General Recursion of one menu, passing down the nested items to the next. Since it is for a GUI function, the performance hit of recursion should not be noticed. http://forums.lavausergroup.org/index.php?...findpost&p=1850 Another good method might be with templates. I'm kinda busy right now, but if nobody comes up with a general nested Right Click Menu (RCM) by New Years, I may give it a shot and a few hours.

Hi everyone, I am trying to parse a C function prototype. The end application is to be able to convert from C function prototypes in a header file to wrapper VIs with CALL LIBRARY nodes inside. I already have some of this done, but would like to have a better parser. My current attempts are rather primitive and I was wondering if someone might have a general parser already done up as part of a scripting effort from time gone by. Thanks in advance, Mike PS: The final tool/utility will be posted here and also be made into an OpenG toolkit. This will be under the LGPL so anything you contribute would have to be acceptable under that license. Sorry. I guess this is a backwards way of kicking off a project and asking for helpers. I'll get a little more formal with this in a few days.

Thanks for reposting this in 7.x Eliezer. I have used older version of your library in the past and am grateful for this version. It would be nice if it had a function to open a VI from the Manager. I added that to one of your older versions a long time ago. Here is my version. I don't know if it is as up to date as yours with LV 7.x: Download File:post-45-1103751333.zip

Thanks Tim, nifty tool. Do you have any updates planned?

You might also want to go to NIs site. They have some tutorials and files for HDF: Managing Large Data Sets in LabVIEW http://zone.ni.com/devzone/conceptd.nsf/we...node=dz00000_us This has a GigaLabVIEW.llb and a couple of HDF DLLs along with some nice tutorial text. There is also a link at the bottom to: Can I Edit and Create Hierarchical Data Format (HDF5) files in LabVIEW? http://digital.ni.com/public.nsf/3efedde43...16?OpenDocument Which has a couple of components that should take care of what you want. If the links above don't work, just go to http://zone.ni.com and search for the title lines above the links.

Hmm, I know that the FITS file format (astronomy based) has been implemented at least twice by different groups and now that I think of it, it seems that I have read about HDF files too. Go to the Info-LabVIEW VI archives at: http://www.info-labview.org/the-archives/vi/lv4 and look for: hdf_distribution.sit and hdf_distribution.txt These are in Mac format, but even that might be a good start. Also go to the Iinfo-LabVIEW search engine SearchVIEW.net and search from 2003 and earlier for HDF. You will find a bunch of entries. Ciao

I have not heard of LV 7.2 either. I think he was just extrapolating versions. It would be surprising that a 7.x version would come out without some type of beta. Senor zeus, glad to hear that uninstalling XP SP2 has solved some of your problems for now. I would not expect 7.2 (even if it existed) or even 8.0 to solve this. I think it is more of a Microsoft issue (surprise surprise...). In the meantime I am sticking mostly with Win2000 and LV 6.1 for most applications and 7.1 only when a client demands it. Ciao

Thanks Jim for your great post. This is indeed a very important topic, which has, unfortunately, been somewhat obscured by the License Manager topic. They are related, but ultimately I think the two clauses you quote from the 7.1 License are more problematic and more important for the LabVIEW User community to address with NI. For NI, or any other company, to say what we can and cannot create with the tools they sell, especially the clause about anything competing with ANY of their software is crossing the line from protection of their product by prevention of theft (illegal copying) into anti-competitive behavior that at best will eventually drive away loyal customers and at worst be actionable in courts, both legal and the court of public opinion. The way the current clause is written, well, lets use a simple analogy of physical tools: Suppose we go out to buy a milling machine, from say Ingersoll or Grizzly or Bridgeport. Bridgeport might be the best example as they are probably the biggest. As I am installing the Bridgeport in my machine shop I start reading the User Manual and find a reference to the Start Switch tag and the License Agreement. Sure enough, I find tye-wrapped around the Start Switch a tag that says breaking the tag and using the machine makes me agree with the license and the license includes clauses like the two in question in NI's 7.1 license. I cannot use the Bridgeport to mill any parts that by themselves or in conjunction with any other parts, might compete with anything that Bridgeport sells. What would be the reaction of machine shops owners to that? I intend to poll a few and then publish the results here. Or simpler, you go to Sears and buy a toolset for Christmas and on the package it says that breaking the shrinkwrap means you agree that you won't make anything with the tools that might compete with or replace anything, not only in the tool set, but any other thing Sears makes or sells. Sears has a pretty big catalog. Has anyone noticed that although the physical size of NIs catalog has gone down, the number of toolsets/addons to LabVIEW has skyrocketed in the last couple of years? I appreciate Mr. Gardner's pledge to work with the community to address our issues with the current NI license and also the comments of several other NI employees here, on OpenG and Info-LabVIEW that NI is not going to use these clauses to stifle our work artifacts. These sentiments are appreciated but are not from NI's legal department and until we hear from them, in writting, we will have no assurance that our creativity, innovation and labor will be rewarded in the marketplace. The bottom line is that NI does not need these clauses in their License and continued inclusion is simply intimidation. I strongly suspect that these two clauses would be ruled invalid with a strong court challenge, but the reality is that NI has the deep pockets to sustain an expensive legal defense, (or offense, should they try to invoke these clauses and tell someone to cease and desist development or sale of a competing product), while most or all of us as users of LabVIEW do not have the resources to defend, even if we are right and the clauses are anti-competitive and unenforceable. If NI's tools and toolkits cannot compete on their own merit and price-performance value, then these two clauses are a poor second-string defense and need to go. NI does not need them and neither do we.

XP SP2 is a lot more intrusive. It is trying to add a lot of security, but its methods of doing so interfere with a lot of programs. We have not had good luck with it and went back to SP1 and have no problems. Do yourself a favor and go back to SP1 if there is any way you can live without SP2. Good luck