g_app_o.unpackageUCF(zipFile_e, destinationFolder_d) not seeing destinationFolder

InDesign
1

I’m using the following:

return g_app_o.unpackageUCF(zipFile_e, destinationFolder_d);

In my case, g_app_o is what most people would have as app. But the issue is that when running that, Adobe’s UDT reports an error:

Invalid value for parameter ‘destinationFolder’ of method ‘unpackageUCF’. Expected File, but received nothing.

The way I read that…

  1. The method is being found
  2. It’s happy enough with the passed zip file
  3. It’s unhappy with the destination folder.
  4. It says that it’s expecting a File?

Questions:

Does that method work in UXP?

Does it want a File for the destinationFolder? I’m not using this to generate an .indd from an .idml. I’m trying to decompress a .zip file that was compressed in ExtendScript using:

app.packageUCF(temp_d, zip_f, mimeMediaType_s);

Jon

2

It worked when I tried passing a simple string.

const { app } = require('indesign') ;
const zipFile_e = '/Users/username/Desktop/ucf/ucf.zip' ;
const destinationFolder_d = '/Users/username/Desktop/ucf' ;
app.unpackageUCF(zipFile_e, destinationFolder_d) ;

Perhaps the value of destinationFolder_d was undefined when it reached that method, or a value of a different type than expected was set.

1 Like
3

Thanks!

I’ll try passing it paths and report back when I’m working next week.

I was sending file/folder entries.

1 Like
4

Indeed, destinationFolder needs a path (string) rather than a folder entry.

Thanks @sttk3!

jsw

1 Like
5

UXP is based on NodeJS paradigms, so pretty much everything that in ExtendScript required a File or Folder object to be passed will now use a simple string path. Some ‘exceptions’ to the rules are when the application returns a Promise to a file or folder (like app.activeDocument.fullName). If you await that, the end result is still a string path representation.
Hope this helps clarify things a bit.

6

Thanks @vamitul! That is useful.

I would say that my greatest pain points in transitioning from ExtendScript to UXP have involved file manipulation. Perhaps I was too reliant on the easy File and Folder objects in ExtendScript?

Jon

7

Now, in all fairness, I think using plain strings has to be easier than specialized objects. But the problem, as far as I see it, is having multiple ways of accessing the file system and very bad documentation about what to use and when. On one hand you have the node-style FS API (https://developer.adobe.com/indesign/uxp/reference/uxp-api/reference-js/Modules/fs/) that is fairly standard and easy to use, then you have the unholy mess that is the storage API (https://developer.adobe.com/indesign/uxp/reference/uxp-api/reference-js/Modules/uxp/Persistent%20File%20Storage/).
Everything that is InDesign DOM related uses the Node-style API. So I think the only time you need to bother with the storage API is if you need a File or Folder picker dialog (and even there you could probably just wrap a ExtendScript call in a doScript and use the old File.openDialog() method.

1 Like
8

I 100% agree with all of that!

I seem to recall, however, that ExtendScript strings for paths were POSIX, but here in UXP, I’m seeing that I have to make OS specific strings. Unless I’m doing something wrong, again. I guess even the POSIX strings had some oddities for Windows, with mapped drives having an initial slash.

jsw