Run time shared lib

Hi,
We have several projects referencing same lib which compiled into a runtime shared swf .
The swfs(projects) can be loaded in several(independent) iframes in the web page.
Is it possible for the projects to use the first runtime shared lib swf
that has been loaded on the client side(It’s supposed to be a singleton)
and communicate (pass compmonents).
Or set the loaded swfs to the same sandbox the “main” swf project got into?
Thanks,

I'm pretty sure separate iframes are separate player instances so no
sharing.

Similar Messages

Preview SWF which contains a Run Time Shared Library

All of our assets share fonts using a run time shared library (RSL) so that we dont need to embedd the fonts in each and every seperate swf. The swf looks for a sharedFonts.swf file one level/directory up from where it is currently at. Inside the assets' RSL the url is ../sharedFonts.swf.
So with a program like Adobe Bridge I just need to find out where Bridge is previewing the file from and then one directory up from that I need to place in the sharedFonts.swf. The place that I am viewing it from is already setup that way and works correctly if I simply open the swf without using some kind of program. So my guess is that Bridge takes the swf and places it somewhere within itself and then previews it or there is simply a bug with Bridge since currently it is just crashing.
I have some logs using windows event viewer and that shows me that the module that is failing is AdobeSWFL.dll which I am guessing is library to preview items.
Faulting application path: C:\Program Files (x86)\Adobe\Adobe Bridge CS5\Bridge.exe
Faulting module path: C:\Program Files (x86)\Common Files\Adobe\APE\3.1\AdobeSWFL.dll
Has anyone ran into something like this before? Any ideas on what to do here?
Thank you!

I'm having the same problem. A coworker showed me how he uses Bridge to navigate all of his Photoshop and Illustrator files. As a Flash artist, I tried using Bridge to preview SWFs, and discovered the auto-crash feature.
Bridge crashes every time I click on a SWF that uses a runtime shared library. Frustrating!
Were it not for this bug, our studio's Flash artists would likely integrate Bridge into our pipeline. A fix, or directions on fixing the issue would be greatly appreciated.

Run time shared library

Hi.
I use the same library "food" (which contains apple.swf, orange.swf etc... ) for ten different games.
I DON'T check the run time shared library box on export.
The ten games import food.swf to use it's assets.
I thought that on downloading food.swf once then it was cached so it would always be local ie: why would it be advantageous to have used run time shared library.
Cheers

Are you talking about symbol RSL in Flash IDE?
If yes - symbol RSLs have nothing to do with application RSL. Symbol RSLs are authoring environment RSLs - they are asasets that shared between FLAs - not SWFs.
RSLs from SWFs perspective are different story.
Say, you have class Food. Also you have Classes Orange, Apple, Walnut that extend class Food. And each of these sublcasses have their own SWF orange.swf, apple.swf, walnut.swf.
You can compile these extended swf in regular way when they don't share their super class Food. In this case a copy of Food class will be in all three swfs. So, all three are as much heavier as Flood class is.
But if you use RSL - you don't compile Food in any of them. You compile Food into main SWF that loads these three extended swfs so that these swfs use a single copy that resides in the main swf. The three subclasses are lighter because they don't have Food class in the swfs.
In other words, orange, apple, and walnut swfs are useless on their own unless they are loaded into main application.
RSL approach is not only about loading efficiencies but also about deployment and maintainability.
Let's assume you discover a bug in Food class or make some changes that are not pertaining to these three subclasses. If you don't use RSL - you will need to recompile all three. With RSL you just need to recompile main swf only.

Design issue with sharing LV2 style global between run-time executables

