Skip to main content
R
RichardSteadman10-Marble
10-Marble
July 5, 2012
Question

Styler: Change marks in the margin

  • July 5, 2012
  • 8 replies
  • 1660 views
Hi,

I need to put custom change marks in the page margin beside
changed content.

I use a UFE with side-by-side alignment with a negative offset.

This works for marks beside regular text, such as paragraphs
and titles.

But there are two problematic cases:

1. Next to a list item the side-by-side layout interferes with
the proper indent of the list number and the following text.

2. When the change mark is on a table row, the side-by-side does
not seem to work (not too surprising).

So, is there another way to put text in the margin that might
work better?

Environment: Styler 6.0 M040 (APP Engine)

Thanks,
Richard

    8 replies

    G
    GarethOakes16-Pearl
    16-Pearl
    July 5, 2012
    If you're using FOSI, it supports the <chgmark> group of characteristics. Just search for "change mark" in the Help Center if you need more info.

    -G
    R
    RichardSteadman10-MarbleAuthor
    10-Marble
    July 5, 2012
    Hi Gareth,

    Thanks, but we're using the APP Engine, not FOSI.

    I was thinking about an APP source edit to generate an inline frame
    or something, but I was hoping there might be a simpler way.

    Regards,
    Richard


    G
    GarethOakes16-Pearl
    16-Pearl
    July 5, 2012
    The easiest APP way is to use accolades... or you can try siderules stuff.

    -G
    E
    ebenton1-Visitor
    1-Visitor
    July 5, 2012
    Another issue from some of our software developers. Anybody have a clue? We have opened a case with PTC support, but it never hurts to ask here (unless somebody starts insulting me and hurts my feelings).

    Here it is:

    To whom it may concern,

    It appears that Arbortext's (v6.0) sequence of events during Exit/Close is affected by the fact the cursor (i.e., insertion point) is with a table entry (OASIS/CALS table). This seems to be the case only while View > Tables > Table Markup is deselected. (a.k.a. table grid view)

    In our case, this manifests itself as our screen FOSI being processed after some resources have been released - specifically, connections to custom COM functions have been lost. This results in the appearance of several error dialogs appearing, again after closing while the insertion point is within a table entry.

    Additional details:
    1. If the insertion point resides within a table cell then custom COM resources are being released as part of the WindowClosing event but before the DocumentClosed event. We get errors about invalid/non-existent entry IDs.
    2. If the insertion point does not reside within a table cell then COM resources are released explicitly through custom ACL requests as part of the DocumentClosed event.
    B
    bibach1-Visitor
    1-Visitor
    July 5, 2012
    Sounds like a timing issue. If you're shutting down Editor anyway, does it
    matter? Seems like the easiest solution would be to just add a check
    before access to any of the COM components to make sure they're still
    available and if not, then return some reasonable "null" result without
    throwing an error. Frankly, the guy who wrote this stuff to begin with
    should have known better (heheh... whoops!).

    If the COM components being closed automatically by Editor instead of by
    the ACL code causes a problem, then you probably just need to put a hook
    into the window closing to run the same "close down COM components" ACL
    code so that it'll happen on either window or document closing, whichever
    comes first.

    But, then, I'm probably oversimplifying... (not unheard of)

    -Brandon 🙂

    PS - Given the request for insults, I'd be tempted to say something about
    how Goofy-lookin' Ed is, but knowing Ed, he'd probably take it as a
    compliment, retire and spend *every* day at Disney World. 😉


    N
    naglists1-Visitor
    1-Visitor
    July 5, 2012
    Hi Ed,

    Don't listen to Brandon. He's a trouble-maker.

    I may have run into the same or similar issue. In my case, however, I am
    working with new code in Editor 6.0, so I can't guarantee it is a version
    issue. Anyhow, when I am closing a particular document (which primarily
    consists of a table) and its window [I think I do a doc_close() and a
    window_destroy()], I am getting errors from within a table ui hide bit of
    code. I found that issuing:

    goto_oid(oid_root())
    caret 1,1

    prior to doc_close/windows_destroy tended to avoid the problem. Not sure
    which or both solve (side-step) the issue.

    On Thu, Jul 5, 2012 at 10:52 AM, Brandon Ibach <
    brandon.ibach@single-sourcing.com> wrote:

    > Sounds like a timing issue. If you're shutting down Editor anyway, does
    > it matter? Seems like the easiest solution would be to just add a check
    > before access to any of the COM components to make sure they're still
    > available and if not, then return some reasonable "null" result without
    > throwing an error. Frankly, the guy who wrote this stuff to begin with
    > should have known better (heheh... whoops!).
    >
    > If the COM components being closed automatically by Editor instead of by
    > the ACL code causes a problem, then you probably just need to put a hook
    > into the window closing to run the same "close down COM components" ACL
    > code so that it'll happen on either window or document closing, whichever
    > comes first.
    >
    > But, then, I'm probably oversimplifying... (not unheard of)
    >
    > -Brandon 🙂
    >
    > PS - Given the request for insults, I'd be tempted to say something about
    > how Goofy-lookin' Ed is, but knowing Ed, he'd probably take it as a
    > compliment, retire and spend *every* day at Disney World. 😉
    >
    >
    >
    E
    ebenton1-Visitor
    1-Visitor
    July 5, 2012
    Thanks, Paul,
    I presume that would affect the Pub caret PI so that the next time the user opens the document, the cursor will no longer be where it was when he/she last exited. Not a dead-on show-stopper, but still undesirable. Unless you have a way of avoiding this?
    N
    naglists1-Visitor
    1-Visitor
    July 5, 2012
    That it might. I'm working with a read-only file from which my authors are
    getting data, so forcing the caret to the top isn't an issue.

    Terms & ConditionsCookie settingsAccessibility statement