A bit more about how I'm using "SetProps". First I tried to get all props with "GetProps", change the specific one, and then set them all with "SetProps". This doesn't work, the script says "timeout error". I then tried to construct just a single specific PropVal, then add it to PropVals object, and use this single value with "SetProps"; this doesn't work either, nothing happens.
A very challenging question. So far, I can't figure it out. Like you, I see a new component created as a file, and any attempt to set FP_ComponentType has no effect. There is this function as well, that claims to insert a component of a certain type, but apparently only works for structured books:
comp = book.NewBookComponentOfTypeInHierarchy (compName, compType, elemLoc);
I didn't try it.
One note about GetProps/SetProps... I often have trouble with those, especially when I attempt to tweak a property and reset. So, no surprise to hear of your trouble there. Normally, it is just better to set the property directly. That is, if it actually works.
I apologize that I don't have an answer for you. I'll keep thinking about it.
From what I understand, there's no way to change this property at all. It's probably set automatically. Here's what brought me to this conclusion: I decided to skip folders for now and started to add documents to the book and run into the same problem: I create a component and its ComponentType is set to (an undocumented) 512 and I cannot change it to, say, FV_BK_XML (0x20) But if I first make sure I have the document's file on disk and then create a component and set its Name to point to the file, I get the right FV_BK_XML type automatically.
The bad news is that, obviously, I cannot do the same for folders or groups as they are not mapped to filesystem objects.
Mikhail, I don't know. I would think that you should be able to set it. There are clearly bugs involved here. The fact that SetProps() hangs a script proves that, I think.
One thing, with regard to ComponentType 512, this is undocumented because the documentation has errors. 512 is Constants.FV_BK_FILE, which should be in the list instead of FM, MIF, and XML. In other words, the last three items in this list are wrong and should be replaced by FV_BK_FILE:
• Constants.FV_BK_FOLDER (0x02) - Folder
• Constants.FV_BK_GROUP (0x40) - Group
• Constants.FV_BK_FM (0x8) - FrameMaker document
• Constants.FV_BK_MIF (0x10) - MIF document
• Constants.FV_BK_XML (0x20) - XML document
I did think of a rather clunky workaround to this problem. I'll put it into a separate response.
Here is a workaround to this problem, although admittedly not very convenient. I would use it if I were desperate.
In the GUI, FM allows you to copy a book component from one book to another. This includes folders and you can simulate this with a script. For example, to copy the first component of one book to another:
var book = app.FirstOpenBook;
var comp = book.FirstComponentInBook;
comp.ComponentIsSelected = true;
book = book.NextOpenBookInSession;
- You have to use FCodes because the book object does not provide a Copy() method
- You will have to do some work to control where the paste occurs. It seems to occur after the currently-selected component
- You will need a "dummy" book from which to copy
- If you are doing multiple paste actions, you need to rename the folders as you go, because a book apparently can't have two folders with the same name.
Anyway, this is a very complicated way to get around the bugs with the expected methodology. I hope it helps.
There is a chance that this is an FDK bug. I haven't been able to do it with FrameScript either. This is often the methodology I will use for something I am not sure of in ExtendScript: I will do it with FrameScript (because I am familiar with it) and then translate it to ExtendScript. I am curious if it would work in the FDK.
Well Rick, since you asked, I had to try. Indeed, the behavior is the same. This call does nothing:
F_ApiSetInt(bookId, compId, FP_ComponentType, FV_BK_FOLDER);
...and an attempt to copy all properties from a folder component to a file component results in a crash.
Not good. The way I understand it, if it doesn't work in the FDK, it is not going to work with either ExtendScript or FrameScript.
According to the FrameScript documentation, ComponentType (FP_ComponentType) is a read-only property.
I wonder how they know, unless it was just by observation. According to the latest FDK documentation, FP_ComponentType doesn't even exist. It is mentioned briefly in the FDK9 supplement, but that's about it. I guess this doesn't surprise any of us, though, so I'll let that dead horse be for now.