jgcode

What do you mean? I'm talking about the ten degrees on the Kinsey scale - what are you talking about?

It turns out there is only 8.

Therefore, I will change my question to:

You obviously understand octet?

@ JG

Why have you slowed it down? (those arrays were inside the for loops for a reason )

Hi Shaun, thanks for your reply.

Here is some interesting points from testing (note: I did it in 2011 as I had it fired up at the time) after I stripped out the new argument:

• The arrays inside or outside the loop made no difference
  
• I cut and pasted your arrays in - this made it faster. It must be to do with the Search 1D Array primitive? Did you optimize the order of elements in the array?
  
• I replaced the order of the tests (e.g. ran your VI in first frame, mine in last frame (in the performance test) and this changed the results! It made mine faster.
  

Can you verify this?

With the new argument stripped its pretty similar however, if the argument is to be removed I think your version (above) is better (I had constraint of handling both arguments when I wrote the proposed VI).

Cheers

-JG

Hey Jon,

Thanks for posting this design change for review.

A couple questions:

A) Do users often need to "Remove non-printable characters (False)" -- is this a common use case?

B) Does it add much value to couple the removal of non-printable characters to the trimming of leading/trailing whitespace? (For example, do users often need to perform these operations together?)

It seems to me that if the answers to these questions aren't an overwhelming "YES" (in all caps , then removal of non-printable characters should be decoupled from Trim Whitespace, since decoupling orthogonal functionality tends to make the software more maintainable, understandable, testable, etc. If the decision is to decouple them, then maybe it makes sense to add a new function called Remove Non-printable Characters.

Regards,

-Jim

Thanks for the feedback Jim, the Remove non-printable characters (False) argument was a feature of Fast Trim so I included it in the proposed VI however, I had to make Fast Trim fit the original OpenG Trim Whitespace leading/trailing interface.

i agree with respect to orthogonal functionality - we could definitively decompose it into two VIs.

What do others think?

There are 10 types of people in the world...

You obviously understand binary?

At first thank you for supporting OpenG.

You are welcome my friend.

I'm stuck with old 7.1 so my question, if it's posssible to get the code downgraded? I promise to do testing and to ask for an upgrade as well

OpenG's direction is definitely a forward one.

Currently the 4.0 release is in LabVIEW 2009.

The cool thing about packages is that you can always install an older version. Unfortunately new updates in later versions would not be available (obviously).

We would love to have you on board if the above works for you (be that now or in the future).

I did take videos off every session that I went to with my new hd camcorder that I recently purchased. the problem is that a 1 hour session in about 5.5 gigabytes worth of data. This makes it difficult to post or stream.

Michael also has copies of all the videos I took. we are trying to figure out the best way to get the videos to the community. Either throug VI shots or Lava.

Also it's very likely that the most popular NI presentations will be respun into webinars in the future.

Wow, I thought they would have compression on those things. Reminds me of when I handled raw AVI back in the day.

Anyways, sounds like a plan.

Can't wait.

Cheers for your time recording the sessions.

This OpenG Review is now closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.

Community,

This is the integration of ShaunR's Fast Trim to OpenG's Trim Whitespace function.

Please review the code and submit all comments below.

On testing PC the new Trim Whitespace VI is >3x faster than the native version and ~5x faster than current OpenG version.

Aside from the algorithm change the VI is now a subroutine (like natvie version).

The new interface supports an additional argument Remove non-printable characters (False), see BD for further comments.

Kind regards

Jonathon Green

OpenG Developer

Trim Whitespace (String) 1.vi

TEST - Trim Whitespace (Performance).vi

TEST - Trim Whitespace 1.vi

I understand that.

And yes, what I'd like is a smater "cluster to array", by the way here's my use case :

I'm lazy and I'd like to have the best of both worlds - so to speak.

A smarter "cluster to array" is one step, the second step would be for the property/invoke node to accept arrays of references. I think there is already an idea for that (not sure though).

OpenG to the rescue?

<!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="1288" height="638" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/FirstFrame.jpg&containerwidth=1288&containerheight=638&content=http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/OpenG%20Cluster%20to%20V%20Array.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW%202011/media/08629e27-bbc8-4451-a4c4-560ee04ec845/" /> Unable to display content. Adobe Flash is required. </object>

Are there videos up anywhere?

I think there was talk of Mark filming some of the sessions and posting them up on LAVA.

That would be great to see (hint, hint, nudge, nudge, know what I mean?)

It would be nice if LabVIEW had a way to force a constructor. Does anyone know why it is not an option to prevent a class object from being dropped on a block diagram?

As mentioned above:

You cannot force this operation and restrict the use of the Class.ctl as you have to use it subVI boundaries, as part of datatypes, as default value etc...

I am sure AQ has commented on this before?

This may seem like a hack, but what about putting a boolean flag in the parent private data that is set only by constructor VIs? This way you could determine if the user called the constructor in the related methods...

What would you do with the flag? You would have to run precheck code in every public method and handle exceptions. That sounds like a lot of work.

