comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Home » Public Forums » archive » Re: IDL 7.0 Projects
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend  		Return to the default flat view Create a new topic Submit Reply
Re: IDL 7.0 Projects [message #57229 is a reply to message #57225] Wed, 05 December 2007 16:53 Go to previous messageGo to previous message
Vince Hradil is currently offline  Vince Hradil
Messages: 574
Registered: December 1999
Senior Member
On Dec 5, 6:25 pm, Doug Edmundson <do...@ittvis.com> wrote:
> David Fanning wrote:
>> Folks,
>
>> I've been thinking about IDL projects quite a lot the past
>> couple of days, because I'm trying to write an article that
>> can explain this to someone like me. Obviously, I am having
>> a great deal of difficulty. :-(
>
>> Here is my latest idea. See what you think of it.
>
>> First, forget about "projects". (Well, you can't forget
>> about them entirely, since IDL 7 is going to force you
>> to use them.) Of course, I'm talking to the Windows crowd
>> here, but I think the same thing applies to most users.
>> Instead, think about "work". You probably already have
>> your IDL *.pro files organized in some kind of "work"
>> structure.
>
>> For example, I have a "david" directory, and inside of
>> that I have folders named "coyote", "activecontour",
>> "catalyst", "test", etc. My normal way of working is
>> to work in the "david" directory when I am just
>> fooling around, but if I have a specific task
>> or, heaven forbid, "project", I make a separate folder
>> to contain those programs.
>
>> What I wanted to do in IDL 7 was duplicate this way of
>> working, but if I create a "david" project, then I can
>> no longer create "coyote" and "catalyst" projects, because
>> these live in the "david" folder, and projects (as far as
>> I can tell) cannot be nested like this.
>
>> So here is what I've created, that is sort of working for
>> me. I've renamed the Default project "Sandbox" and I let that
>> go into the IDLWorkshop folder. This is now where I do my
>> fooling around. I've renamed my "david" folder "idlwork" and
>> with the exception of moving all the *.pro files out of there
>> and over into my "sandbox" directory, I've left the directory
>> structure alone.
>
>> So, when I fire the IDL Workspace up, I am looking at the
>> project Sandbox. Now, if someone sends me an e-mail saying
>> that FSC_COLOR is a piece of crap, and here is how you can
>> fix it, I simply create a *new* project named "Coyote" and
>> I create if from the "coyote" directory in "idlwork". I can
>> make changes to coyote programs there. When I am finished with
>> it, I can just delete the Coyote project (taking care, God knows,
>> NOT to delete the contents of the directory!) and I am back
>> to my Sandbox. I can do this with any "project" I care to work
>> with.
>
>> This has several advantages. It keeps my Project Explorer
>> from overflowing with projects I'm not the least bit interested
>> in at the moment. It means the Workshop doesn't "Analyze Code"
>> for an hour and a half every morning. And it sort of makes
>> sense to me.
>
>> Of course, if I forget to delete the project before I exit
>> the IDL Workspace, it just starts up again the next morning
>> with the same configuration I left it in.
>
>> And, naturally, I do ALL the path manipulation manually
>> because I don't trust ANY software that thinks its smarter
>> than I am. This means my programs can find coyote, and catalyst,
>> and other procedures when they need them, even if they are NOT
>> in the project currently.
>
>> Does this seem like a workable configuration to anyone?
>
>> Cheers,
>
>> David
>
> David,
>
> This sounds good to me, especially if you have routine name "collisions"
> (due to multiple versions of the same library?) and hence need to pay
> particular attention to path order. We have similar users here at ITT
> VIS who do that.
>
> The only thing I'd add for anyone else who's reading this is that if
> they don't care about the order of routines on their path, they might
> want to go ahead and trust, yes by golly, trust the IDL Workbench to
> manage their path. :-) That way one doesn't have to constantly create
> and destroy projects. When a project is closed, it'll be automatically
> removed from the path and not parsed (no "analyzing code"). To close a
> project, go to the "Project Explorer" view, right-click on a project and
> choose "Close Project". Opening a managed project will immediately
> re-add it to the path.
>
> Cheers,
> Doug

That seems reasonable to me, but I think David is also concerned about
seeing all those projects in the project browser.

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: problem with vector plots
Next Topic: Re: IDL7.0 Help System Tabs???

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Oct 10 20:16:20 PDT 2025

Total time taken to generate the page: 0.55911 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.7.
Copyright ©2001-2013 FUDforum Bulletin Board Software