Possible Bug LV2018 Project-Library Interaction - please attempt to replicate

[szewczak]

Hello LV Forum members online today (and lets be honest, probably Hooovahh)!

I ran into consistent crash with LV2018, and I wanted to see if others can replicate it before I submit a bug-ticket. In past versions of project mode, whenever a dependency library item is added to a project the full library is added to the project folder. So far in LV2018 I get a fatal crash instead. See below or: direct YouTube link

How to replicate:

1. Create a Library File with linked vis
2. Create a Basic project with a single blank .vi
3. Add a Library VI to the Block Diagram of blank .vi
4. Attempt to move the Library now in 'dependencies' to be included in the Project file.

This was a very useful tool in previous versions for organizing projects and reusing libraries of code from past projects. Please let me know if you can replicate this behavior in LabVIEW 2018

[szewczak]

also here is the crash file contents:

####
#Date: Tue, Jun 19, 2018 10:54:55 AM
#OSName: Windows 10 Pro
#OSVers: 10.0
#OSBuild: 17134
#AppName: LabVIEW
#Version: 18.0 64-bit
#AppKind: FDS
#AppModDate: 3/08/2018 21:41 GMT
#LabVIEW Base Address: 0x00007FF631410000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors() reports: 8 processors
InitExecSystem() will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3612264896.87184238, (10:54:56.871842385 2018:06:19)]

<DEBUG_OUTPUT>
6/19/2018 10:57:19.238 AM
DAbort 0x00000001:
e:\builds\penguin\labview\branches\2018\dev\source\project\ProjectWindowDialog.cpp(85) : DAbort 0x00000001:
minidump id: f7ba20fe-968f-4e25-94dd-2c484f18c4ba
$Id:

</DEBUG_OUTPUT>
0x00007FF6318543BC - LabVIEW <unknown> + 0
0x00007FFED17A5389 - mgcore_SH_18_0 <unknown> + 0
0x00007FF63282C240 - LabVIEW <unknown> + 0
0x00007FF631C9532B - LabVIEW <unknown> + 0
0x00007FF63282A3C3 - LabVIEW <unknown> + 0
0x00007FF631D4B56E - LabVIEW <unknown> + 0
0x00007FF632B48E23 - LabVIEW <unknown> + 0
0x00007FF632B4877A - LabVIEW <unknown> + 0
0x00007FF6338BB4B1 - LabVIEW <unknown> + 0
0x00007FF6338BABBE - LabVIEW <unknown> + 0
0x00007FF63390F930 - LabVIEW <unknown> + 0
0x00007FF63397A7E4 - LabVIEW <unknown> + 0
0x00007FF63390EA92 - LabVIEW <unknown> + 0
0x00007FF63157E44B - LabVIEW <unknown> + 0
0x00007FF63157E302 - LabVIEW <unknown> + 0
0x00007FF633B43857 - LabVIEW <unknown> + 0
0x00007FF63157E847 - LabVIEW <unknown> + 0
0x00007FFEFA583034 - KERNEL32 <unknown> + 0
0x00007FFEFA861431 - ntdll <unknown> + 0

[billko]

While I cannot replicate the issue, IMHO an external library that is used elsewhere as well should stay as a dependency, just like you wouldn't include instr.lib in your project, either.

[szewczak]

Thanks Bill,

After RTFM'ing on .lvlib I agree with your advice. Quick tangent question though: How do you (as in your methods, not generally) manage class/ support vi organization in a LV project?

[billko]

---

@szewczak wrote:

Thanks Bill,

After RTFM'ing on .lvlib I agree with your advice. Quick tangent question though: How do you (as in your methods, not generally) manage class/ support vi organization in a LV project?

---

Whew, that's a tough one!  I think you'll get as many different answers as respondents!  Man, I have think about this one.  Great question!

[Ben]

---

@szewczak wrote:

Thanks Bill,

After RTFM'ing on .lvlib I agree with your advice. Quick tangent question though: How do you (as in your methods, not generally) manage class/ support vi organization in a LV project?

---

This blog may give you one way of doing it.

Libraries and classes that I am developing get put in a project but libraries that are being used but NOT being developed I just leave them to show up in dependencies.

Ben