jgcode

Crelf has proposed a minor update to the OpenG Comment in the OpenG String library.

I'd replace it with someting like:

/* This_is_a_free_text_comment_label-Double-click_this_text_and_start_typing_to_replace_it */

Note the spaces before and after the underscore delimited text.

thank you so much i am using LB8.5 and eagerly waiting for starting code.

Hi sjukheter

Here is another example using User Events to communicate based on the above discussions.

Cheers

-JG

PC Events - LV85.zip

Code is in LabVIEW 8.5

Starting new project for old LabVIEW (version 8.2.1). I recollect there were some problems with LVOOP in 8.2, some of them so severe, that it was suggested not to use it in 8.2? I tried googling it out - no luck. Can somebody kindly point me to the problems I might run into.

Yes, if memory serves correctly, 8.2.1 was a massive upgrade for LVOOP rather than the standard minor fixes.

Anyways, I have seen weird stuff with using it so I wouldn't recommend it (I was forced to by a client's license).

Of course it makes sense that the standard features are more stable in the latest LabVIEW versions (and that there are more features as well).

IMHO I would recommend LV2009.SP1 if you have access to it - lots of features and really stable.

Of course it comes down to your requirements and resources etc...

I am doing a presentation at NIWeek this year on LabVIEW debugging

Sweet! Can't wait

I've been using this feature forever

Well why didn't you let us know about it then?

Nice! I wish I had known that, it would have helped with some of my debugging in the past....

I knew you could change the inputs but didn't know you could change the outputs, so thats pretty cool - thanks for sharing.

Lol

This thread was manually moved from OpenG to LAVA.

Hi there..

I searched in the forum but couldnt find a similar topic.

When setting the name of a variant with "set data name" it will erase all atributes. Is this wanted for some reason i don't understand, or kind of a bug?

For me it works when changing the vi as shown in the attachement. I ask, because I want to share some tools, and i use properties, and it would not work with the openG libraries as in the current repository.

Regards

Bernhard

and the png....

Is this forum dead?

Where can I change the libraries in oglib repository?

Lg

By the way its Rhythm not Rythem

This thread was manually moved from OpenG to LAVA.

Just upgraded to LV2010 and found a problem with Strip Path Extension. The string version of the Vi will load the File Path Indicator correctly but the indicator is NOT passed out to the calling routine. The results is that you always get an empty string.

Has anybody else experienced this problem?

Thanks,

Eldon Zacek

This appears to not be just isolated to the Strip Path Extension Vi. I have found another Vi, Delete Elements from 1A Array(string), that has the same problem.

This thread was manually moved from OpenG to LAVA.

I hope this is the correct forum to report this bug:

LabVIEwVersion__ogb.vi which looks to me like it's part of OpenG Builder (although I'm using it via VIPM) fails to return the correct version for LabVIEW 8.6.1f1 (the f1 patch confuses it due to a literal string match on the Version property). The attached hacked version fixes the problem by testing each part of the version number separately and giving up after matching the minor version number.

LabVIEWVersion__ogb (hacked).vi

This thread was manually moved from OpenG to LAVA.

Hi openG users,

Since LV2010, Set Control Value {Variant}__ogtk.vi function end on error for some control type like cluster reference.

See SetControlValueBug-LV2009.vi in attachment to reproduce the bug.

LV2009 SP1 --> OK

LV2010 or later (SP1 and LV2011 beta) --> NOK

To fixe the bug, you just need to replace Ctrl Val.Set Invoke Method by Ctrl Val.Set (variant) Invoke Method.

See Set Control Value {Variant}__ogtk--fix.vi in attachment to fix the issue.

It will be great if this fix could be added to oglib_appcontrol.

Thanks,

Olivier

SetControlValueBug-LV2009.vi

Set Control Value Variant__ogtk--fix.vi

This thread was manually moved from OpenG to LAVA.

The Current VIs Parents Ref.vi opens a reference to a VI and doesn't close it (obviously, because otherwise the ref in the output would not be valid anymore). I think however the help should note that the returned ref should be closed by the caller after he's done with it.

When occasionally calling this VI in your app, it shouldn't be a real problem, but I recently had an application which seemed to have a memory leak, and after letting the Desktop Execution Trace Toolkit take a peek at it, I found that it was caused by Current VIs Parents Ref being called somewhere in the call-chain of a very tight loop (20ms). Closing the ref when done with it fixed this.

Not really a bug this, but expected behaviour that should be clearly noted in the help I think, hence the post here instead of bugs forum.

This was noted in LV2010SP1 btw.

This thread was manually moved from OpenG to LAVA.

