I'm having a similar problem building a SAV file in IDL 7.0... I have a widget application that runs just fine when created using 6.4, but when I use 7.0, several core functions/procedures (i.e., STRSPLIT() and XMANAGER) aren't included in the SAV file unless I add links to the source files in my project.

Solution to problem 2. IDL_bridge path is by default set to the working directory. The working directory can be changed with the "cd" procedure. I'm not even sure what the default is when idl_runtime starts up, so setting it to the directory where the save file was loaded from seems a bit more challenging. Solution to problem 3. Create a .sav file of the desired library code using idl 6.4 (for some reason IDL 7 does not properly resolve_all). Put the save file into a known directory, and then send the command restore c:\known_directory\somefile.sav to the idl_bridge process. All routines are now available for use.

Peter: Re: 2st Problem - Missing Procedures 'Project->Build Project' is the right way to go. However, I just last night during my own application development discovered and logged in IDL's bug-tracking system a few bugs and feature requests on the subject ot its behavior. These are the ones that might be relevant to your latest attempts: 1) Some IDL Project Properties settings are inconsistent with Projects that have linked-in Project References. The 'Execute .RESET_SESSION ...' setting, for example, will perform .RESETs in the middle of a multi-Project build, if it is set 'On'. Do you have Project References in your Project? [I would, in all cases, leave the 'Execute .RESET_SESSION ...' option off until I found the source of a missing routine problem.] 2) Custom build commands are sometimes (perhaps always) incompatible with the setting 'Build in a separate IDL session'. Did you try buildig in both your current session and "in a separate session" with the same result? 3) The Workbench Console view is not showing as thorough output during compilation as the old IDL Output Log. Thus, where the old IDL output log would have a 'Compiled routine ...' entry for every routine within every compiled file, the new Workbench console will only report the compilation of routines that share the same name as the file. Thus, one's session and one's '.sav' file may contain routines that the programmer is not aware were compiled. (I do not think that is your case with GET_SCREEN_SIZE, however.) Re: 2nd Problem - I should point out that IDL Documentation makes this remark about the IDL_IDLBridge: "It is important to realize that IDL_IDLBridge child processes do not inherit any state information from the parent IDL process. This means that the child process will not have access to data, compiled routines, system variables, or even the current working directory of the parent process." I do not know whether that knowledge by itself will solve your problem. However, commands like the following will help you debug, I think: IDL> o = obj_new('IDL_IDLBridge') IDL> o->Execute, 'pathInfo = !path' IDL> print, o->GetVar('pathInfo') ; The above should show whatever is set in your login's regular static path preferences IDL> o->Execute, "RESOLVE_ROUTINE, 'GET_SCREEN_SIZE', " + $ IDL> "/COMPILE_FULL_FILE, /EITHER" IDL> o->Execute, "HELP, OUTPUT=helpOutput" IDL> print, o->GetVar('helpOutput') ; This approach would demonstrate whether GET_SCREEN_SIZE got compiled ; into your bridge IDL process Re: 3rd Problem - If nothing else o->Execute, " RESTORE, '/path/to/myIDLlib.sav' " should work. Have you tried that? James Jones ITT Technical Support