Jim Kring

I've been using Jott for several months now and think it's an indispensible service. I've even got Jott on the speed/voice dial of my cell phone, so I don't even need to press any buttons to dial it :thumbup:

Hi everyone, Thanks for the TALM nomination and for all the kind words. The LabVIEW community, especially LAVA, has been a great resource and outlet for my LabVIEW passion. The people who make up this community are a pleasure to work with and have as friends and colleagues -- how would anyone not want to be a part of it? Thanks, -Jim PS - crelf must really be a glutton for punishment -- I start pressuring him to get to work on his OpenG toolkit candidate and then he nominates me for an award

Here's a fix for the remainder > 0 bug: Download File:post-17-1206073613.vi

QUOTE (Daklu @ Mar 20 2008, 12:42 PM) So, what are you waiting for? Let's get them up to speed about OpenG -- start them off on the right foot, early

QUOTE (Norm Kirchner @ Mar 20 2008, 09:13 AM) Hi Norm, In an effort to keep the discussion in one spot, I have responded to your question on the OpenG thread, http://forums.openg.org/index.php?s=&showtopic=820&view=findpost&p=2070' rel='nofollow' target="_blank">here. Thanks,

QUOTE (Justin Goeres @ Mar 20 2008, 07:55 AM) Justin, That looks like it might make for a good OpenG candidate -Jim

Eugen, I'm looking forward to seeing your blog and tutorials. It sounds like this is something that you are very passionate about. One piece of advice that would give you, is to focus on creating something special/unique that you are passionate about and strive to do it better than anyone else. Cheers, -Jim

There is a great discussion happening, as we speak, to debate and improve the design of a new candidate VI for the OpenG Toolkit called Average 1D Array. The discussion is happening here. If you like using the OpenG VIs and want to help improve them, this is a great opportunity.

QUOTE (Justin Goeres @ Mar 19 2008, 10:47 AM) Losing to Justin did hurt. But, when I saw a guy roll the score counter at 999,999 I felt very small

QUOTE (Aristos Queue @ Mar 17 2008, 07:40 PM) If modifying tip strips is editing a VI, then how come we're allowed to do it at run-time? IMO, the design of the tip strips feature is flawed (design bug). I can understand how changing the default value of a tip strip should not be allowed in clones, since default values are necessarily persistent. However, changing the tip strip's current value should certainly be allowed, just as we can change a control's value, run-time menu items, context menus, etc.. It seems to me that any VI/Control property which can be changed at run-time that is also considered a modification that can't be performed on a clone should be broken out into default value and value. :2cents:

QUOTE (Michael_Aivaliotis @ Mar 17 2008, 04:36 PM) I agree. If performance is the issue, then there should be some setting that toggles between these two extremes: clones used for programmatic functionality vs. clones used for user interfaces. Rarely do I care about gray areas in between these two extremes (except when debugging instances).

QUOTE (Christina Rogers @ Mar 16 2008, 06:50 PM) PS CAR# 96951 was marked as a duplicate of CAR# 49855. Thanks for confirming and for the work-around. I've updated the CAR# in my original post.

QUOTE (Justin Goeres @ Mar 16 2008, 10:58 AM) Hmm... do you think that the/a reason NI went to 8.5 instead of 9.0 is that people stopped upgrading to X.0 releases after 8.0?

QUOTE (tcplomp @ Mar 16 2008, 03:01 AM) A long time ago, when LabVIEW was on a X.0, X.1, Y.0, Y.1 release pattern, we decided that when LabVIEW released a N.1 release, it was probably OK for OpenG to switch development to LabVIEW (N-1).1 (for example, when LabVIEW 7.1 was released, it was OK for us to start using 6.1). When 8.0 was released, it was really buggy. This mean't that a lot of people didn't upgrade from 7.1 to 8.0. And, most people gradually upgraded as 8.2, 8.2.1, 8.5, and 8.5.1(?) were released -- but, they skipped 8.0 and went to 8.2 or greater as quick as they could. I think the fact that 8.6 is getting close to release means that it's probably OK to jump to 8.2. And, there is enough significantly new stuff in LabVIEW 8.2 that it makes pretty compelling argument for OpenG Developers to add new stuff. And, cool new OpenG features/tools will attract more people to use OpenG. I think it's important to also re-stress the fact that this change will only effect new released of packages. All our existing code that uses OpenG in older versions of LabVIEW will continue to work. QUOTE (Michael_Aivaliotis @ Mar 15 2008, 08:03 PM) Maybe people should update their LAVA profile with the LabVIEW version used. Then I can query the database for a complete list. :ninja: Michael, Seeing the profile data would provide some interesting statistics. I'd be interested to see the LabVIEW version bin count for Primary, Secondary, and Tertiary LabVIEW versions used, with users filtered by some total post count and/or recency threshold (to ensure that the quality/freshness of data is good). But, we should keep in mind that there is no fool-proof way to ensure that the profile data is fresh, except for new users (unless the profile data is stored in new database records each time the data is modified or there is some other profile modification time stamp). Also, the profile contains Primary, 2nd, and 3rd LabVIEW versions used. It doesn't really ask the question: Which LabVIEW version do you use when starting a new project? I'd be inclined to think that the answer to this question would likely be the highest LabVIEW version in the combined set of LabVIEW versions used, for each user. For example: for each user in allUsers: user.max = max([user.primary, user.secondary, user.tertiary]) -Jim

