Community Nugget, 02/27/2008

[parthabe]

In LV 8.5, the following error occurs, if th CCT is opened from the splash screen.

[TCPlomp]

parthabe,

thanks. After that the Getting Started window is visible right?
I will file a bug report stating:

"Capturing of a BD protected VI is killing the CCT in an unwanted way"

tbob,
are you sure you have version 1.0?
You can 'revive' LabVIEW by opening a VI from disk and selecting View->Getting started Window

I'll test today at work.

Ton

[tst]

This might be a bug with 8.2, since it doesn't seem to happen in later versions.

I already implemented something which I think will fix it - if the tool can't access the diagram (locked, missing, etc.), it simply disables the options for the diagram. A quick test seems to indicate that this helps with the Getting Started Window as well, but the problem with 8.2 might be deeper.

That said, I don't know when we'll release the next version. If there are a lot of bugs, maybe soon.

[tst]

Now I remember something.

In 8.0, the GSW was implemented in such a way that opening anything in it would remove it from memory, so you would get this message:

NI later changed it so that it remains in memory, but I believe they only did that in 8.5. I suppose that it is theoretically possible that if we try to open a VI which is no longer in memory we get stuck somewhere and our code continues to run with no front panel open.
I would say that the most likely source is the panning process. Maybe it doesn't have time to register the stop event before the event is fired and so gets stuck in the loop.

[tst]

---

tst wrote:

I would say that the most likely source is the panning process. Maybe it doesn't have time to register the stop event before the event is fired and so gets stuck in the loop.

---

After a bit of testing, this does seem to be the case, which means it's a simple race condition.

Solving it is easy - we just need to make sure the process VI doesn't start or that it terminates correctly if there is an error.
At least the first option is simple - we add an error input and connect it to the error coming from CCT VI.

[TCPlomp]

I tested the 1.0.0 version with LabVIEW 8.2 from the Getting started window and don't have an issue.
Tbob did you use a customized GSW?

Maybe we should ask for the password if the  BD is locked? or only after the setting changed to BD capturing?

Ton

[tst]

---

TonP wrote:

Maybe we should ask for the password if the  BD is locked? or only after the setting changed to BD capturing?

---

I already changed it (although I didn't commit yet) - if we can't access the BD, we don't allow the user to. If they want, they can unlock the VI before they open the CCT.

In any case, we do have a race condition for closing the panning process, which needs to be handled.

[tbob]

This is very strange.  Yesterday I would get the error "The VI is not in memory  ---   GSW_Main.vi", and then Labview would just go away.  Today I get the follwoing error and then the Labview splash screen returns.  I didn't do anything different.

Message Edited by tbob on 02-29-2008 08:42 AM

[tst]

Are both of these on the same computer using the same version of LabVIEW?

There may be two different race conditions in effect.

We have one for sure, because there is currently a possibility that the stop event will be fired before the Pan VI registered for it, leaving the Pan VI running and resulting in what you saw (no LabVIEW window open, but the process still runs).

LabVIEW might also have one. I'm not sure how opening the reference works in 8.x, with the different instances, but it's possible that LabVIEW tries to open a reference to a VI currently in memory. Then, if the GSW unloads before the CCT loads, you get the "not in memory" error. If it doesn't, you get the 1040 error. In any case, not getting the GSW back is probably our bug.

[Rod42]

Hi, I;ve using the CC tool for a while and have discovered a couple of minor issues

1) I got the same problem of the BD alignment grid being turned off (as per craigc in msg 17)

It did happen with a real VI to capture, but I could only reproduce by....

Ensure that you have the BD alignment emabled. Start a new, empty VI. From the BD, Tools-> code capture

Clink on the Code Captire window's X. Note that the region that was occupied by the CC window has no grid.

Go to the options, and note that the grid alignment is now off.

2) If the BD is minimised when the CC tool is opened, the "All" option doesn't capture all of the BD. As an example look at the attached fred.vi. Have the FP open and BD minimised. Do a capture, setting both BD and FP to capture All. The BD is incomplete. All is OK if the BD is open. I don't have a problem if the BD is open and FP closed. Moving the BD items around causes different bits to be omited.

See attached fred.vi and captured image fred.png (Setting both BD and FP to All, with the BD minimised)

Interesting!

Rod.

EDIT: LV 8.2, Dev Suite, CCT 1.0.0 Build 139

Message Edited by Rod on 09-29-2008 04:34 PM