Hi,
Just when I though that I had everything figured out, I ran into this design issue.
The application that I wrote is pretty much a client-server application where the server publishes data and the client subscribes data using data sockets. Once the client gets all the data in the mainClient.vi program, I use LV2 style (using shift registers) to make the data global to all the other sub-vi’s. So the LV2 is in initialize mode in the mainClient.vi program and then in the sub-vi’s the LV2 is in read mode. Also, I had built the run time menu for each sub-vi that when an item is selected from the menu, I would use the get menu selection to get the item tag which will be the file nam
e of the sub-vi and open the selected sub-vi using vi server. This all worked great on my workstation where I have labVIEW 7.0 Express installed. But the final goal is to make exe’s for each of these sub-vi’s and install runtime on the PC’s that do not have labVIEW installed. Of course when I did that only the mainClient.exe program was getting the updated data from the server but the sub-vi’s were not getting the data from the mainClient.exe. I did realize that the reason for this is due to the fact that I had compiled all the sub-vi’s separately and so the LV2 vi is now local to each executable (i.e. all executables have their own memory location). Also, the run-time menu did not work because now I am trying to open an executable using vi server properties.
To summarize, is there a way to share LV2 style global's between executables without compiling all of the sub-vi’s at one time? I tried using data-sockets (local-host) instead of LV2 st
yle gloabls to communicate between the sub-vi’s but I ran into performance issues due to the large volume of data.
I would really appreciate it if anyone can suggest a solution/alternative to this problem.
Thanks
Nish

> 1) How would I create a wrap-around for the LV2.vi which is
> initialized in my mainClient.vi and then how would I use vi server in
> my sub-vi to refer to that LV2.vi?
> You mentioned that each sub-vi when opened will first connect to the
> LV2.vi via via-server and will keep the connection in the shift
> register of that sub-vi. Does this mean that the sub-vi is accessing
> (pass-by-reference) the shared memory of the mainClient.vi? If this
> is what you meant I think that this might work for my application.
>
If the LV2 global is loaded statically into your mainClient.vi, then any
other application can connect to the exe and get a reference to the VI
using the VI name. This gives you a VI reference you can use to call
the VI. Ye
s, the values will be copied between applications. That is
why you need to add access operations to the global that returns just
the info needed. If you need the average, do that in the global. If
you need the array size, do that in the global. Returning the entire
array shouldn't be a common operation on the LV2 style global anyway.
> 2) Just to elaborate on my application, the data is
> transferred via DataSockets from the mainServer.vi on another PC to
> the client’s PC where the mainClient.vi program subscribes the
> data (i.e. 5 arrays of double type and each arrays has about 50,000
> elements). The sub-vi’s will have to access these arrays
> located on the mainClient.vi every scan. Is there any limitation on
> referencing the mainClient.vi data via vi-server from each sub-vi?
Your app does need to watch both the amount of data being passed across
the network, and the amount being shared between the apps. You might
want to consider puttin
g the VIs back into the main app. What is the
reason you are breaking them apart for?
Greg McKaskle

LabVIEW 8.0 Run-Time engine & shared variables

Has LabVIEW 8.0 Run-Time Engine the shared variable's support, I wonder?
The thing is that .exe with globals/locals runs alright, but beeing replaced with shared variables it refuses to run.
What's wrong? May be need in library(s) absend?
Thanks.

You can use the Shared Variable in the Run-Time Engine (you do not need DSC).
Can you be more specific about what happens when it refuses to run? Are you seeing an error message?
If you are using Network-Published shared variables, they need to be deployed before you run the application. You can either deploy them manually with the project, or your application can programmatically deploy them. You can find some more information about this in the LabVIEW Help under "Shared Variables and Stand-Alone Applications or Shared Libraries" (follow this link and scroll down to the bottom):
http://zone.ni.com/reference/en-XX/help/371361A-01/lvconcepts/project_variables/
-Chris

Custom Run-Time Menu Not Found in User.lib

Our Instrument Run-Time Menus are getting lost.
This is because we have some computers that are 32 bit and the code is located at
C:\Program Files\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
Other computers are 64 bit and the code is located at
C:\Program Files (x86)\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
The directories are thus slightly different because of how Windows treats the location of 32bit LabVIEW running on a 64 bit machine.
Does anybody have an easy work around?

I'm confused by "lost". Do you mean when you build the path to your custom menu within your vi or are running some executable? Is this code you have written? If so, then maybe a simple check when initializing the paths might work.
If it is as simple as just having to decide between those two directories, then I would just check to see if the win64 bit directory exist, using "file directory info" vi. If it doesn't' exist you should get an error, then check to see if the other path exists, it should hopefully, and use that.
Not sure if this is what you need.

Missing vi.lib files in Run-Time LabVIEW 2012

