Darin

I thought it was here: https://decibel.ni.com/content/thread/8293?tstart=30

In LV10 I use the Move Selected Objects Method of the TopLvlDiag Class (ie. Block Diagram). I use the Joints[] property to find the segment I want. Typically I index the array to select the starting joint. I will use the maximum of the Left/Right/Up/Down indices to find the opposite end of the segment. Using those two points I would use the Point2Rect.vi followed by RectCentroid.vi (both in vi.lib) to find the center of the segment, and then use Point2Rect.vi again with the incremented and decremented centroid value. This defines a very small rect around the center of the wire segment. Then I would use the Clear Selection Method (TopLvlDiag), followed by MakeSelectionFromRect using the rect you found, followed by Move Selected Objects with appropriate Delta X/Y. Finally Clear Selection. I could post an example later, this is from memory. Better learning experience recreating it yourself. I have added other features like finding the segment closest to a given point, and double checking that the selection process does not add other objects. It is easy to get the terminals selected on shorter segments which are hidden. My other point is that you are usually a much, much happier scripter if you let LV deal with the wiring (BD cleanup, Clean Wire method, autowire). Futzing with wiring in scripting is a spaghetti factory, this simple task is already a screen wide on a BD.

So I do have a bit of a disorder when it comes to round numbers, and my latest version was clocking around 102-104 nsec on my machine. Had to get those last 2-4 nsec out of there and noticed a little detail that was counter-intuitive (for me). I insisted on putting the reverse array inside the case, why would I reverse every time if I wasn't going to trim the end? Turns out the compiler (LV9 at least) is happier with the reverse array node on the root diagram (as JG astutely shows above). That simple change shaved about 6 nsecs on my machine so the test clocks in at a tidy 98 nsec (next fastest was at 114). Happy day, got to learn something new. Happier day, it may prove useful.

If you feel the need for speed there is one more step you can take. It obfuscates the process a bit, but you can generate a lookup table which is indexed by the byte array. Simply put true at values which correspond to whitespace and index it. VI attached below. (I tend to use the version I posted earlier because I can make the lexical class a control to trim more than whitespace, but this seems like a unitasker). Darin2.vi

My goto method for resizing controls is to use the following VI from the resource directory: ...\LabVIEW 2009\resource\dialog\Resize.llb\PosDims.PasteToTargets.vi Open the ctl file you have created and get the control reference (only object), hide the label so the control bounds equal the image bounds, then use that VI to scale the control to match the original image size, then reposition the label. In the attached VI I add the ability to change the label as well. I use this to autogenerate frameless buttons from PNG glyph files. ScaleControl.vi

I have a similar version except that I use the Lexical Class comparison (which also sets my definition of white space). My guess (no hard data) is that it is a wee bit faster than the array search. Rearranging my code to match the above image gives me this. Also I would look at the result in your code when an all-whitespace string is trimmed at the end.