content: CSS issue in XMAX 5.5

[craig_83]

I am using XMAX 5.5 and have created a set of custom tags to display in Normal view.

I have displayed these tags using the CSS and the content property, an example of this is below:

MyElement:before {
display: inline;
content: url(CssImages/StartTag.png);
background: #dcdcdc;
}

MyElement:after{
display: inline;
content: url(CssImages/EndTag.png);
background: #dcdcdc;
}

The problem is when I am in one of the elements and try to move out of the element (that is surrounded by my custom tag images) the cursor moves back to the start of the element, this only occurs in Normal View. For example:

The cursor is represented by |:
(TagImage)T|est(TagImage)

I move the cursor left:
(TagImage)Te|st(TagImage)

And again:
(TagImage)Tes|t(TagImage)

When I move again the cursor moves back to the start:
(TagImage)|Test(TagImage)

This means I cannot move outside of the element using the keyboard arrow key. It only happens when trying to go to the right, I can move the cursor left and out of the element with no problem.

Any ideas?

Reply

[jonathanh]

I am having the exact same issue. Once an element is surrounded by images, as mandated by the CSS, I can't use the 'right-arrow' key to move beyond the right hand boundary of the element.

As crag_83 describes, I get to the point wheree the cursor is just before the last character in the element. The very next 'Right-Arrow' keypress causes the cursor to flip back to the start of the element again.

I can use the mouse to position the cursor at the end of the element without issue.

If there are no images mandated by the CSS the problem goes away.
If the element contains a Template processing instruction, the problem goes away.
If the element contains no text, the problem goes away.

I have broken this right back to a simple example using just an XMAX Control in a WinForms Control, which is wrapped in a WPF Control. The problem still occurs.

This is very frustrating for users. If an element is prepopulated with content users often need to alter this. It is a common requirement to move the cursor to the end and then backspace from there, e.g. when wanting to change the trailing day number of a date.

Any ideas on resolving this would be very much appreciated.

Thanks…

Reply

[Derek Read]

We think we've identified the issue that is triggering this behavior. There is no workaround for it short of avoiding use of CSS:after for the purpose of embedding images after element content.

This feature was added to the 5.1 release of XMetaL Author in anticipation of a requirement for another feature that was ultimately never implemented. As a result it was not fully tested (nor officially documented as being supported or even existing as far as I am aware). However, it was also mistakenly left in the product even though the other feature was never completed. Note that XMAX inherits most of the same basic functionality implemented in XMetaL Author and so it also mistakenly received this untested feature with its 5.1 release.

We are now looking into the cursoring (move right) issue. We hope to test and get it working in a future release. In the meantime the only recommendation I have is to avoid use of CSS:after to render images after an element's content. My limited testing so far shows that using CSS:before to display an image with this feature seems to be OK as far as keyboard navigation is concerned (ie: moving left and right past and image displayed using CSS:before works). The older and documented feature for rendering text before or after element content is still working properly and is unaffected by this cursoring bug as far as I can tell. That feature went through our standard QA processes many years ago.

Note: in craig_83's description in one portion he states that moving the cursor “left” does not work when he means “right” in all cases. Just wanted to clarify that in case others might be confused.

Reply

[jonathanh]

Well, I did find a very hacky workaround for this in XMAX 5.5. This is all driven from a C# .Net WinForms wrapper for the XMAX control (using the interop which is generated when you drop an XMAX control onto a WinForms control).

In the 'PreviewKeyDown' event of the XMAX control I do the following:

[code]private void axXMetaLControl_PreviewKeyDown(object sender, PreviewKeyDownEventArgs e)
        {
            if (e.KeyCode == Keys.Right && !e.Control)
            {
                /* You can't 'right-arrow' the cursor past the final character in an
                * element, if that element happens to be bound by a CSS-specified
                * 'after' image.
                * We have to do some stuff to move the cursor beyond the
                * element and then step it back. The final step of this has to be
                * handled in the UpdateUI event. */

                var startingRange = this.XmaxControl.Document.Range;
                var rangeToPlayWith = startingRange.Duplicate;

                rangeToPlayWith.SelectAfterContainer();

                int i = 0;

                while (!rangeToPlayWith.get_IsAdjacent(startingRange))
                {
                    rangeToPlayWith.MoveLeft(SQMovementType.sqMove);

                    i++;

                    if (i > 2)
                    {
                        break;
                    }
                }

                if (i == 2)
                {
                    // CTRL+RIGHT doesn't cause the issue! And at this position
                    // RIGHT has the same effect (or should do!) as CTRL+RIGHT.
                    // So we send a CTRL+RIGHT keypress.
                    SendKeys.SendWait(“^{RIGHT}”);

                    // Now the original RIGHT keypress will happen too. This
                    // will need to be corrected in the UpdateUI method
                    // (if we handle it here the original issue will recur).
                    // So we set a global private variable which will be picked up
                    // in UpdateUI…
                    this._movedTooFarRight = true;
                }
            }
        }[/code]

Note that I can find no way to stop the original 'Right-arrow' operation from completing in addition to the hacked 'CTRL+Right-arrow'. So I have to set a global boolean which says 'we went too far right' and then check for this this in the 'UpdateUI' event (code not shown for this). If it's true, we step back one cursor position again.

Note also that I have to step beyond the container and then work backwards. I can't 'MoveRight' with the range because the same issue happens then as well (i.e. the range cursor jumps back to the start of the element).

The only issue with this (other than I'm chucking state around between events which makes me uncomfortable) is it is really slow and causes a noticeable lack when using the 'right-arrow' key. I'm wondering if there are any more efficient ways to work out where the cursor position is within the Element.

Reply

[Author]

Posts