I learned something new today; there is so much to learn in LVOOPs.

...and LabVIEW in general, which is why it's so much fun!

See here: My LVOOP class control has a black border, what does that mean?

...because they force you to use the same inputs for every child class... what if you have a specific property in one of these classes, and you want to initialize its value in its constructor?

Yes - you can have different constructor CP's for each Class.

The only things I can currently think of are:

• You must have a unique name for each Constructor VI for Classes with children
  
• Using a Constructor in a pure LVOOP Plug-in architecture may require a Wrapper VI so the API (i.e. Interface) is standardised across all public methods.
  

I've created a constructor.vi and am forcing all children to override this vi. Inside the parent's private data cluster, I have another cluster called "data for override" and a single accessor can write the entire cluster. That cluster is also a type-def, which is used on the front panel of the child as well. So all I have to do in the constructor is take that cluster and write it to the parent's cluster.

FWIW the constructor method I present in the video link does not use dynamic input/outputs.

Using type-defs in Classes is a whole 'nother thread. However, using a cluster is not the best interface - you should use separate accessors methods for each property IMHO.

Another option could be to have VI's such as 'GetRangeXYZ', put it in the parent class with the property 'Require descendant classes to override this dynamic dispatch VI'.

Then you create these override VI's in child classes so that they simply output constants.

This seems like a lot of work in comparison - do you use this often and prefer it over the constructor/init method? Are you able to comment on pros/cons?

Cheers

-JG

I like the idea and have similar questions to Greg. Can you provide more info on how they would be 'used' please. What is your vision for blogs on LAVA?

LAVA used to have them right?

If a page linking these should be created then I suggest one be created on labviewwiki.org.

That was my first though as soon as read the OP.

So have a like from me plus this is my 301 post yippeee

Congrats

Not true. You can do what you want with the new Unread Contents page. Just click on the date you desire on the left. You will then see all your items. They will never go away. You can preview read each item (without setting the read flag) by clicking the little arrow next to each post title. Any items you have already read will have the light grey background.

It's pretty nice.

The cool thing is the settings persist from full site to the mobile version (I can't see where to change then on mobile version) - now I have mobile 'portal' - love it.

I think this is a better way to show support and encouragement to a user's post and increases networking between community members. I "like" it!

I am up for trying anything new - so I like it to

Plus like works in mobile version when reps don't.

You can set the default child data in the class data control. So then that data will be used when placing the object constant. Of course this data can only be set at edit time. But I assume this is what you want.

From what I read, the OP wants to override parent data (which is not available in the child by LVOOP design).

From what I can tell, national instruments doesn't have any type of constructor built into LVOOP. What you are saying is that to essentially create one and work around that, I can simply create a method inside the class where the object is created that does the initialization stuff. Then when I want to use that object in a program I just plop down the constructor.vi on the block diagram and use it's output terminal as the object instance. I don't put the bare object constant on the block diagram as is typically done... ...Unfortunately I don't think there is a way to "force" someone to use constructor.vi on the block diagram instead of the object constant, so the programmer will have to keep that detail in mind. Also, there is no way to "force" those certain data fields to be initialized in the constructors of each child that I can see.

Yes that is correct.

You may or may want to call it constructor (as LVOOP has no constructor) the constructor is always the Class.ctl if you will.

You cannot force this operation and restrict the use of the Class.ctl as you have to use it subVI boundaries, as part of datatypes, as default value etc...

Unless someone here can tell me that this isn't the best way to accomplish what I'm trying to do, I'll try it out and see if it works.

IMHO I don't think this is the best approach to learning - you should try stuff anyways and form your own decision, then provide feedback back to LAVA to continue the learning cycle

Optimally, I'd like to override the defaults of those data fields, and require all children to override them. If there was a constructor, I could just read in the defaults off of the child's front panel and then populate the parent's fields, which would be a little more work. However, from what I can tell neither of those are possible. So how can I make sure the parent's private data fields are set appropriately to what the child's defaults are?

Sure you can - check out the video Create Constructor From Template here, that is the style I like to use.

Just set the parent accessors in that VI with the default data (from constants etc...) then call this VI instead of dropping of e.g. a Class Constant on the BD.

Cheers

-JG

As a result of the great "Config VI Refactoring Debacle", I come down strongly on DISCOURAGING any use of VIs that are not in the palettes unless you copy them to a new location on disk and use them from there. I'm pushing to have the Variant Data Type library added to the palettes in LV 2012 so that it is no longer under this interdict.

This package exposes the Variant Data Type Library palette if anyone is interested.

Cheers

-JG

Hmm, I wonder where that shortcut in the file menu came from. I think it is in ONLY LV2010 SP1 for me. I think its largely irrelevant based on what you say, I'll just start using the hotkey.

Thanks,

~Jon

There is an OpenG package that installs this option.

It wasn't there by default in 2009, Yair says it should be here, I can't check 2010 as I don't have it installed on this laptop.

Cheers

-JG