Jim Kring

Anyone solved this problem? Basically, I want to get the screen coordinates of a block diagram object. Thanks!

Hi All: Please let me know if/when you need this built/released. I want to support this!

Thanks for the info, everyone! My takeaways are: - NI is eating its own dogfood and using this feature internally to a very great extent (I'll see if I can verify this and learn more). - For projects that do not have multiple targets (e.g. Windows desktop only, and no Real-Time targets in the same project) this seems to work very well in 2013 and 2014 (but, there were lots of problems in 2012 and earlier) - For simple projects that have multiple targets (e.g. Desktop and Real-Time targets in the same project) this seems to cause issues ("small hiccups" and "odd things") that can usually be resolved by clearing the object cache. - For larger and more complicated projects with multiple deployment targets there can be (A) deployment errors when running in interactive mode on remote target, as well as (B) build problems. Unfortunately, forcing recompile and clearing the object cache doesn't always work to resolve the issues. For some users, this is too big of a pain and they have abandoned the use of Separate Compiled Code from Source on these projects. Did I get that right? Anyone else have good/bad experiences or input to the topic? Thanks,

Back in the early days of LabVIEW, the Separate Compiled Code From Source feature had a lot of quirks (and we discussed them in this old thread). I'm wondering what are people's current feelings and practical experiences with this useful feature. Do you trust it (e.g. to not corrupt your code)? What are the current issues/quirks (e.g. occasional broken VIs)? How do you work around them (e.g. object cache flushing)? Thanks for sharing. I'm working to put together a set of best practices for using this feature and I'd like to know everyone's... well... best practices

There isn't a spec for this, currently. But, I think that they are ordered by order of insertion. There has been talk of refactoring the current implementation, at some point, with variant attributes, since they are more performant.

"Labview is packed with wonderful pieces at the cutting edge of fashion with an emphasis on collections by young up-and-coming designers, who are very much in vogue." -- https://cityguide.b-europe.com/en/lyon/shopping/labview-p-107snc220 (Photo was taken by someone from CERN.) And, it's funny that the shop next door sounds like LAVA'erie And, I've updated my outdated avatar to a newer pic from the CLA Summit 2013 in Paris, France -- seemed fitting

Hi Dustin. Thanks for reporting this. I think I get what you're saying. Could you attach a small example VI that demonstrates the problem?

Hi Neil, That's a good idea. One reason we didn't do that, initially, is that we wanted the JKI SM template (that you drop from the palettes) to be free of any dependencies . We're considering creating some templates that will integrate into the project templates wizard that will be a little more elaborate. Including a typedef (or maybe an LVClass?) for the main cluster might make great sense. Anyone here try using an lvclass instead of a cluster?

That's great feedback, Eric. These are definitely some useful features in Top Level applications. I have a template with some similar features If you have any more ideas or input, let us know! Thanks.

[cross-posted to NI forums] Hi LAVA'ers, Over at JKI, we've soft-launched a new idea exchange for the JKI State Machine: http://ideas.jki.net/forum/31756-jki-state-machine/ I've seeded this with a couple ideas we've heard mentioned before. If you're interested in providing your feedback on ways to make the JKI State Machine Better, we'd love to hear it! In addition to feature ideas, we're also interested in knowing what types of design patterns and application examples you'd like to see. Regards, -Jim

Hi Todd, Brian, This is great to hear! Thanks for sharing your results. -Jim

I'm curious whether people are using the "separating compiled code from source" feature in LabVIEW 2013 with success. Are people still experiencing any issues? Do we trust this feature yet?

Hey Guys, I just want to mention that JKI is committed to making sure that VI Tester works well in LabVIEW. We can't live without it at JKI and it's going to continue to be improved. We've been really busy lately, so that's why there hasn't been a new version pushed out. We see the LV UTF as addressing a totally different market need than VI Tester. As I see it: UTF is great for people who want to show 100% test coverage through its static analysis tools -- NI created it to address the needs of people developing for regulated industries. VI Tester is great for people who want to do better and faster software engineering in LabVIEW -- JKI created it to help test object-oriented (and other) LabVIEW applications using the industry-standard xunit architecture. I can't comment on time-frames, but please stay tuned and don't give up on us. BTW, VIPM 2013 SP1 (one of the areas where we've been busy) was just released (do a check for updates)! We couldn't have done that without VI Tester.

Hey Mads, If you're interested in looking into this and making some specific recommendations, I'd be happy to consider them for inclusion.

Hi David, I'll work with you to get this proposed fix through the process! -Jim

I was just curious if there's been any movement on 64-bit support.

Hey Ryan. Yes, that's right. The main OpenG Toolkit is just a simple way to install everything. There's actually nothing in the package itself -- it just declares dependencies on all the individual packages.

I think it could make sense for OpenG to start moving to 2010, at least, for active development. This won't negatively impact people using older versions of OpenG, it just means that they won't be able to install newer versions of OpenG into older versions of LabVIEW. I think the benefits of moving forward outweigh the benefits of staying on older versions of LabVIEW. Also, it might make sense to change the version of OpenG Libraries to 2010 for those built in 2010 and then create a 2009 branch if any improvements need to also added to the 2009 branch.

Sweet! I'm glad this is working for everyone :-) It was quite fun to dust off my developer hat too. And I got to use VIPM 2013 which made changing the pallet names of breeze--thanks for that, Michael Aivaliotis!

I was on a roll and fixed/released the new OpenG Time and Array libraries too, so this issue should be resolved for now. Please let me know if there are any issues once you upgrade to the new versions.

Hey Everyone, I've rebuilt the OpenG File library (v4.0.1.22) with a fix for this -- I've added the "(OpenG)" suffix to the Window Title and palette names. vipm://oglib_file?repo_url=http://www.jkisoft.com/packages Please take a look and let me know if this works well. If so, I'll make the fix for the OpenG Array and Time libraries, too.

Makes sense to me

That's great! I didn't know about that (or learned about it so long ago I forgot about it)! That eliminates one of the biggest technical hurdles around moving OpenG into LVLIBs. Now it just takes elbow grease Yeah, might do an incremental fix of adding the "(OpenG)" suffix, as a stopgap. That's a great point, too! And, you just might have (arguably) found another LabVIEW bug ;p Cheers,

Would you consider this a Quick Drop bug (that brackets in a VI Window Title would cause a failure of QD)? Might want to generate a Hash of the name and use it as the UID/reference for each item that appears in the list, rather than reference by name.

Would it create any problems (for Quick Drop) to use brackets in the VIs window title so that it looks a little more like what Quick Drop adds to LVLIB members? For example: "Build Path [OpenG]"