ragu

QUOTE (JDave @ Oct 15 2007, 07:20 PM)

I posted a while back how I was feeling there must be a better way to wire up my controls to the connector pane on my subVIs. My experiments since then have been quite fruitful.

Auto ConnectorPane

• Puts a huge scaled connector pane decoration on your front panel.
  
• Connects up any controls or indicators that are in the oversized terminal boxes.
  
• Drag your controls and indicators to the desired box, or outside the decoration to disconnect them.
  
• Works with all connector pane patterns.
  

It's the best thing since dragging your mouse back and forth between the connector pane and each and every control and indicator! Just put the .llb file in your project folder in the LabVIEW directory. Restart LabVIEW and you will have an option in the Tools menu for Auto ConnectorPane.

LV 8.2 or higher is required, and depends on several OpenG libraries (you should have OpenG installed anyway, of course).

Download File:post-1519-1192574576.llb

Download File:post-1519-1193686315.llb Filters out invalid file types and controls have less strict positioning requirements.

EDIT : I changed the original .llb file to a version that does not crash if you move the decorations. It just puts them back.

I added a second version that filters invalid VIs out and implements a different algorithm for assigning terminals.

When try to open "AutoConnectorPane.Vi", Autoindexing-Tunnel_ogtk.vi is missing. So that i am not able to add this into my LabVIEW8.5...How can i get this...

Thanks in advance

QUOTE (vieira @ Feb 16 2009, 01:21 PM)

Yes, aleatory means random numbers between 1 to 10.

I need a matrix nxn, n rows and n columns (for example: 3x3, 4x4,5x5, 6x6, 7x7,....). The "n" must be entered by control.

Thank you.

hi

I got somewhat what do you want.Just find the attachment.If it's not help u plz explain ur requirement once again..

QUOTE (Antoine Châlons @ Jan 14 2009, 09:40 AM)

I think we have to separate memory leaks like defined by Rolf (memory got allocated and the reference got lost somehow without the memory being freed) and http://eyesonvis.blogspot.com/2008/07/memory-lakes.html' rel='nofollow' target="_blank">memory lakes which can be caused by uncareful use of the build array function.

The way to detect memory leak and memory lakes are not exactly the same. I faced both. Memory leaks are annoying but once you've found out which reference is not freed correctly you can find a work-around. Memory lakes in a fairly big application (about 2k VIs) are really not easy to fix. In my case the memory used by the application was stable for about 30 hours and then started to slowly increase untill breaking the 2 Go limit and resulting in a crash.

Since you don't always explicitly allocate memory in LabVIEW programming you need to learn how LabVIEW will allocate its memory and code your application appropriately. Learning this was time and energy consuming for me because I have no background in C (or any other language) but it was really worth, now I feel a lot more confortable in my day to day coding.

Doing this might not be a "simple way" to detect memory leaks or memory lakes but this is the way I recommend. There are many good white papers on NI knowledge base regarding memory managment.

hi,

i have 1 year experience in labview.i want to know how labview allocates the memory(i.e. internals of labview).could you please give some tips or answers to learn.

thanks in advance...