[OSX] dialog for Browse options does not show up

[_Chris]

New VI

Add "File path control"

Right click on the folder icon

Choose "Browse Options..."

--> nothing, no dialog, nada

Tested under Ventura on Intel and AppleSilicon

Ch.

[Christina_R]

Thank you for reporting this issue! I've filed it as Bug 2410529.

[sth]

To be clear this is for all controls not just file browser.  And for all indicators as well.

[Christina_R]

Thank you for making sure this was captured!

I filed the bug against the file browser, but when R&D investigated it, they found it was all controls, so the bug was redefined to track that.

[sth]

It is a pretty big miss. So I assume it is an easy fix to get the correct link to the properties dialog.  If I am not mistaken that properties dialog is written in G.  Someday, someday, they will include the linking of indicators to network variables back into the property dialog as in windows.  I don't quite understand if it was written in G, why it is not cross platform?

[Christina_R]

---

@sth wrote:

It is a pretty big miss. So I assume it is an easy fix to get the correct link to the properties dialog.  If I am not mistaken that properties dialog is written in G.  Someday, someday, they will include the linking of indicators to network variables back into the property dialog as in windows.  I don't quite understand if it was written in G, why it is not cross platform?

---

The dev team's investigation notes say: "This was caused when the Apple Silicon version of the property pages dialog was moved to a location in Targets. Moving it back manually works around the issue. Real fix is to resolve path to .lvlibp correctly."

[sth]

@Christina_R wrote:

---

---

The dev team's investigation notes say: "This was caused when the Apple Silicon version of the property pages dialog was moved to a location in Targets. Moving it back manually works around the issue. Real fix is to resolve path to .lvlibp correctly."

---

I see, there are 2 versions of the lvlibp, I assume one is the arm64 and one the x86 version.

% find . -name PackedPropertyPageLibrary.lvlibp -ls                     

694646 Apr 10 17:01 ./Targets/mac-arm64/resource/PropertyPages/ControlPropertyPages.llb/PackedPropertyPageLibrary.lvlibp

673819 Apr 10 17:00 ./resource/PropertyPages/ControlPropertyPages.llb/PackedPropertyPageLibrary.lvlibp

They are different sizes and slightly different dates.  If these are LV then the compiled code should be separate and they should be the same files?  Moving the arm64 version would overwrite the x86 version?

[Craig_S.]

Yes, copying the version from Targets to the main location will fix the issue for arm64 but overwrite the x64 version; you should save it off if you want to be able to run both.

To support Apple Silicon, LabVIEW ships as a universal executable, and uses the VIObjCache to maintain separate VI code for Intel and Apple Silicon.  Built applications and frameworks store their code in an embedded LLB, which can support both architectures by using two different filenames.   However, LabVIEW PPLs are standalone binaries which do not use the VIObjCache and do not have a universal storage format, so they need to have two different user-visible files.   In this case, we locate the correct one via unique search paths, but there was a bug in the implementation for the property pages.

This issue is fixed for the release.

[sth]

Thanks Craig!  The problem of multiple architectures takes some careful planning and could be integrated with some sort of path variable, but it is unclear if that kind of effort is worth it these days.

But that clarifies the two different files I found, and need to preserve the arm64 and x86 versions to go back and forth.