LabVIEW RTE Search Paths Capitalization [LV/TS]

Not sure if this belongs into LV or Ts so I'm posting on both.
I'm getting the following error when I try to run a sequence in TestStand 4.1 with the LabVIEW 8.5 RTE as my adapter.
Is there a flag in the ini config file that I can set to make my paths not case sensitive???
Thanks,
<<-N->>

Hi
Jonathan,
We found a workaround moving the folders around and that seems to fix the problem. I talked to a support engineer on the phone yesterday and he confirmed that this was a bug in the TS-LV adapter.
This is the procedure we are following to fix the problem:
Create a new VI in C:\MyProject\Projects\Component\Everything.vi
Add all the VI's within Component as sub-VI's to "Everything.vi"
Close LabVIEW
Move the whole directory of C:\MyProject\Projects\Component to C:\Component
Open Everything.vi. Help find the VI's it is having a hard time finding.
Close LabVIEW
Change C:\Component\Product\Common to C:\Component\Product\xxommon
Open Everything.vi. it should automatically find everything without asking you for help
Close LabVIEW
Change C:\Component\Product\xxxommon to C:\Component\Product\Common
Open Everything.vi. it should automatically find everything without asking you for help
Close LabVIEW
Move Component back under MyProject directory structure
Open Everything.vi. Help find the VI's it is having a hard time finding.
Close LabVIEW
Cross your fingers and see if it works this time.
<< - N - >>

Similar Messages

LabVIEW RTE Search Paths Capitalization [LV/TS]

Not sure if this belongs into LV or Ts so I'm posting on both.
I'm getting the following error when I try to run a sequence in TestStand 4.1 with the LabVIEW 8.5 RTE as my adapter.
Is there a flag in the ini config file that I can set to make my paths not case sensitive???
Thanks,
<<-N->>
Message Edited by << - N - >> on 07-01-2008 11:57 AM
Attachments:
Error2.JPG ‏32 KB

Nice Error ; )
For me it looks like a TestStand Error - Did you tried what's written : To find all the steps who call "tkwca200 basic setting.vi" and select load dynamically into the TestStand Step option.
Another idea is to have only one step who call this VI and see if it work..and then add another one, and see what happen.
Hope it will help
Chris (not very good in TestStand..)

Labview doesn not care about "vi search path "?

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

We've had some problems with labview taking sub vi's from other library files than wanted. To clean up the mess once and for all I wanted to include the path to the active library files, and remove the <foundvi> from vi search path.
The added path is something like "\\acanova5\common\...", also tried the version "\\192.168.0.50\common\..."
So far so good, but when I open a vi that need sub vis (before located in now deleted lib files) LV don't find them. When then manually point to the lib file and point to the vi it is ok, but why doesn't it work as I expect?
I looked in labview.ini, and my path is the first in "vi search path" list.
Ola

[Help] LabVIEW Search Paths Questions...

Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
Christopher Povey
Senior Test Systems Engineer for BAE Systems.
Solved!
Go to Solution.

