Dear friends,
Even if this project may be to ambitious for my knowledge I’m at least one step further than what I presented Barb Binder in November.
- The script is intended for the unstructured interface. Any structure related find or replace stuff is left out.
- FMfindRepl v0.6 finds everything which I can handle (see the second page of the documentation (aka help file).
- The script does not yet replace anything. I see many challenges ahead. Just look at the famous comment by Russ Ward in https://forums.adobe.com/thread/895626: now, lets jimmy the text range in memory to place it directly.
- While the script reacts on the change of the active document (Notify function) it does not find in books or a selection.
- The help file currently displays the pdf “Developer-log”. Later it will open the according web-page.
- The RegEx support is rudimentary. It opens a web page.
- The script has only an English interface, even if you run it in a French FrameMaker. This will change towards version 1.0, because this will require fine-tuning the UI.
Nevertheless some features go beyond the standard Find/Change panel:
- Error messages and information about searched items is presented in an edit area rather than a separate dialogue which must be dismissed.
- The reason of the whole project was to save and retrieve settings by a name. The settings are kept in an xml file.
- When selecting a find category which comprises a catalogue (e.g. Character Tag) you get an additional drop down list to select from.
- The various options are enabled depending on the find category. This avoids dangerous or anyhow not used constellations. This required change of the drop-down lists for the Replacement modes to radio buttons.
Installation
- Download https://daube.ch/zz_tests/FMfindRepl.zip
- Expand the ZIP
- Copy file FMfindRepl.jsx and directory FMfindRepl into the Startup folder of FM
- File allerlei.fm (FM-15) is a test file containing all objects which can be searched for.
Usage
- With a document open you can invoke the panel by ESC q f d.
- While the panel is open you may switch to another document for further tests.
- Use the HELP button to get my developer-log pdf with a complete description of the UI.
Remarks
- Concerning the statement of Stefan in https://community.adobe.com/t5/framemaker/can-i-create-a-library-of-regex-searches/m-p/11451335 «For Find/Change there are "many to many" relations between find and change strings.» I try to conquer this by the table asFindType in file FMfindRepl_en.xml.
- Those looking into the code: it is my personal style. It is not yet streamlined: you find incomplete comments, duplicate portions and superfluous parts.
- Why two buttons: Save and Save new? See the docu, page 9.
- The project so far consumed 214 working hours.
Please send messages concerning errors directly to me.
1
Reply
The current development path turns out to be a «cul de sac», a dead end:
- It is not possible to identify certain found objects. See this post.
- The algorithm for Clone Case is not clear. Maybe it could be evaluated by a large set of experiments ...
- The most serious problem that keeps the project grinding to a halt is the following: The found text is in the found Text Selection. But: Regex replace requires to know the matched text in the symbols $0 $9. I have not the simplest idea from where to get this information.
There is no mention at all of the terms “regex” or “regular expression” in the ExtendScript or FDK documentation (only Constants.FF_FIND_USE_REGEX is mentioned in the FM Scripting Guide).
And as you know; Regular Expressions are the trigger of this project.
The original post was written before Christmas and just published at January 3. After a pause of some days and enough distance from the work done so far I got this idea:
Why not try to follow the first idea: control the FM Find/Change dialogue from the outside with sent keystrokes? But there are also constraints or even insurmountable hurdles:
- Feedback from the FM-dialogue back to the script is not possible! The process can only work in one direction. Hence the timing of keystrokes may be cumbersome - keep it slow...
- Of course the key strokes depend on the UI language. This is easy to handle ...
- But the following at first killed my idea: Check boxes are toggles! I can not know their state before sending a SPACE to toggle them.
- But thanks to the origin of FM in Unix I tried to find out an ‘absolute’ setting like we have in the behaviour of TABS in paragraphs, whether check boxes can be set/unset independently of their previous state. And guess what: I found these: ESC, + sets a check box, ESC, - clears the check box. Again, this is not in the documentation or Help...
So I tried the following manually (feasibility). Note the headstand required to access values in the drop down lists (where several items start with the same character).
Conclusion
It should be possible to control the FM Find/Change dialogue by an AHK (Auto Hot Key) script. This gets input from a file in which the necessary keystrokes are listed. The extend script must either assume a certain processing time (which is dangerous, because the time may vary significantly, think of Change All...).
A better idea might be to leave the ‘pressing of the button’ to the user and use FMfindRepl just to fill the FM-Find/Change dialogue with settings.
This lets me hope to be able to continue the project - but first I use some time in my hobby room: a kindergarden nurse wants to have a small convoyer belt to let the children play 'post office' with it 'sorting parcels'
AdChoices