Styler: Change marks in the margin

[RichardSteadman]

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

[GarethOakes]

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

[RichardSteadman]

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

[GarethOakes]

The easiest APP way is to use accolades... or you can try siderules stuff.

-G

[ebenton]

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.

[bibach]

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. 😉

[naglists]

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. 😉
>
>
>

[ebenton]

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?

[naglists]

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.