MXP frames
2. Run this from console in Portal app:
Event.fire("internal_mxp","<FRAME Name=\"Testo\" Scrolling=\"yes\" INTERNAL Align=\"left\">");
Event.fire("internal_mxp","<DEST Testo>abcdefg\n\rabcdefg\n\rabcdefg\n\r</DEST>");
Event.fire("internal_mxp","<DEST Testo>zxy\r\nzxy\r\nzxy\r\n</DEST>");3. They do autoscroll with new text as necessary but don't allow buffer scrolling. The MXP spec seems pretty vague in this regard; zMUD seems to allow buffer scrolling and autoscroll regardless of this setting. So what I'm asking for is buffer scrolling (and scroll bars would be cool
).4. Not too worried about it. Not clear whether there are any cases where DEST can't be used in place of REDIRECT.
5. My goal is more to control the starting position of a window with respect to the main ScrollView (just above, just below, just left, just right). I'm basically trying to create frames that are viable in both zMUD and portal. zMUD's layout is based on docking windows into the main window; obviously portal not so much.
Please Log in or Create an account to join the conversation.
Vodur wrote: ...
3. They do autoscroll with new text as necessary but don't allow buffer scrolling. The MXP spec seems pretty vague in this regard; zMUD seems to allow buffer scrolling and autoscroll regardless of this setting. So what I'm asking for is buffer scrolling (and scroll bars would be cool
...
5. My goal is more to control the starting position of a window with respect to the main ScrollView (just above, just below, just left, just right). I'm basically trying to create frames that are viable in both zMUD and portal. zMUD's layout is based on docking windows into the main window; obviously portal not so much.
1, 2, 3, and 5 done.
Re 3:
Like zMUD, I don't see much of a point in disabling buffer scrolling. If the server wants to flush the buffer, it can send a request to empty the area, then send a few lines to have still appear after the flush, etc. I'll probably set some sensible absolute max for all buffer sizes, just like there is one for the main ScrollView.
Re 5:
Given how the portal app UI works, any initial alignment in relation to the ScrollView would have to be calculated in absolute pixels, and the use of the align attribute is to help you automatically stick to the edges of viewable space instead (which I think will look better in most cases).
So, to be precise, right now the behavior is to ignore "INTERNAL" in the sense that we won't be inserting things inside a ScrollView that may or may not exist (and most certainly won't look good with stuff inside it). We honor align="left | right | top | bottom" in the context of the total viewable area. And as an added bonus, we support "top left", "right bottom", etc.
Please Log in or Create an account to join the conversation.