To update Text Insets with FDK, FDK Programmer's Reference suggest to use F_ApiUpdateTextInset function and to stale before the text inset object.
For that, FP_TiLastUpdate property must be set to 0.
As this FP_TiLastUpdate property is not referenced among those available in Solution Explorer window of MS Visual Studio project, do you have any idea or solution where to find it?
I don't have Visual Studio, so I cannot check there, but the Scripting Guide normally shows all the same properties. It lists LastUpdate instead of TiLastUpdate. Maybe it is a typo in the FDK Reference, but then it might be a typo in the Scripting Guide. I know I have succesfully used this property a long, long time ago - I just do not have those sources anymore to find it out. I hope the typo is in the FDK Reference and this solves your problem.
You are right as always!
fapidefs.h library contents shows
|#define FP_LastUpdate||2052 /* R/W Int when the inset was|
|* last updated, number of|
|* seconds since Jan 1, 1970|
Maybe one day, who knows, Adobe will use FM to produce documentation without typos;-)
I know they are already using DITA - in FM - to create the docs. But there is a LOT of docs and there are not enough people to check everything. When I cannot find a property or have my doubts, I use the Data Browser in the ExtendScript Toolkit and set a breakpoint in my script to see exactly which properties are available. Not all are exposed, but they will usually have the same names as in the FDK interface, minus the Api_ prefix.
I am using the FDK Reference Guide to find info that is missing from the Scripting Guide. It seems you could use the ESTK's Data Browser to find properties and methods for your FDK programming. 🙂
Good to read that the right property was found.
With apologies for derailing this thread, I have to ask... why would you use DITA to produce an FDK or ExtendScript manual? I can't think of anything that DITA would give you except a pile of overhead to manage. The time required to manage this overhead would replace the time used to ensure accurate content, perhaps the reason that the content is the way it is. Is there something obvious that I am missing here?
Well, you have to use some standard to write your content in. Unstructured FrameMaker does not allow structural reuse (the text insets really don't cut it) and there are a lot of reasons in a large enterprise to not use a custom XML but a standard that all other other departments are using as well. Plus the FrameMaker team has invested heavily in support for DITA, so it would be a strange message if they did not use it for themselves.
DITA is not just about reuse. It is about using key references, variable content, filtering on attributes, adding semantrics without breaking the standard tools. All of these items can be done outside of DITA but as the majority of structured content creation is done in DITA today there is really no reason NOT to use DITA.
What would really be useful is for Adobe to provide a way to "open source" some of their documentation. Then some of us could contribute updates as we discover things as we work with the FDK and ExtendScript.
Very true, and with DITA that would be a viable option. I am sure the FM dev team would love to do this, but Adobe company policies might block it. I will pass this idea again and see what their response is.
So for Rick's comment, totally agreed. For Jang, I don't agree with that... I think there is a list of significant reasons not to use DITA, especially if you are using the topic-based authoring approach. If you are not reusing content at the topic level, it is a big exercise in breaking everything into little pieces and then putting it all back together again, for no benefit. And, at a loss of flow and context. You could spend that time writing and editing useful information instead. For an FDK manual, I can't think of any compelling need for topic-level reuse.
But again, I have hijacked the thread with a non-relevant point, so I will leave now having thrust my opinion into the mix. Anyone else can have the last word. Thanks!
This won't be the first thread that has been hijacked, so I will add my two cents. DITA is useful for some kinds of documentation, but it is definitely not the best schema for all technical documentation. The problem I have is that many clients equate going to structure as going to DITA. I will show them DITA because of the existing FrameMaker (and other) infrastructure, but tell them that DITA might not be a good fit for their documentation requirements. Then I tell them that we can make a custom schema that will better fit their requirements. We get all of the benefits of structure (guided authoring, automatic formatting via the EDD, XSLT processing, vendor-neutral XML, etc.) without force-fitting their content into topic-based DITA.
I have had good success with my clients with this approach. This has been especially effective with unstructured FrameMaker clients that have been very disciplined and consistent with their templates and formatting. We create a schema that closely mirrors their unstructured documents and are able to move them to structured FrameMaker and all of its benefits, while leveraging their existing templates. I agree, this approach is not for everyone, but neither is DITA.