Yeah, it makes a lot of sense. Local variables are definitely easier to control than global ones. Thanks again for all help.<div><br></div><div>Ming<br><br><div class="gmail_quote">On Fri, Oct 24, 2008 at 12:42 PM, David Cole <span dir="ltr">&lt;<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="Ih2E3d">On Fri, Oct 24, 2008 at 1:00 PM, Ming Chao <span dir="ltr">&lt;<a href="mailto:mingchao2005@gmail.com" target="_blank">mingchao2005@gmail.com</a>&gt;</span> wrote:<br>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>It appears you recommend to leave the env variable untouched, but would rather copy dlls into the .exe directory. But the problems is that for every project using vtk I have to copy them. Isn&#39;t that awkward? What is the disadvantage of setting environment variables?</div>


<div></div></blockquote><div><br></div></div><div>How long did you spend thinking there was a problem when there wasn&#39;t one? Wasted time is the primary disadvantage of setting environment variables for finding DLLs.</div>
<div>
<br></div><div>If you do want to set it via environment variables, at least set it locally... (In a customized command prompt or just within your Visual Studio solution.) That way, you won&#39;t get confused again two years from now when you&#39;ve built another new build of VTK and are trying to get another application running.</div>

<div><br></div><div>The other secondary disadvantage of using environment variables to select a build of VTK dlls is when you have multiple builds of VTK that you are switching between. Whenever you switch an environment variable you have to kill all the processes that have a copy of the old value in them and then restart them. To me, it just seems easier to say &quot;I will always get VTK dlls from the same directory as my exe&quot; and *never* think about the PATH env var again.</div>

<div><br></div><div>Hopefully, this makes some sense...</div><div>David</div><div><br></div></div>
</blockquote></div><br></div>