Hi
I've got a problem executing VI's under RT in LabVIEW 2012.
Our system consist of multiple independent modules which are opened and run from a Manager VI. VI paths to the modules are read from an .ini file by the Manager VI.
We have build a single executable (RT Launcher) that takes the path of the Manager VI as argument (Attachment : RT Launcher.png).
The RT Launcher is placed in the ..\National Instruments\LabVIEW 2012 folder as the LabVIEW.exe.
The RT Launcher is called from the CLI.
"C:\Program Files\National Instruments\LabVIEW 2012\RT Launcher.exe" "C:\Workspace\Labview\Manager.vi"
This will run the Manager.vi in the RunTime Environment and the Manager.vi will open the .ini file and execute the Module VI's one by one.
By calling the RT Launcher.exe from the same folder as the LabVIEW.exe, the search paths should be the same.
The system worked fine in LabVIEW 2010.
The Manager VI is opened with broken arrow and the errors indicate that vi.lib sub VIs are missing (attachment : Manager VI errors.png)
I know there are issues regarding object cache and separated compiled code from LV2010 -> LV2011 -> LV2012, but simply can't figure out how to come around this problem.
Can anyone explain the difference and how to solve the problem ?
Thanks
Regards Kahr
Certified LabVIEW Architect
CIM A/S
Solved!
Go to Solution.
Attachments:
RT Launcher.png ‏68 KB
Manager VI errors.png ‏35 KB

Hi Kahr.
It sounds like you are making some dynamic calls to VI's, eg. by using 'Open VI Reference'. My answer is based on that assumption.
You are absolutely right. In LabVIEW2010 we introduced a function called 'Separating Compiled Code from VI'. At that time none of the VIs from VI.lib had that option enabled. In LabVIEW2011, many VI's in VI.lib have, by default, a separation of compiled code and VI. This option cannot be changed (greyed out) for these VI's as well. This feature was introduced in order to simplify source code control.
Separating Compiled Code from VIs and Other File Types
The drawback is, that it is no longer possible to call VI's dynamically from an application (executable), when this option in enabled, since the compiled code no longer exists. The method of calling a VI dynamically from an application has been (and still is) used to make some kind of a plug-and-play architecture, meaning we have one EXE-file that only gets distributed once and a set of subVI's that gets redistributed according to new versions (new features added to the subVI), meaning we can make changes in the subVI without having to redistribute the EXE-file.
With the release of LabVIEW2011 and LabVIEW2012 we can no longer distribute VI's that uses functions from vi.lib, this also include DAQmx calls even though the DAQmx driver is installed.
The simple explaining is, that it has never been intended that VI's got distributed. Eg, when Microsoft is making a new software update for Windows7, they don't send out the source code to all the users.
The solution is therefore to wrap up the source code into 'something' that includes all the compiled files. In LabVIEW we do that in a couple of different ways.
1) Include the VI's in the EXE-file.
When building the application, we have the option to include files, that normally is not included in builds. If we call a SubVI dynamically this will not automatically be included! However, the drawback of this method is, that if you need to change something in one of your SubVI's, you would need to build and distribute the entire application. Thereby, we are not making use of the plug-and-play architecture that we originally wanted. However, this method will fix the error.
Error 1003 When Using VI Server in a LabVIEW Application
2) Now, if we still want the plug-and-play architecture in LabVIEW2011+2012 (and this will properly be the same for the next many released of LabVIEW), this can still easily be achieved by making a Source Distribution. When we make a Source Distribution, we can include the VI's from VI.lib and thereby the compiled code. When using this method, two important things should be remembered:
a) Make the files into a LLB file. This will pack all the VI's into one single file, that is easy to distribute.
Go to Destinations ==> Destination Type ==> LLB.
b) Make sure not to 'Exclude files from vi.lib', as this method will then simply not work.
Go to Additional Exclusions ==> Remove checker mark in 'Exclude files from vi.lib'.
How Can I Call a VI Dynamically from an Executable Without Including Those VIs in the Build?
I have made a small example to demonstrate this:
Example: Using vi.lib
This example has two mainVIs and two EXE-applications. Build the two EXE-files, but do NOT build the source distribution yet.
1) Main(IncludeSubInExE). This version has included the subVI in the build distribution for the EXE-file. When running this EXE everything works fine, even when calling the subVI dynamically. However, since the subVI is build into the exe, we would have to redistribute the exe for every new version of the subVI. This breaks the hole idea.
2) Main. The subVI is no longer included in the build. When running and trying to call the subVI, you will get this error (on both your developer and run-time machine):
Now, build the Source Distribution and run this EXE again. The exe is running perfectly with no errors.
I hope this answers your question.
Best Regards
Alex E. Petersen
Certified LabVIEW Developer (CLD)
Application Engineer
Image House PantoInspect
Attachments:
Using vi.lib.zip ‏83 KB

