What prevents a 32-bit developed vi or project (lvproj) containing many such vis from opening in a side-by-side 64-bit LabVIEW environment?

[Novgorod]

---

@*3d0g wrote:
How can I force the vi to open in the correct environment, always?

---

You seem to be doing a lot of heavy-duty dev management stuff, which makes it kind of odd to have the success of your "system" depend on how Windows interprets a double-click on some file in the file explorer. As everyone already said, it's the same as working with different Labview versions on the same machine, only that it does no harm whatsoever if you accidentally save the program with the "wrong" bitness - just open the "correct" bitness environment and save it again.

I always have the habit to open the Labview version/bitness I intend to run first before double-clicking on any vi files, but I also virtually never have more than one environment open simultaneously. If that's too much discipline to ask for, you can always use the command line to run the Labview version of your choice and open your vi 🙂 ...

[JimB.]

---

@*3d0g wrote:

LabVIEW 32-bit doesn't even try to actually handle the 64-bit vi block diagram.

---

You're misinterpreting what happens here. LabVIEW 32-bit isn't receiving a block diagram, so it can't attempt to handle it.

What happens if you paste a block diagram in Word? Or Paint? You get a picture. There is a difference between an interprocess copy/paste operation and one that is done within the same process. When you copy code from LabVIEW, the Windows clipboard stores a picture. When you paste into any other process it is the picture that gets pasted, not a portion of block diagram.

That has nothing to do with bitness. You fill find the same thing happens if you copy paste between two different 32-bit versions as well. For example, I currently have LabVIEW 2019 32-bit and 2020 32-bit installed. I can confirm the same thing happens if I copy paste between these two versions. It is crossing the process boundary that is the issue.

[BertMcMahan]

Crossing a process boundary works in some instances. Most Office apps can cross the process boundary just fine. For example, if I copy some shapes in Word and paste to Powerpoint, they come across as full-fledged shapes with text, formatting, etc, not just a picture. Obviously LabVIEW doesn't do this, but it's not unreasonable to expect it might work.

[*3d0g]

It's been a bit.  I'm very busy.

But here's what I've found.

To open a 64-bit created lvproj in 64-bit LabVIEW, you must have been using 64-bit LabVIEW, last on the machine.

Otherwise, even though you worked in 64-bit the whole time during the project, just because you were looking at 32-bit LabVIEW, last, your entirely 64-bit project is opening in 32-bit LabVIEW.  This has been my experience.

Next what happens?  That vi that works great in 64-bit LabVIEW now opens broken and needing to be fixed.

Now, how about swapping the situation.  You were last in 64-bit LabVIEW and doing things.  You close it.  You move over to an all-the-time-it-has-been-32-bit project.  You open it.  Is anything broken?  No.  ...not yet.  What happened?  Nothing.  You just work away, make some tweaks here and there, click save, and... Do you ever get to open your 32-bit only project any more?

So far the only solution I see is 1) pick your environment, and then 2) open your project.

[santo_13]

What is broken exactly?

Do you have an example that you can share that can replicate your observation of things broken when opened in a different bitness LabVIEW of the same version?

[rolfk]

You're hammering a problem that is not really a problem!!

The last LabVIEW instance that gets opened registers itself during startup as the version to handle all LabVIEW file types. And yes that is of course a different LabVIEW exe for 32-bit and 64-bit.

You don't want that to happen? Sure simply add the entry "RegisterExtensions=False" to the according LabVIEW.ini file. The default value is True when running in the IDE.

If you enable to separate the code from a VI in the VI settings, there is not really ANY difference in the VIs on disk between saving it in 32-bit or 64-bit. Only potential complication I can think off at this point is if your VI uses anywhere the Call Library Node and you specified an absolute path to a DLL (or the DLL has a different name depending on its bitness). In that case LabVIEW might try to load the DLL from that absolute path which would be of course wrong in another bitness!