ChristopherPovey wrote:
Is the "Tools" \ "Options" \ "Paths" \ "Search Paths" stored on the PC that is running LabVIEW or stored in the currently opened VI?
It is specific to that PC. It is stored in the labview.ini file.
Also can I specify relative search paths for example: "<topvi>\..\..\..\Library\MyLib\*"
You can, but that's not really the solution to your problem.
Is the search recursive? i.e. If there are subfolders, with subfolders will it drill down looking for the missing VI's?
That's what the asterisk at the end signifies. From the LabVIEW Help:
After you select the directory, LabVIEW inserts the path in the text box to the right of the Browse button. You can edit the path in this text box. When you select a path, LabVIEW normally searches that directory but not its subdirectories. You can make the search hierarchical by appending an asterisk (*) to the new path item. For example, enter LabVIEW/*, LabVIEW\*, or LabVIEW:* to search LabVIEW and its subdirectories.
The issue I have is that I have a project in a directory structure defined by a configuration control program i.e:
Y:\Test Equp\Project\Modules\Library\MyLib\* (there may be one or more sub folders contain VI's).
Y:\Test Equp\Project\Modules\MyApplication\* (there may be one or more sub folders contain VI's).
On the target the structure might be:
C:\Final\Library\MyLib\*
C:\Final\MyApplication\*
The issue is when I copy the files from Y: on my PC to C: on the PXI rack and open the top level VI in "MyApplication", LabVIEW cannot see the files in the "MyLib" until I tell where one VI is in each sub folder in "MyLib". This is a pain, specially if I make changes and transfer the file back to my PC as I have too go through the process again!
If I can spec a search path for the library files then it should just find them on either my PC or the PXI rack...
Thanks
The location of subVIs is saved with a VI, and it's a relative path. Since you are moving both directories there shouldn't be an issue finding the subVIs when you open the top-level VI, so it's not clear why there's an issue here. Are you loading VIs dynamically?

VI Search Path not working in LV2011 for VI Server Plug-ins with exe

I have found what seems to be a problem with the search path when a LabVIEW 2011 built executable calls a Plug-in VI.
When the plug-in VI has subVI’s from vi.lib on its diagram the executable has to know where to find them. Not all VI’s in vi.lib are part of the run time engine or the dll’s that may get generated as part of the build. The things you have to do to make plug-ins work for an executable are explained in several Developer Zone articles. The article titled “How Can I Change or Set the VI Search Path for LabVIEW Executables” describes the ini file setting viSearchPath. When this is set to the vi.lib directory I have not encountered problems with previous versions up to and including LabVIEW 2010.
I have come across an example in LabVIEW 2011 where it doesn’t work. I have attached an example (I am using LV2011 SP1). It demonstrates the basic plug-in architecture. Everything works in the development environment. But it doesn’t work from a built exe. I haven’t included the actual built exe in the zip file in case that causes a problem downloading it. If you run the build spec from the src directory project file the exe should get generated in the bld directory. The problem appears to occur when certain VIs from the analysis library are in the Plug-in. In the example attached, the Plug-in VI is very simple but I have placed the troublesome SubVI on the diagram. The VI in this example where there is a problem finding it is the Butterworth Filter VI. I have placed it on the diagram in a conditional disable structure so it is easy to enable and disable. When enabled and you run the test Plug-in VI the error 1003 is raised, meaning a subVI cannot be found in the dynamically called VI (for example see this post). Note that a way round this may be to incorporate the Plug-in VI into the built exe but this shouldn't be necessary. It’s not a problem with this specific filter VI, as it occurs for other VIs I try on the diagram. However if you place an FFT VI on the diagram there is no problem. I suspect that one is built into the Run-Time Engine.
I also note I am running Win7 64 bit and 32 bit LabVIEW (note the relevant viSearchPath in the ini file – you may need to change if you are on different version of Windows). If the example is converted to LabVIEW 2010 everything works as expected for the built exe. I tried that on a colleague’s computer running XP and 2010 but I am pretty sure in still also works on Win 7.
Things I am suspicious of are that the analysis VI’s are part of a LabVIEW library (lvlib) and perhaps something has changed there? I understand there is a problem with OOP in LabVIEW 2011. Perhaps it is related to that as that seems to be an issue in 2011 (see this Discussion Forum post). Perhaps it is related to OS version?
I also tried generating a Source Distribution to extract out all the vi.lib VI’s and place them directly in the Plug-in directory. That didn’t help.
Interested in whether anyone else reproduces this behaviour. In any case something is different in 2011.
Attachments:
LV 2011 test Plug-in.zip ‏42 KB

I found some more out about this issue working with my local NI rep here in Australia. Apparently something has changed in the compiler between LabVIEW 2010 and 2011. Using the viSearchPath token in the ini file, as described in various Developer Zone articles, now guarantees that the Plug-in will not work. The only way to make it work appears to be to create a Source Distribution. I noted in my original post that I had already tried this and it would not work. It turns out that having the viSearchPath token in the ini file when using a Source Distribution causes the error 1003 to occur. When the token is taken out of the ini file the Plug-in (containing an analysis VI) with a Source Distribution works - in the simple example I posted.
Well I then found its a bit more complicated than this. It all worked for the simple example I posted. Recall we found the error when there was an analysis VI in the Plug-in VI. In our actual application (which is a large one) that calls Plug-ins - we still got the error 1003. By trial and error I found a workaround. There are certain Build Spec settings for the calling exe that I set and found worked. On the Additional Exclusions page I found that I had to make sure that I left unchecked "Modify Project Library File after removing unused members". I've always had trouble understanding the need for this setting. In the Build Spec Help on that page it notes that the build will take longer. In most builds you remove polymorphic VI instances, remove unused members of Project libraries and also Modify the project library file after removing the instances (this is a sub setting of the previous). This makes the exe smaller in size and a quicker build time. Obviously modifying the project library caused a problem. In the big application exe calling Plug-in, I probably have the same analysis VI on the diagram (I haven't actually checked and also whether it is the same polymorphic instance) and in the simple example I posted I definitely did not have VI in the calling exe example - so there may be some clue there. I should try putting the same analysis VI on the calling exe diagram in the simple example to see what happens but I'm running out of energy on this one :-(
So none of this gives me much confidence and I wish I could get a better explanation from NI regarding this behaviour to be sure I am not going to encounter a different problem for different calling exe and Plug-ins. I was advised that a CAR would be issued. Perhaps this is now expected behaviour for 2011 but it would helpful if some definitive explanation could be given about what has changed from LV2010. And an update of Developer Zone articles on the subject would be helpful.

TestStand 4.1.1 vi search path

    This is so low-level I'm almost embarassed to ask. I'm using TestStand 4.1.1 over LabView 8.6, both of which are licensed as full development systems.
In order for our organization to make better use of (non-NI or Labview) source control, we've created a common directory structure for several developers over several large TestStand/LabView projects. This includes areas for "common VIs" that are reused across projects. So I'm in the process of migrating a rather complex project into a new directory structure. The sequences and VIs in question were working perfectly under TestStand 4.0/LabView 8.5 prior to this attempted migration.
   My test sequences (and sub-sequences) can't seem to find needed VIs, even though they exist in directories that are included in the search paths I configured. (An annoying sub-problem is that TestStand appears to "hang" while the LabView interface underneath the TestStand window is prompting for a VI's location. I have to click the LabView item in the Windows menu bar to get LabView "on top" and see what the problem is.)
   I've already added several paths to both the LabView and TestStand VI search paths, and I've even checked the "search subdirectories" box, but the items are not being found. It's going to take weeks to lead TestStand and LabView by the nose to find all this stuff.
   I can't believe this would really be a bug. I tried searching the forums for an answer and had no luck. I can't be the first one with such a problem, so help me out with some search terms so I don't have to clutter the forum with such basic stuff. Thanks.
-M

trosier, Neurotika,
It appears as if LabVIEW is having trouble finding your VIs, not TestStand. When TestStand loads the VI you have designated as a code module into memory, if you have the LabVIEW development environment designated in the LabVIEW adapter settings, we tell LabVIEW to load the VI via its ActiveX interface.
If TestStand is unable to find the top-level VI, you will see a dialog like this:
If LabVIEW is unable to find a sub-VI, you will see a dialog like this:
Notice that the TestStand dialog has an additional checkbox at the bottom that allows you to select an absolute path. Also notice that TestStand specifies what file its looking for in the Files of Type box while LabVIEW allows you to choose All LabVIEW Files. Which dialog are you seeing?
Another way to test this is to try to open one of your VIs from disk (by double-clicking on it). If you get a Searching for SubVIs dialog, then it is LabVIEW that can not find the dependencies.
Or if you open the specify module pane of the sequence editor, if TestStand cannot find the top-level VI, you will see a file not found warning like this:
If TestStand can find the file, but LabVIEW cannot find a sub-VI, then you will not get a warning or error until the VI is loaded.
The reason that this matters is that TestStand and LabVIEW do not share their search directory lists. If you have moved files, you will need to know which application cannot find its files.
Message Edited by Josh W. on 04-23-2009 11:27 AM
Josh W.
Certified TestStand Architect
Formerly blue
Attachments:
subVI not found by LabVIEW.JPG ‏31 KB
TestStand file not found.JPG ‏7 KB
VI not found by TestStand.JPG ‏31 KB

Vi search path

Hello all,
I have a problem with "vi search path" in Labview.
First, here are information about our directories architecture to understand the problem.
We are using the following architecture for our developments:
Each project is located in a specific directory.
ex: Project 1 is located in D:\Data\PRJ1
Project 2 is located in D:\Data\PRJ2
In the project directory, there is a subdirectory called "TestTools".
All Labview developments for a given project are located in this directory
and its subdirectories.
ex: D:\Data\PRJ1\TestTools
In the TestTools directory, there are subdirectories:
--> ...\TestTools\Tests : containing test VIs (top level)
ex: D:\Data\PRJ1\TestTools\Tests\Test1.vi
D:\Data\PRJ2\TestTools\Tests\Test45.vi
--> ...\TestTools\Utils : containing sub-vi for the tests.
ex: D:\Data\PRJ1\TestTools\Utils\HF\HF_cfg.vi
D:\Data\PRJ2\TestTools\Utils\CAN\CAN_start.vi
If I add "[topvi]/*" in the "vi search path" menu, Labview will search
the sub-VIs for my application in the directory of the toplevel VI (and its sub-directories).
ex: if I open "D:\Data\PRJ1\TestTools\Tests\Test1.vi", Labview will search the sub-VIs
in the following directory: "D:\Data\PRJ1\TestTools\Tests".
Labview will not be able to find the sub-VI called "HF_cfg.vi" which is
located in "D:\Data\PRJ1\TestTools\Utils".
I can add "D:\Data\PRJ1\*" in the "vi search path" menu but It will work only for Project 1,
and it will not work for Project 2.
I must replace it by "D:\Data\PRJ2\*" to work with Project 2.
If I don't do that, Labview will not find sub-VIs for the tests of Project 2.
(or it will find wrong sub-VIs located in the directory of Project 1 !!)
This is a problem because we often switch from one project to another.
We close and re-open Labview when we switch from one project to the other to be sure
that Labview is not using VIs already loaded in memory, but we still have problems
with "VI search path".
Is there a way to configure Labview to search sub-VIs from an upper directory
that the topvi directory?
Something like that: "[Topvi]\..\*"
(the parent directory of the topvi directory, and all its sub-directories).
I tried "[Topvi]\..\*" but Labview does not support this type of directory.
Someone suggested me to use "Source code control".
I am using Labview Full Dev (not Labview Professional) so I can't use "Source Code Control".
Is there another solution for my problem?
Thanks for your support.
NLu

Dear NLU,
the behaviour is somehow strange. I have projects with some similar folder layout in which sub-VIs are located under ..\..\DMS\sub.vi relative path from the toplevel VI. The search path is set to default. These VIs are really sub VIs not dynamically loaded. The toplevel VI holds the relative path to its sub VIs if they are on the the same drive and the absolut path if the drive is different. This is a least true from LV 3.0.1 to LV 7.1 under all Windows OS I have used (95 and ME I haven't used).
Unloading LabVIEW when changing the project is absolutly neccessary since LV holds a list of all folders where it have found VIs during a session. If you switch from PROJ1 to PROJ2 LV will load VIs with the same name in PROJ1 and PROJ2 but with different paths from the path used during working with PROJ1. Unfotunatly there is no menu entry for "Empty VI found list".
The solution provided by Evan can be made simplier. Create a shortcut to LabVIEW and use the command line parameter -pref to load the desired preference file. Look in the help under "LabVIEW-Defined Command-Line Arguments" for the exact usage.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Can I programmatically change the VI Search Path?

I'm writing a simple program to periodically mass compile certain directories of my source code. In my directory structure I try to enforce rules about what is allowed to depend on what, so I want to programatically enforce this during the mass compile. To do this, I'd need to modify the VI search path before each directory is compiled. Is there any property or method available for changing the VI Search Path?

There is, but it's a private property, so it's not documented, and its behavior and/or availability can change with subsequent releases of LabVIEW:
Message Edited by smercurio_fc on 10-24-2007 05:24 PM
Attachments:
Example_BD.png ‏2 KB

How can I install labVIEW to another path?

Greetings,
I am trying to install labVIEW 8.2.1 for our R.H. Linux labs campus wide.
I am able to install the software onto a single machine.
And in the installation script it outputs:
NOTE: LabVIEW will install by default in /usr/local/natinst/LabVIEW-8.2,
or in the natinst/LabVIEW-8.2 subdirectory if you specify an alternate location.
But it doesn't say how to specify an alternate location.
I need to install labVIEW into:
/afs/bp.ncsu.edu/dist/labview821/
which is a network filesystem we have here. Most of our commercial apps are installed this way. Your app is the first
commercial app I've had to install that uses RPM instead of a tarball.
I can't install the RPMs on every machine on campus because we only have root access
to a small subset of these machines. In the past we've been able to install apps into
AFS space and have anyone on campus be able to access the application.
(By adding each apps bin/ in the network directory to the search $PATH)
So I want to put labview in
/afs/bp.ncsu.edu/dist/labview821/bin/labview
instead of
/usr/local/bin/labview
Will this be possible with labview? Or will labview only work if installed on a local hard disk drive?
Thanks,

Greetings,
We have a site license for the college of engineering.
I was never prompted for any licensing info for the Linux version. (Durring install or running the labview
app post install on my test machine) I know some of our employees set up a LabVIEW license server. I know its IP address...
(152.1.68.81)
How do we specify that the Linux installed software should use that? Is it done via an environmental variable? Or does only
the windows version of the software use the license server? The Linux version appeard to have no copy protection? I never was prompted for
serial numbers or anything...
I also tried using the
./INSTALL --no-rpm
command line option to install the app but it failed to give me a way to specify a new install location. In fact, it seemed
to still use rpm for its install.
I looked at the readme.html docs on the install CD and it refered to a pdf that you can only read
after installing the program. (To learn how to install the software you first have to install the software)
This document was called: "LabVIEW release notes."
ON page 8 of "LabVIEW release notes" it says:
LINUX:
Complete the following steps to install LabVIEW for Linux.
1. Log into the system as root.
2. Insert the LabVIEW 8.2 installation CD. Uswe mount /mnt/cdrom to
   mount the CD. On some systems, the CD mounts automatically.
3. To change the current directoty to the mounted CD, enter the
   following command:
   cd /mnt/cdrom
4. To run the installation script, enter the following command:
sh ./INSTALL
5. (Optional) Install LabVIEW add-ons. Refer to the Installing LabVIEW
   Add-Ons section of this document for more information.
6. (Optional) Install and configure National Instruments hardware. Refer
   to the INstalling and Configuring Hardware section of this document for
   more information.
7. Refer to the Where to go from here section of this document for more
   informationabout getting started with and using labVIEW.
The INSTALL script prompts you to enter the directory where you want to
install LabVIEW, which is typically /usr/local.
But the install scipt never prompts you like it says it would in the release notes.
Maybe it did that in version 8.2 and doesn't in 8.2.1? (And they just forgot to update
the documentation or its just wrong?)
If rpm is the only supported option for installing the Linux version and if it can't
be relocated than we can tell the departments paying for the site license that
they will have to run the program only on our 200 or so Linux lab machines. Not their
Linux machines hooked up to whatever instruments they plan to interface with this
software.
But before I tell them that I'd like to hear someone tell me that what I'm trying to do
is impossible. (Install LabVIEW on a network directory) I am having a hard time
finding any further installation documentation for the Linux version on the ni website.
And the documentation I've read from within the program in the form of the Release Notes
seems to have errors.
Many thanks for any ideas anyone has.

Including a LLB into the Teststand search path

Hello everyone,
on a testsystem I am using Teststand 2013 and Labview 2013. There are different measurement instruments in my system and right now I have all the VIs for controling these instrumtens saved as VIs on my system. Now I want to change this into an LLB. But when I do that, Teststand is no longer able to find the VIs inside the LLB, although the LLB is in the serach path of Testand. Since a lot of Sequence files access these VIs, it would be a lot of work to manually edit each VI call. Is it possible to include the LLB into the search path?
Thank you very much for your help!
Felix

Hi,
The search within a LLB is not supported within TestStand.
You need to update your vi path in the step settings like "MyLLB.llb\In An LLB.vi"
i.e. modify the path as llbname\\existingviname.vi.
If you put the llb in a relative path it should be fine.
Regards,
Ravi

Associate different vi search paths according project

HI
i Would like to know if it is possible to associate the option VI search Paths with the project
like this you can have different vi search paths for each project you handle
I have read that it can be possible with labview.ini but I have not seen how to do that
Thanks for your help

I believe this is what you are looking for:
How Can I Change or Set the VI Search Path for LabVIEW Executables?
If not, post back with some additional details on what exactly you want to achieve.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

How to search paths work?

I can not get the search path to find a VI that is saved in an LLB file that is located in the same directory as the LLB file that contains the TOP-VI. My search path include both "topvi" and "topvi"\* but Labview will not search through the other LLB file, it only search the TOP-VI LLB file and through the directory itself.
I don't want to add any specific search paths for special directories. I think that using basic search paths, Labview should at least search all LLB files within the directory that contains the LLB file where the TOP-VI is located.
I know that I can just find the files manual and then save the VI but I am trying to understand how the search path is supposed to work?
What am I doing wrong? Is this a bug? Is there a work around or special search path that I should add to the options to make Labview search through all the LLB files?
Thanks
Roger Bald

Roger,
I see what you mean. This does seem a bit odd. If the subVI is relocated into the same library as the top level, it finds it, but not if it's moved into another library, or even moved to the same directory as the top level and not put in a library.
I tried this with the default VI Search Path setup, then added the <foundvi>\* to the path and got the same thing.
It does seem that there should be a way to have it search through the entire structure of the top levels directory.
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

Search Path Field Height

We have a large LV developer user base and our users are getting confused by the limitations on the search path fields. The lowercase q really looks like a q (see below), any ideas on how to change this to make it more clear?
Thanks!
Using LabVIEW2012 32bit

Ironically, in your message both characters "lowercase g and looks like a q" they both look the same. I understand, looking at the image that you are saying lowercase G and lowercase Q look the same, apparently because the field height clips the image?
Putnam
Certified LabVIEW Developer
Senior Test Engineer
Currently using LV 6.1-LabVIEW 2012, RT8.5
LabVIEW Champion

Office 2013 with Service Pack 1 installation error about "search path"

I have an automated installation technique that has worked fine with Office 2010 Pro Plus (32-bit), incorporating the latest Service Pack into the network administrative installation point (under \updates), adding 10 foreign languages to the network administrative
installation point, creating a custom .msp with the OCT (that goes into \updates too), editing the config.xml files, and then running setup.exe from that network administrative installation point. This works on 32-bit Windows XP clients and on 32- and 64-bit
Windows 7 clients.
For Office 2013 Pro Plus, I have built the network administrative installation point exactly the same way (original DVD files + languages + SP1 updates + config.xml updates), but the installation is failing with every type of client, all with
the same error message. The network administrative installation point is readable by the normal installing account, but I even get the same error when I login as me and initiate setup.exe manually, and I have all rights to this point.
Here's the critical point from a log file:
2014/03/11 11:53:49:691::[2372] DistributionPoint parsed. The distribution point is now set to: \\archive.ads.college.edu\archive\KBOXalt\Office2013
2014/03/11 11:53:49:691::[2372] COMPANYNAME specified in config.xml.
2014/03/11 11:53:49:691::[2372] USERNAME specified in config.xml.
2014/03/11 11:53:49:800::[2372] Setupexe Resiliency Mode is set to [PerformIfApplicable]; thus Resiliency is [disabled] for the [InstallExecutionMode]
2014/03/11 11:53:49:910::[2372] Searching for default versions of resource files under the folder [\\archive.ads.college.edu\archive\KBOXalt\Office2013].
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
ErrorCode: 0(0x0). Failed final attempt to load a setupexe resource file.
2014/03/11 11:53:50:019::[2372] Error: GetDirectories: search path \\archive.ads.college.edu\archive\KBOXalt\Office2013 does not exist
Type: 34::InvalidDirectory.
2014/03/11 11:53:50:019::[2372] WER element [SuppressModal] is set to value [true]
2014/03/11 11:53:50:019::[2372] WER element [P4] is set to value [InvalidDirectory]
2014/03/11 11:53:50:019::[2372] Catalyst execution finished: 03/11/2014 11:53:50. Return code: 30034. Exception caught: InvalidDirectory.
2014/03/11 11:53:50:019::[2372] PERF: TickCount=894821 Name=RunSetup Description=End function
I cannot find any references to this exact error anywhere on the Internet. Can anyone tell me what this means, and how I fix it?

As automated, the utility that runs setup.exe maps a drive letter to
\\archive.ads.college.edu\archive\KBOXalt using a kboxmap AD account, which has read access to the whole \KBOXalt tree. I used that same kboxmap AD account manually to simulate what the utility does, and hit the same problem. But here's what's
odd: right next to that
\\archive.ads.college.edu\archive\KBOXalt\Office2013 directory is an
\\archive.ads.college.edu\archive\KBOXalt\Office2010 directory, both created the same way, and the Office 2010 installation has always worked perfectly using the kboxmap AD account. I don't understand why Office 2013 is only working for an account with
read/write access, where Office 2010 worked fine for an account with only read access. Especially when the Office 2013 resource kit documentation clearly states that the account running the installation should only have read access, nothing more. (All this
KBOX stuff comes from the fact that our deployment environment is a Dell KACE KBOX 1000. However, that plays no part in the problem: ignoring the KBOX 1000, I can manually recreate the problem every time.)

Reader X Search doesn't differentiate cached search paths for reselection

I use the Search quite a bit (or did).
Specifically the "All PDF Documents in" option, where the paths of locations that have previously been browsed to are presented for reuse.
Previous Reader versions shortened long paths so as to display the last part of the pathname, which is normally sufficient to identify the path required.
X does not, so, with no Tooltip either, it is now impossible to differentiate paths with common starting paths longer than that displayed. Update FAIL.
Widening the whole search panel does not widen the field. Update FAIL.
AND when you start the search you STILL don't get to actually see what path is being search due to truncation. Again widening the panel does not widen the fields. Update FAIL.
And why can't we have the normal search term field in the toolbar for seraching the curent document? Although as it took me too long (I think) to even work out how to get any search button on the toolbar, maybe I mssed that. Update FAIL (x2).
And all my old search paths from the previous version have been binned. Update FAIL again.
So much for ease of use, do developers actually test sw "in use" rather than some neatly defined functionallity test scrpit - make the developers use the product is always a good way to fix this I find.
Honestly, if there wasn't enough resource available in Adobe to sort out this kind of trivial ease-of-use functionallity (that I found in just 5 mins use) then how can anyone have faith that the serious stuff has been properly tersted?
Not a good start for 5 mins use. And I see the downgrading doesn't work. Stuffed again.

Any ideas on how I get Quicktime to work that does not include disks?
Pacifist does not require an optical drive for use. Simply "drag 'n drop" the downloaded "QuickTime769_Leopard.pkg" installer file as downloaded from Apple or the OldApps.com site to the Pacifist Window, select the "QuickTime Player App under the "Applications" entry, and tell Pacifist to extract the app. Then it is simply a matter of dragging the app to your root "Applications" folder.

LabVIEW RTE Search Paths Capitaliza​tion [LV/TS]

Similar Messages

Maybe you are looking for

LabVIEW RTE Search Paths Capitalization [LV/TS]