Which Shared Libs are required to run ADF

When we setup a new stand alone server, the shared libs are not targeted to that server.
What Shared libs need to be targeted to a managed server for ADF applicaitons?
Running WebLogic 10.3.1
JDeveloper 11.1.1.1.0
thanks,
Rodger...

You should be more specific with your environment.
My understanding of a standalone WLS is this: a WLS installed with the plain WLS installer, no JDeveloper involved.
If you installed JDeveloper which includes WLS and want to run a new WLS domain from this installation then you only need to run the Configuration Wizard to create a new domain. During this run you should include (set the check box) the Oracle JRF (something like Java Runtime Framework) option. Then your new domain is able to run the ADF application. You should be aware that you need to package it as an EAR file otherwise the shared libraries are not called. (Hint: See http://blogs.oracle.com/olaf/2008/10/nice_jdev_11g_feature_ear_pack.html)
--olaf

Can labview export shared libaray use in C++ without run-time engine?

Hi, everyone
Now, I write a VI for a algorithm and export it as a dll. I use the dll in my C++ apps. It is good. But I want to know how my apps can run without labview run-time engine or I must install run-time engine?

you can install run time engine or include dll which will be used by your application.

Can't load shared lib lib... with SuSE 6.2

Hi,
i have a Problem with sqlplus and the shared librarys, if I start
sqlplus everytime it complains about the shared libs.
Is it wron to set the LD_LIBRARY_PATH to $ORACLE_HOME/lib ???
Do I need an updated JRE ??? GLIBC ???
Thank you for the help !!
Michael
null

Hi,
which libs are wrong? There are several libs with 0 byte size!!!
That is a known bug, and when ld reads them it of course
complains ;-)
For one of the 0 byte libs there is a patch (look at earlier
postings around 2 weeks ago)
Marcus
PS: it seems anyhow this release is not ready for prime time. If
you want to play around with Oracle, take 8.0.5.1, that works
really good.
Christian Schroeder (guest) wrote:
: Marcus (guest) wrote:
: Hi,
: : try adding $ORACLE_HOME/lib path to /etc/ld.so.conf
: : then, run ldconfig -v as root, this may solve your problem
: I did this, but the ldconf complained that he couldn't read
: the headers of the libraries, especially the
jni-shared-library.
: I was wondering if I use the wrong ldd version? It says it is
: 2.1.2! Is this enough?
: Thanks you for you help,
: cu Christian
null

Reading the stabs.index section of Shared Libs

Hi there.
In order to produce developer-friendly stack-traces, I'd like to read the stabs info from our own projects to map the stack offsets to actual code lines.
So far, I've sucessfully written the reader to handle the lazy stabs inside our object files, and I get the relevant mapping (using N_SLINE, N_FUN and N_SO). But I don't have much luck trying to find these actual .o files from the shared libs (using the N_OBJ stabs contained in the ".stab.index" section of the shared library).
It looks like Sun Studio 11 (maybe earlier versions too) writes the stabs in an odd format in our shared-lib, so that only the beginning of the section is correct (only the one covered by the first N_UNDF) . After a while, the offset to the strings get wrong, even using the "correct" algorithm of adding the offset contained in the previous N_UNDF stab.
So, I can read all the information correctly, except for the actual strings for each stab. I had a look at some other stab-readers (gdb and valgrind), and they suffer from the same issue as my code. Actually, even an objdump -G mySharedlib.so produces the same incorrect output. But obviously, there is a way of find the correct string pointers, as the dumpstabs tool works perfectly.
Does anyone have any pointer to the actual trick needed to read the stabs ? I've already read "The stabs debug format", and the document provided by Sun (and linked from Chris Quenelle's blog): http://developers.sun.com/tools/cc/documentation/ss10_docs/stabs.pdf
Cheers

