Jump to content
News about the LabVIEW Wiki! Read more... ×
Neil Pate

LabVIEW 2017 Editing Issues

Recommended Posts

I've heard the NI argument against older issues -- there may be internal or customer-specific information, but I don't see that as an excuse moving forward.

I haven't heard that argument but I think it is a good one.  Often times I will see some odd behavior in a larger application, and then start pruning it until it is small enough to send to NI.  It often has a weird unpredictable behavior, and contains some amount of the original application.  I will send the minimized program to NI with instructions on how to reproduce it and what the observed behavior is.  From my point of view I can't say "Memory allocation when using DVRs in a reentrant inlined VI set to subroutine, causes a race condition with an IPE structure if the moon is out."  I just have weird behavior and send it to NI.  They have a bug tracking system but I assume my whole project goes along with the issue and my instructions.  I'm not sure how easily NI could expose the issue to the world to vote one, or view, without including my application.  And even if they did it might not always be clear that an issue I'm having is the same as someone else's.  I think a publicly tracked issue tracker is a good idea, and I'd like having it, I'm just saying I can see why NI doesn't do it.  Issues with JIRA, and a web browser won't contain 5,000 individual files of source code to reproduce the issue.

Share this post


Link to post
Share on other sites

Yeah I suppose splitting it up theres three sorts

  • Obvious issues: things you can get down to a simple test case, or easily describe (eg when I use quickdrop to insert delete from array onto a wire, it isn't correctly wired)
  • Crashes: They already have NIER. It would be interesting to see how common a crash you just got is, but at least they know (for the x% of labview instances that are on a network and not firewall blocked).
  • Wtfs: This is what you described, generally one-off issues

And of course I have no clue what proportion of issues fall into which bucket. Take crashes, for example-- I wouldn't guess the total quantity of distinct crash types is all that high. So if thats true, are there more clear-cut issues or wtfs out there?

Edited by smithd

Share this post


Link to post
Share on other sites

Dear Jon,

You were talking about the bug tracking. In deed, it would be very helpful for us, developers that makes promises to our boss and customer, to know when the bug are planned to be resolved. Per example the bug  493662  concerning the .net is causing problem to a lot of us. Listing a work around to use external .dll is a killer for LabVIEW reputation. and this bug is there since 2014... I personally believe that new features should be delayed till all the bug are fixed. All LabVIEW developer will be so happy to not encounter bugs that kills their planning.

So please fight fur us and represent us in front of NI to push them the importance to release a version of LabVIEW without bug.

 

Benoit

Share this post


Link to post
Share on other sites

I got some more information on the flickering. It is caused when we do a redraw of the canvas. If you slow down the video of LabVIEW 2015 and before you can actually see the flicker once, when we redraw the canvas. We introduced live redraw in 2016 which makes the flicker obvious because it happens multiple times. I did file CAR 713251 for this which one of my colleagues will prioritize among the other work his teams have on their backlog.

 

With respect to the CAR 493662, I agree that the workaround isn't great. It's only an option if you are both the author and consumer of the .NET Assembly. If you are just using an assembly installed on the system, you can't call the other constructor. This doesn't help your situation, but I have a team that is currently working on .NET for NXG and I did make this an acceptance criteria of their work. I verified in a beta build of NXG 3.0 that we are able to call both of the overloaded constructors.

Quote

 I personally believe that new features should be delayed till all the bug are fixed.

This is similar to the model we are moving toward. The Product Owners have the final say of when we toggle on a feature. It's our role to hold the line for quality and workflow completeness when it comes to turning on features. Hopefully our change in process is noticeable as we move forward.

 

Thanks again for the candid feedback here. It does help myself and other POs have a better grasp on the heartbeat of the community.

  • Like 2

Share this post


Link to post
Share on other sites
On 9/9/2018 at 9:26 PM, Benoit said:

Dear Jon,

I personally believe that new features should be delayed till all the bug are fixed.

Realistically that might mean that there is no new LabVIEW feature in many years! So I doubt that this rigorous specification is ever reasonably considered.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.