Skip to main content
Bed30321077z973
Inspiring
February 8, 2024
Answered

Problem with "Display"(or Pointers location) of imported items if you have more than 1 project open.

  • February 8, 2024
  • 2 replies
  • 605 views

Hello,

I unfortunately don't have a step by step ready to use process to reproduce, but this one is pretty easy to reproduce, I can give a brief description and leave out there, it that can help one day,

 

if you have 2 projects open for example, then have 2 variables containing each a Project item, then perform an import files on them,

All the filles will DISPLAY only inside the currently viewed project by the user.

So if you are in project 2 (currently viewed by user), and you perform the insert files for project1 with its variable, all the items show up on project2, if you perform the insert for both projects, ALL items from both projects ONLY SHOW UP on the currently viewed project.

 

So the problem is next time you open the projects that was not viewed (project 1 here), it will have NO ITEM from the ones you performed the import on. (meanining that proj1-> import files function did not fail, YET there is no item inside proj1)

 

If you drag an item from project 2 (the one that received all the items despite telling the api to put them in different proejtcs) to project 1 (the one that got no item), then it will add that item to its list.

 

So another problem is that the "app.project.rootItem.children" becomes unusable, and unreliable. You can only trust the list of items you get from the currently viewed project. Because any time you add a new item to another (non viewed currently by the user) project, it will be added and disturb the list, whereas the list stays fix if you have imported the files once and you are working with one single project.

 

So next time you want to use a reliable list from "app.project.rootItem.children", for a specific project, you would always need to go check the "other" project that "received" all the items you imported...

 

Maybe that's a hardcoded choice, letting users import items on projects that are currently viewing, and that made it that there was oversight on use cases when the user is using api and want to import ONLY to a project, that is not currently viewed (despite it being open of course).

 

This topic has been closed for replies.
Correct answer Bruce Bullis

ExtendScript can already shift to another active project or sequence; 'app.project' and 'app.project.activeSequence' are read/write. 


2 replies

Bruce Bullis
Community Manager
Community Manager
February 8, 2024

The import behavior you've described is 100% correct.

>If you drag an item from project 2 (the one that received all the items despite telling the api to put them in different proejtcs)


There is no API that allows for simultaneous import into multiple projects. 


app.project.importFiles() is specific to the project object, from within which it's being called. 

>So another problem is that the "app.project.rootItem.children" becomes unusable, and unreliable. You can only trust the list of items you get from the currently viewed project

 

That is also 100% correct behavior. app.projects = Array of open projects. app.project = the currently active project. 

Bed30321077z973
Inspiring
February 8, 2024

Interesting.

That's why project1.importFiles() and project2.importFiles(), behaved the same way for me.

One alternative, to keep things working as they are and give more possibility would be a function to "shift" to another "active" project/sequence?

That would be interesting.

Something like project1.makeActive(SequenceTobeActivated); //return false if the sequence does not exist or if there is a problme etc.

(Maybe in the future with new APIs if it does not exist already)

Bruce Bullis
Community Manager
Bruce BullisCommunity ManagerCorrect answer
Community Manager
February 8, 2024

ExtendScript can already shift to another active project or sequence; 'app.project' and 'app.project.activeSequence' are read/write. 


Bed30321077z973
Inspiring
February 8, 2024

Actually being able to use items from project2 inside project1 should be kept in one condition, because it facilitates the code (no need to find children of every project separalty),

The condition: using items from project 2 inside project 1 resulting in creating the pointer of that item inside the project that did not have the item priorly should not increase time of processing. (This should be monitored with more experiments and see which is best, or maybe offer both options (2 differents import files function types, one that actualy imports to the right project (missing) and the other one that only import to the currently viewed project (currently in use).