First of all, I should start by saying that in Sun Studio 12 all the
Sun compilers will generate dwarf as the default debugging format,
and you should be able to use the GNU binutils "addr2line" utility
to query the line number information. The dwarf information produced
by Sun Studio 11 (C compiler, for example) has a glitch that makes
it incompatible with addr2line, but the glitch is fixed in our development
release, and Sun Studio 12 (when it comes out) will work with addr2line.
On Solaris, the addr2line utility is available as "gaddr2line".
But I realize that stabs processing is also useful for the time being.
Here are my ideas for what might be going wrong.
If there are stabs that resulted from COMDAT functions then there are
special formatting issues. The C++ compiler uses COMDAT to implement
templates. The stabs.pdf document describes how COMDAT affects
stabs. Search for the word COMDAT in the document. Because comdat
ELF sections are merged at link-time, it might also help to run
elfdump and dumpstabs on some of the .o files that are being put into
your library as a way of understanding what's going on.
Specifically, the string table offsets need special processing around
any index stabs that result from comdat sections, so I suspect
that's what's causing problems.

Error involving Report Generation Toolkit and Labview Run Time Engine

Developed an application using LabVIEW 6.1 and LabVIEW Report Generation Toolkit for Microsoft Office 1.0.1. From there, tried to build a shared application for use with the LabVIEW Run Time Engine. The Run Time version functions properly until "New Report.vi" is called and then an error is generated, code 7, calling out "Open VI Reference in New Report.vi" could not be found. When building the application, I did include the "NI Reports Support" in the advanced installer options. The machine used for original development and application build is running Windows XP Pro and Office XP. Any suggestions??

I am having the exact same problem but with LV 6.1 and M/S WORD 2000. It appears that the "New Report.vi" is trying to open "C:\APP.DIR\Word_Open.vi" and "C:\APP.Dir\Word_Open_Document.vi" by reference. The "OFFICE 2000.TXT" says that "_exclsub.llb and _wordsub.llb must be added as support files when building an application or a dynamic link library with the application builder." I added them as Support Files and I copied them to the "C:\TESTER\" where the TESTER.EXE is and I still get ERROR 7 in "NEW REPORT.VI" at VI OPEN REFERENCE.
Do I need to make a "C:\TESTER\DATA\" sub-dir and put the support files there?
I am building on MY COMPUTER on F: Drive on a network and transporting files to the real Tester.
I displayed my App.Property of APP.DI
R at start up and it is C:\TESTER\ ! How would my application know that "Word_Open.vi" and "Word_Open_Document.vi" are actually inside the _wordsub.llb?
Any ideas ?
Greg Klocek

