Input suppression for specifc XML nodes (structured FM document)

[Apollo102]

Hi,

Is there a way to suppress input or changes in specifc nodes (structured FM document)?

Thank you for any pointer.

Regards

Apollo102

[Russ Ward]

Apollo102,

Not really, unless you wanted to write some scripting. The structured FM authoring interface is fairly loose, relying on post-authoring validation rather than pre-authoring restrictions. A script could provide some measure of intervention, but of course that adds some complexity.

Russ

[Apollo102]

Hi Russ,

thank you for your reply.

Inspired by the following post I've tried the following:

Double click event on a specific element in a FrameMaker document    

function Notify (note, object, sparam, iparam) { 

    switch (note) { 

    case Constants.FA_Note_PreFunction :

         //alert("Constants.FA_Note_PreFunction  " + "  "  + object +  "   "  +  sparam + "  "  + iparam);

          if (getElementName(getCurrentSelectedElement(oDoc)) === "xyElement")

          {

                if (iparam === 3570 | iparam === 274  | iparam === 2576)

                {

                    ReturnValue(Constants.FR_CancelOperation);

                    alert("No input or modifcation in this element permitted");

                }

          }     

      break;

     } 

}

By trying I mean that I have found the following values for iparam so that I can suppress the corresponding keyboard inputs or modifications with ReturnValue (Constants.FR_CancelOperation).

3570: KBD input

274: backspace (delete)

2576: insert XML element (catalog and selection insert)

Now my questions:

Is this an acceptable way or are there good reasons not to do so?

If so is there a better way?

Where can I find a list of the possible values that are given back to me via iparam? Just to complete my list.

Thank you for your advice.

Apollo102

[Russ Ward · Accepted solution]

Hi Apollo102,

First of all, I have to apologize that I didn't realize I was in the scripting area of the forum. I threw out the idea of scripting casually as if it were a remote possibility for you, but obviously that was what you came here for. So my initial response had a silly context to it.

I'm impressed that you moved so far so quickly. This business of notifications and constants can become tricky. Here are some answers to your questions....

Is this an acceptable way? My answer is yes. It's the way I would do it. Note this though... more than likely, once you run the script and activate the notifications, you will need a FrameMaker restart to turn them off. Maybe you could turn them off with a Notification() call somehow in the same script afterwards, but I'm not sure. Either way though, this is just the nature of the ESTK environment and just something to be aware of.

Where can you find a complete list of action constants? A most excellent question and one without a good answer, that I am aware of. These values are based on something called "fcodes" from the original FDK implementation and are defined within an fcodes.h file within the FDK. Here is an excerpt of this file that shows the definition for what you called "KBD input" (3750):

#define KBD_API  0xDF0    /* Dynamic (API clients/config) */

#define KBD_API_SHORTCUT  0xDF1    /* API used only from shortcut */

#define TYPEIN  0xDF2    /* OUTPUT-ONLY: Text type-in */

#define INLINE_TYPEIN  0xDF3    /* Inline input for Asian text */

#define KBD_VIEW_API  0xDF4    /* Dynamic (View API clients/config) */

#define KBD_VIEW_API_SHORTCUT  0xDF5    /* View API used only from shortcut */

#define KBD_VIEW_SWITCH  0xDF6

All values in this file are defined in hexadecimal format, so the value 3750 is equivalent to 0xDF2 in this file, that is, the TYPEIN constant.

You could go get this file and browse through it, but constant names are sometimes cryptic and there are many, many hundreds of them. So my suggestion is this... just put an alert box in your code that displays the event code, then manually do whatever action you think should be restricted and see what code pops up. I see a line of code already in your sample that will do just that... I think you could just uncomment that. Maybe move it under the element tag conditional. In this case, that's likely how I would determine the correct codes.

Hope this helps.

Russ

[Apollo102]

Thanks Russ.

Seems to be that I am on the right way. When I will see that more inputs has to be supressed then I can figure out with my alert which value I need to add.

Apollo102