Thank you!
This was a great help.
/Nimrod
In article <3913232c@newsgroups.ni.com>,
"Jean-Pierre Drolet" wrote:
> OK...
>
> Here some project management tips
> I'll assume you are on Windows
>
> First, the compiled VI code is already present in the VI file (or
LLB). What
> the builder do is to recover all VIs needed to execute, copy them in a
> single file, remove diagrams, front panels, change settings, etc. It
> recompiles the copies because all these changes, but the source VIs
are
> compiled and executable as is.
>
> To quickly see how your VIs execute in the Run-Time environment, you
can
> built an empty application (run the builder with *NO* files at all).
Call it
> LVRT.EXE and put it in the LabVIEW directory. When you execute LVRT,
it
> opens a dialog asking which VI to open. If you open and run your
application
> main VI, it should execute quite the same way as in the LabVIEW
environment
> since the VIs haven't been copied or modified. NO compilation, NO
build, you
> don't even need to close your VIs in LabVIEW to test the changes, just
> reopen the main VI with LVRT. Make a shortcut "c:\labview\lvrt.exe"
> "c:\myproject\mainvi.vi" to get things faster.
>
> The main idea is that the Run-Time executable does not require the
VIs to be
> built but only have to know where to locate them. Of course, problems
occur
> mainly when the application is really built and the directory
structure of
> the application is different than in the development environment.
>
> If a large part of the hierachy of the project is quite debugged, you
can
> make an LLB, using "Save with options" and save VI for distribution,
the
> same way LLB were prepared for the builders before version 5.1. When
> building the application, include this LLB as a *support* file. The
builder
> does not process support files at all and only copy them to the
application
> target directory. You have to be sure that the Run-Time application
will
> know how to locate these VIs, putting LLB path in the search paths
list or
> calling VIs within using the VI server. Saving VI for distribution is
a kind
> of "prebuild" and make a part of the work that the builder does not
need to
> redo every build.
>
> If you have more questions, feel free to repost.
>
> Jean-Pierre Drolet
>
> .
>
> a �crit dans le message :
> 8euvho$9lj$1@nnrp1.deja.com...
> > The thing why the 5 minutes bothers me is that I don't get the same
> > results in the stand-alone version as in the "LabView" environment.
> > This means I have to make a change, rebuild, and test the stand-
alone
> > to find a work-around. Even with a relatively short compile time it
> > will become a long time if the app is hard to debug.
> >
> > In Visual C++, for example, I'm able to make a precompiled header
so I
> > only have to compile what I have changed, but I'm missing this
feature
> > in LabView.
> >
> > /Nimrod
> >
> > In article <3912d113@newsgroups.ni.com>,
> > "Jean-Pierre Drolet" wrote:
> > > Yes there are some techniques but it will take more than 5
minutes to
> > > implement... After all one need to compile once in a while when
the
> > code is
> > > completed
> > >
> > > Maybe if you tell exactly why a 5 min. compilation time bothers
you,
> > we can
> > > find solutions.
> > >
> > > Do you compile frequently your code just to see how it runs
stand-
> > alone?
> > >
> > > Jean-Pierre Drolet
> > >
> > > a �crit dans le message :
> > > 8eugs9$o9l$1@nnrp1.deja.com...
> > > > Hi,
> > > >
> > > > I have an application with around 300 vis. Making an executable
with
> > > > application builder is somewhat tiresome (takes me around 5 min
to
> > > > build on an PIII 450). Is there anyway that I can precomile some
> > vis to
> > > > make the build faster?
> > > >
> > > > /Nimrod
> > > >
> > > > PS. I'm using LabView 5.1.1
> > > >
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Before you buy.
> > >
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