Howdy

LabVIEW Project Libraries (.lvlibs) provide namespacing, scope and iconography among other things and I would like to discuss their role in OpenG Projects (I did not use the term libraries to avoid confusion). Also, some cool things can be done like making all Polymorphic Member VIs private, but the Polymorphic VI public (and whether that would be desired). NI also seem to be moving their code to this paradigm (but have the benefit of linking to the new namespacing automatically on upgrade).

Anyways, my intention is to keep the question pretty general in order to generate a discussion in any direction (reasoning, process, benefits etc...).

What are developer's thoughts on migrating the OpenG Projects to LabVIEW Project Libraries?

Cheers

-JG

I guess we should put together a pros and cons list and weigh everything together.

I think that some things are a great fit for LVLibs: poly VIs, Dictionary, Message Queue, Zip Tools, etc.

However, I wonder about how much benefit there is to grouping everything in the OpenG Array or String libraries into an LVLib (where the VIs are only grouped based on the data type that they operate on).

Maybe this is a good discussion for LAVA.

This thread was manually moved from OpenG to LAVA.

Howdy

Just noticed the optional input include string (j) is wired to the right hand side of the Connector Pane.

Will this VI have to be depreciated in order to be fixed?

Cheers

-JG

Yes, I think that we will need to deprecate the old vi, in order to change the connector pane.

And, if we're going to do that, I would argue that we should look at other ways to improve the connector pane and icon. For example, I would argue that string (input) and substring (output) should be at the same vertical position.

I got my passing CLD results from NI today.

Kudos!

I bet she gave you a better dress-sense than I, too.

Funnily enough, pink is my favorite color!

I do something pretty similar (without the vi tree). Only I also have a "config" file that tells the loader what to load (I usually have modules that need to check 3rd party hardware as well as DAQ etc, and feed that back to the splash so you see "Loading....[module name]") - they change from project to project)

Cool. I have done stuff where the Main App sends Status Messages to the Splash Screen. Can you go into detail about how the hierarchy works here?

Does the Splash Screen load the modules, then open the Main App so th modules stay in memory, then the Splash Screen goes out of memory etc... ??

Cheers

-JG

I've done splash screens before, but they've not really served a purpose other than branding so their implementation really didn't matter from a performance perspective.

FWIW this is what I do.

I do it for the reasons you stated - to have time to load the main application and do any initialising I need before showing the UI.

This is the general approach for most applications.

As I do a lot of smaller applications so I decided to write some reuse code and have a generic splash screen engine.

When requirements dictate, I just start with an engine template and go from there.

This is my project, it has two important VIs

Launcher - which is not statically coupled to the application hierarchy

VI Tree - contains all other Top Level VIs (not Launcher)

This makes the Build Spec very simple and does not need to be changed.

I then create a Splash Screen for each application that can look like whatever (note: toolbar only shown in dev environment)

The BD code looks like this - this is the reuse code. I just configure it with the Main VI and UI VI.

The Engine does its stuff. Launches the Main VI in the background

Does some fading out or other screen effects based on a Timer

Then due to the RTE exiting if a FP is not in memory, the application does a check and waits for the UI's FP to be loaded. This means I have time to initialize the UI etc... before showing it.

Pretty basic I know, but it works.

I have other apps where the Splash Screen can create a log of the session, checks for driver version (DAQmx, dotNET) etc...

I would like to add more features into the reusable code that I have in these other applications when I have the time.

Make JG Dance For You

Windmill and kick is my favourite

Nice! I leave town for a few days and this is what happens...

10 points for trying, but my wife beat you to this about 6 months ago

LAVA just got moved to a new faster, bigger, more stable, server (that's what she said!).

That has be Crelf... ...lol

Thanks, Chris! I've had a blast working with you and the passionate, intelligent, awesome LAVA folks.

I'll still be following along online as you build things like the awesome graffiti art demo, and fully expect to see you at NIWeek later this year.

Thanks for all your hard work in growing the LabVIEW community and good luck at Jive Software!

Also please keep tweeting - I really enjoy your feed.

Cheers

-JG

If so I would be very interested in your opinion of how closely the single CLA sample exam compared with the real exam.

I would say similar too, but a bit bigger.

Absolutely nothing of technical merit to add here, but I can not believe you actually used the words "ShaunR" and "shy" in the same sentence.

ShynR??

What jgcode said -- unless the popup is being generated by something other than LabVIEW (or other code you have control over)?

You may be onto something there, on second look the popup does say Message From webpage - of course I have no idea, as its unclear at this stage I just assumed LabVIEW code.