Other than that you really need to be more specific as to what is broken. Broken arrow? Not loading? Runtime errors when you run the VI? If it is a broken arrow, which subVI breaks and why?

[JimB.]

---

@*3d0g wrote:

Do you ever get to open your 32-bit only project any more?

---

If you open it in LabVIEW 32-bit next time, yes, absolutely. A VI does not have a set bitness. If you use the the option to separate compiled code then there is no difference in the VI regardless of which environment you edited it in. If you do not use that option, then the embedded machine code will be recompiled if you open it in another environment, but this should work in both directions.

Of course, all of that has already been said in this topic! It feels like this is spiraling in circles.

What is the problem you are trying to solve? Can you create a reproducible sample? It almost seems as if you are saying that every VI that you save in LabVIEW 64-bit is broken when you open it in LabVIEW 32-bit, and that should not be the case.

[altenbach]

---

@rolfk wrote:

Only potential complication I can think off at this point is if your VI uses anywhere the Call Library Node and you specified an absolute path to a DLL (or the DLL has a different name depending on its bitness). In that case LabVIEW might try to load the DLL from that absolute path which would be of course wrong in another bitness!

---

I agree that if the code breaks when changing LabVIEW bitness, something is fragile and should be investigated. Unfortunately we did not get any useful information on what causes the problems.

If different DLLs need to be loaded based on LabVIEW bitness, a "conditional disable structure" is an easy solution. Just create cases for the two possible "TARGET_BITNESS==32|64". (As quoted here, and picture two posts down).

If you want to ensure that code is broken in the "wrong" bitness (to give you a hint that you accidentally opened it in the wrong version before doing more development) use that same conditional disable structure and have some broken code in one of the cases. For example placing the following code will break the VI when opened in LabVIEW 64 (the other case is for ==32 and empty):

[*3d0g]

---

@rolfk wrote:

You're hammering a problem that is not really a problem!!

The last LabVIEW instance that gets opened registers itself during startup as the version to handle all LabVIEW file types. And yes that is of course a different LabVIEW exe for 32-bit and 64-bit.

You don't want that to happen? Sure simply add the entry "RegisterExtensions=False" to the according LabVIEW.ini file. The default value is True when running in the IDE.

---

You may have a solution there. ...the LabVIEW installation's ini  At my next opportunity I'm going to look into that.  I wonder what it'll do.

Yes, by broken I mean broken arrow.  I opened the 64-bit version of the project.  (following using the 32-bit LabVIEW)  No issue.  Then I opened one of the main vis (the project has 2, one for test and one for use in tests,) and I got a broken arrow.

Yes, the project does use a DLL. ...picoscope's

These are great responses from you guys.  Thank you.  It helps me think through the problem.

[*3d0g]

---

@altenbach wrote:

---

@rolfk wrote:

Only potential complication I can think off at this point is if your VI uses anywhere the Call Library Node and you specified an absolute path to a DLL (or the DLL has a different name depending on its bitness). In that case LabVIEW might try to load the DLL from that absolute path which would be of course wrong in another bitness!

---

I agree that if the code breaks when changing LabVIEW bitness, something is fragile and should be investigated. Unfortunately we did not get any useful information on what causes the problems.

If different DLLs need to be loaded based on LabVIEW bitness, a "conditional disable structure" is an easy solution. Just create cases for the two possible "TARGET_BITNESS==32|64". (As quoted here, and picture two posts down).

If you want to ensure that code is broken in the "wrong" bitness (to give you a hint that you accidentally opened it in the wrong version before doing more development) use that same conditional disable structure and have some broken code in one of the cases. For example placing the following code will break the VI when opened in LabVIEW 64 (the other case is for ==32 and empty):

---

This is good stuff, thanks!

TARGET_BITNESS  I need to check that out.

(the graphic in the above, for me, is absolutely huge. I'm leaving it quoted to see what happens when it posts.)