Hi,
Arbortext 5.4 is the platform.
I want to define a macro/key/right click menu option (doesn't matter which) to run a process against some XML files, including the one I currently have open in Arbortext. Specifically, I want to run part of my org's internal publishing toolchain. This toolchain requires an exclusive lock on every XML file it uses as input, and as it's not under my control, this can't be changed. So I need to temporarily wrest the file out of Arbortext's hands, run the piece of toolchain, and then open the file back up in Arbortext. This has provided after-dinner entertainment for me for several days, and I still haven't solved it.
If you have any ideas on this, please let me know.
What I've found so far:
1) window_close() doesn't. It's documented that it doesn't actually close the window (it MINIMIZES it, making one wonder why it was not called window_minimize()), but still.
2) doc_close(current_doc()) does not seem to actually fully close the file, from Arbortext's point of view. I had high hopes from the manual that this would be enough to fully close all file handles to the document, but it turns out that Arbortext still has one of its two edit windows for that document open after doc_close() is called. Specifically, before I do the doc_close(), when I enumerate all edit windows for all documents, two windows are attached to my document (the doc map and edit panes). After the doc_close(), when I enumerate edit windows, there are still two: one that now has a name beginning with "scratch" (former edit pane, now blank), and one still with a name of the document I had wanted to close (doc map, still populated correctly and editable/navigable). When I call the doc_close() on the document again, the remaining window attached to the document does actually go away and our toolchain can open the XML document for exclusive access.
3) window_destroy() is really destructive. That is, it tends to close Arbortext (which, of course, also stops the macro from running), if you only have one doc open -- which is our usual use case. So I gave up on it and removed it once I figured out that the second doc_close() on the document allowed the toolchain piece requiring exclusive access to the XML file to run.
4) That brought the problem down to simply re-opening the document I'd just closed, and getting it up in a horizontally split window with a doc map on the left and an edit pane on the right. So the rest of the code basically does a doc_open(original document path) and a window_create specifying the docid returned from the doc_open call, and then a window_show to put it on screen. Wen that ran, the result was a new window that was split 50/50 horizontally, and then the right pane was split 50/50 vertically, with my content in the upper right pane and the left pane and bottom right pane both blank. I don't believe I asked for splits, and don't know why this happened. When I start Arbortext I normally see a single window or a 25/75 split screen; I'd never before seen this arrangement of windows.
5) A series of late night experiements with window_remove_split, window_show and window_redisplay didn't change what I see on screen.
So my questions are:
1. Is there some preference somewhere that is causing my newly created edit window to default to both vertical and horizontal splits? Where do I find it?
2. Is there anything I can do to open a window and guarantee it's not split? (remove_split() after the fact doesn't seem to change it, so clearly I have to prevent it)
3. Can I just reopen the document in the window that becomes associated with the scratch document, once I'm done running my toolchain? I couldn't find an API function to attach a document tree to an existing window. The thing is, that scratch window is still out there, and I'd like to put my document back into it, seeing as that's the window (as in, same window ID) that my document was originally in.
4. Do you have a simple answer to this that I haven't thought of yet? It seems to me that this is more complicated than it should be, which leads me to wonder if there's a simple solution I've overlooked.
Thanks.