Problem with classloader (for shared-lib's) on oc4j 10.0.3.4 under jdk 1.5

I have a project that runs great on oc4j 10.0.3.4 under jdk 1.6. (everything worked great)
I recently tried to run it under jdk 1.5 and i've run into a little problem with the shared-lib's:
The classloader's debug file reports the following: (i have translated some of it)
Class error: oracle.classloader.util.AnnotatedNoClassDefFoundError:
     Missing class: javax.xml.bind.JAXBContext
Dependant class: nl.comp.util.XmlUtil
     Classloader: comp:0.1
     Code-source: /C:/programs/oc4j/j2ee/home/shared-lib/comp/0.1/comp.jar
     Configuration: <code-source> in /c:/programs/oc4j/j2ee/home/config/server.xml
The missing class is available from the following location:
     1. Code-source: /C:/programs/oc4j/lib/xml.jar (from <code-source> (ignore manifest Class-Path) in META-INF/boot.xml in C:\programs\oc4j\j2ee\home\oc4j.jar)
This code-source is available from classloader oracle.xml:10.1.0_2
     2. Code-source: /C:/programs/oc4j/j2ee/home/shared-lib/jaxb/2.1.6/jaxb-api.jar (from <code-source> in /c:/programs/oc4j/j2ee/home/config/server.xml)
This code-source is available from classloader jaxb:2.1.6.
So the classloader knows where to find the necessary lib, but it isn't loading it? If i run the exact same code (with same descriptors and everything) under jdk 1.6, it works, under 1.5 i get the above error.
What is different on the class loader level between the two jdk versions that might affect the program in such a way?
Need i update a descriptor or do something else?

Jack,
Not a definitive answer for you (sorry), just a few suggestions (that I assume you are unaware of).
1. Try unsetting your "ClassPath" variable. Open a "command" window and type the following:
set ClassPath=2. Launch OC4J from the directory where the "oc4j.jar" file is located, for example:
D:
cd oc4j\j2ee\home
java -jar oc4j.jar3. I'm just guessing, but if your drive "D:" is a mapped, network drive, this may be causing the problem. Perhaps try installing OC4J on a local drive?
Hope this helps.
Good Luck,
Avi.

Unable to locate the LabVIEW Run-Time engine

Using LabVIEW 2011, I have built an executable and installer including the LabVIEW Run-Time engine. I built the app on a 32-bit system. I'm deploying it to a Windows7 64-bit system. When I ran the installer, rebooted, then tried to run the app, I got an error messsage stating "Unable to locate LabVIEW Run-Time Engine", stating that the LVRTE 2011 was needed to run the app, and asking if I want to download from NI. I have tried downloading the RTE and re-installing it, but when I try, I get an error message from the installer stating that there is a newer version of the RTE already installed, and the installer exits! I have tried un-installing the application, but have had no luck removing the RTE. Now I'm stuck. The re-installed executable application says it can't find the RTE, and the RTE installer says there's a later version already installed!
I can't go forward or backwards!
Prior to running the installer for this app, I had a working LVRTE for 2011, and was running some other executable LabVIEW programs on the target box. However, since this new application had additional components not included in the original install of the RTE, I built the new installer which included the additional components. Once I ran that installer, my problems began.
In my frustration, I've tried downloading from NI both the 32 and 64-bit versions of the RTE, and installing them. I realize that the app was built on a 32-bit system, so the 32-bit RTE SHOULD have run it fine, but didn't.
At this point I have removed the 64-bit RTE using the NIUninstaller. I believe I need to completely remove all 32-bit RTE components and start over, but I have not been able to. The 32-bit RTE does not show up in any un-install utilities I've found.
What could be causing this problem, and how do I get past it??
Thank you.

One thing I did discover in my struggles is that the RunTime engine on the target box needs to be based on the environment of the development box. So if you built the app on a 32-bit machine, you would need to install the 32-bit RTE, even on your 64-bit target box.
The RTE Uninstaller might not show up in the Windows Add/Remove Programs utility. In my case the 64-bit RTE uninstaller showed up, but the 32-bit did not. The NiUninstaller (C:\Program Files\National Instruments\Shared\NIUninstaller) did list both RTEs for uninstalling, but still didn't get me past the problem.
I was finally only able to get past the problem by doing a system restore to a point in time prior to my changing of the RTE.
Good luck.
Dan

System Error 998 While loading the Labview Run-Time Engine

Hello.
I have a DLL made with LV 7.1 I run the dll using a C compiler and works great in WINXP, but cannot run in Win2K. Error is:
"System error 998 while loading the Labview Run-Time Engin(c:\program
files\National Instruments\Shared\Labview Run-Time\7.1\\lvrt.dll)
READVOLTAGE requires a version 7.1 (or compatible) Labview Runtime
Engine. Please contact the vendor of READVOLTAGE to correct this
problem"
READVOLTAGE is my function inside the dll. The runtime is already
installed. I tried it in another WINXP running machine and works fine.

This is actually a Microsoft bug with statically loaded DLLs. There are a couple of workarounds for it, and I have included two links below to posts that address this issue:
Not found error message from LabVIEW runtime when called from VC++ with statically linked MFC
I get error 998 when calling a LabVIEW buildt DLL from MSVC++
Kind Regards,
E. Sulzer
Applications Engineer
National Instruments

Run time shared lib

Similar Messages

Maybe you are looking for