QUOTE (crelf @ Mar 15 2008, 12:57 PM) Here is my analysis of the initial poll results: 90% of people are using 8.2 or greater for new projects nobody is using 8.0 (must be buggy) 6.66% are using 7.1 3.33% are using 7.0 I think that its probably safe to start using 8.2 for OpenG development. This will greatly simplify our process, since it's damn hard (in many cases) to support 6.1 and 8.x at the same time. Certaily, we'll want to wait until more people have a chance to respond to the poll -- there are only 25 people who have voted, since the poll was created yesterday, and most polls on LAVA tend to get anywhere between 75 and 125 votes.

QUOTE (Yen @ Mar 15 2008, 11:20 AM) It's good to hear that you are upgrading -- you were on my list of concerns

As usual, I am curious about how people use LabVIEW -- please take the poll (above) and let me know your thoughts. This time, I'm interested in your opinions, because I want to know how best to support OpenG users. Right now, almost all OpenG libraries are compatible with 6.1 or greater. But, that means that we can't easily support certain new data types like the time stamp, 64-bit integers, or LabVIEW objects. I'm curious how many users we might stand to alienate by starting to use new versions of LabVIEW for subsequent package releases. Keep in mind that you will still be able to use existing versions of packages that support 6.1 or greater. It would only be newer releases that would be limited to newer versions of LabVIEW and these new releases would likely come, as a result of needing to support new data types and LabVIEW features.

QUOTE (Aristos Queue @ Mar 14 2008, 10:36 AM) It kind of reminds me of a Flying Toaster... http://lavag.org/old_files/monthly_03_2008/post-17-1205517813.gif' target="_blank">

QUOTE (Aristos Queue @ Mar 14 2008, 07:42 AM) Wow! That's news to me. I guess that I'm just used to accessing LVClass members from the LabVIEW project environment. I don't really ever think to put them in the palettes.

QUOTE (Aristos Queue @ Mar 12 2008, 07:32 AM) Thanks for your support The reason that I was worried that this would be considered a "feature" is that the "Close VI Reference" function does not wait until a VI is unloaded from memory before it returns (See this old info-labview thread: http://sthmac.magnet.fsu.edu/cgi-bin/ILVsearch/search.pl?Match=1&Realm=ILV2003&Terms=%22Bug+-+Close+VI+Reference+and+App.AllVIs%22' target="_blank">Bug - Close VI Reference and App.AllVIs) -- that's why we created the OpenG "Wait on VIs Unloaded from Memory" function. It seems ironic that 5 years later I realize that the inverse problem is occurring in "Open VI Reference" and the workaround is to create a "Wait on VIs Unloaded into Memory" function. [update: CAR# 96951]

I'll bet a dollar that someone from NI says that this is not a bug, but it's really bugging me, nonetheless... When you open a reference to a VI by path, which was not previously in memory, there is a small time delay between when the Open VI Reference funtion returns (returning a valid VI reference) and when the VI appears in the App.AllVIs array, which supposedly contains the list of all VIs in memory. To me, this seems like a bug -- I have a reference to a VI in memory and it's not in the list of all VIs in memory. In my opinion, the Open VI Reference function should update the list of AllVIs before it returns to its caller. :2cents: Download File:post-17-1205274083.vi

[cross-post] Noel Adorno just posted several items in the NI Developer's Feature Brainstorming forum on changes to the LabVIEW directory structures (mostly due to vista security). Here are the threads that she started, today: System directory access and LabVIEW directory changes System Dir Access: Right set of directories? System Dir Access: Cross-platform use? Sys Dir Access: Other needs? LabVIEW Dir Changes: Agree with Goals? LabVIEW Dir Changes: Goals met? LabVIEW Dir Changes: Concerns? It is very important for OpenG/LAVA developers to participate in this discussion, because it will impact how our tools integrate into the LabVIEW development environment.

QUOTE(crelf @ Mar 7 2008, 11:33 AM) Or until some moderator deletes it

QUOTE(crelf @ Mar 5 2008, 08:19 AM) They'll have to take us both