FWD » Core Development » User Interface

• LINE attribute
• CURRENT-ITERATION attribute
• GET-ITERATION() method
• STREAM-IO option
• SCROLL option
• NO-ATTR-SPACE option

Created task branch 6438a from trunk revision 14696.

Greg Shah wrote:

• STREAM-IO option
• SCROLL option
• NO-ATTR-SPACE option

All of these options to implement as part of the DEFINE FRAME ... WITH .. statement, right?

The 6438a updated for review to revision 14697.

This change adds conversion support and partial runtime support for attributes/methods/options noted above.

The following options have partial runtime support:
SCROLL, STREAM-IO - need to clarify how it actually works.
NO-ATTR-SPACE - this option is obsolete and is not supported in 4GL. I think we have nothing to implement for this.

So if we need urgent support for GET-ITERATION() method in other project we can merge 6438a into trunk and continue work here with new 6438b.

Also GET-ITERATION() method for Buffer object has only stub at runtime. I think we need to ask the persistence expert for implementation.

The 6438a rebased with recent trunk 14698. The new revision is 14699.

Code Review Task Branch 6438a Revision 14699

Overall the changes are good. The only problem I see is with the implementation of GenericFrame.line(). It has been implemented as a rendering of dynDown but I think it is supposed to just call frameLineWorker(). Per the 4GL documentation, LINE should be the same as the FRAME-LINE built-in function instead of a reporting of the DOWN value.

Also GET-ITERATION() method for Buffer object has only stub at runtime. I think we need to ask the persistence expert for implementation.

It is OK to have a stub there. In the gap analysis, mark the runtime support as partial and put a comment into the gap rules that the buffer implementation is a stub.

Greg Shah wrote:

Code Review Task Branch 6438a Revision 14699

Overall the changes are good. The only problem I see is with the implementation of GenericFrame.line(). It has been implemented as a rendering of dynDown but I think it is supposed to just call frameLineWorker(). Per the 4GL documentation, LINE should be the same as the FRAME-LINE built-in function instead of a reporting of the DOWN value.

Agreed.

The 6438a updated for review to revision 14700.

Notes resolution.

Code Review Task Branch 6438a Revision 14700

The change is fine. I've edited the comments and history in revision 14701. If you've tested this, it can be merged to trunk.

Greg Shah wrote:

Code Review Task Branch 6438a Revision 14700

The change is fine. I've edited the comments and history in revision 14701. If you've tested this, it can be merged to trunk.

OK. Starting merge into trunk.

Branch 6438a was merged to trunk as revno 14699 then it was archived.

Further investigations shows the following:
1. Seems like the SCROLL option is currently supported at runtime. At least for testcase used SCROLL frame option the FWD behaves the same as 4GL.
2. The STREAM-IO is not supported. The following change adds basic implementation FrameGuiImpl.java:

...
   public void initialize(WidgetId id, FrameConfig wcfg)
   {
...      
      // the frame's title uses the window title font
      LabelConfig tcfg = new LabelConfig();
-      tcfg.font = FontManager.WINDOW_TITLE_FONT;
-      gf = new GuiFontResolver(window(), gd, tcfg, false);
+      if (config().screenIO)
+      {
+         tcfg.font = FontManager.WINDOW_TITLE_FONT;
+         gf = new GuiFontResolver(window(), gd, tcfg, false);
+      }
+      else
+      {
+         tcfg.font = FontManager.DEFAULT_FIXED_FONT;
+         gf = new GuiFontResolver(window(), gd, tcfg, true);
+      }

      // frameScroll height can be computed only after gf is created/assigned
      updateScrollPaneSize();
...

The idea is to always use default fixed font if the STREAM-IO(which is logically !SCREEN-IO) is in use.

So we could open 6438b, commit the FrameGuiImpl and consider the base runtime is implemented for SCROLL and STREAM-IO options.

Is forcing the use of the fixed width font really the only thing that needs to happen to support STREAM-IO?

Greg Shah wrote:

Is forcing the use of the fixed width font really the only thing that needs to happen to support STREAM-IO?

I think yes. The other thing to be happen is setting USE-TEXT frame option to true. But it is already implemented.

As general note this mode is designed for frame output to be easily converted to printer friendly format to provide the simple text formatting to make hardcopy on paper (or PDF). Probably we need some significant time to spend if something does not work out of the box at this time. This can become a big task. We need scenarios, baseline samples and so on...

The other thing to be happen is setting USE-TEXT frame option to true. But it is already implemented.

You mean that we already set USE-TEXT to true when the STREAM-IO option is present? Or that we do support USE-TEXT already but still need to set it to true when the STREAM-IO option is present?

As general note this mode is designed for frame output to be easily converted to printer friendly format to provide the simple text formatting to make hardcopy on paper (or PDF). Probably we need some significant time to spend if something does not work out of the box at this time. This can become a big task. We need scenarios, baseline samples and so on...

We can set the runtime support level to "basic" and defer the testcases until later.

Greg Shah wrote:

The other thing to be happen is setting USE-TEXT frame option to true. But it is already implemented.

You mean that we already set USE-TEXT to true when the STREAM-IO option is present?

Yes we already made USE-TEXT in sync with STREAM-IO. No need more changes here.

Or that we do support USE-TEXT already but still need to set it to true when the STREAM-IO option is present?

But I do not know how USE-TEXT option changes are processing at runtime now.

As general note this mode is designed for frame output to be easily converted to printer friendly format to provide the simple text formatting to make hardcopy on paper (or PDF). Probably we need some significant time to spend if something does not work out of the box at this time. This can become a big task. We need scenarios, baseline samples and so on...

We can set the runtime support level to "basic" and defer the testcases until later.

Yes, I think this is what we need at this time.

Go ahead with these changes.

Constantin: What do you think?

Eugenie, the priority of these attributes is for ChUI, although if any missing GUI support can be added easily to be 'basic or better', we should do so.

For STREAM-IO, there was work done at #2368 (for ChUI), but the GUI behavior was deferred.

For NO-ATTR-SPACE - this is already implemented in FWD I think, is the opposite of ATTR-SPACE attribute. There is a mark as 'deprecated' in latest docs for OpenEdge ATTR-SPACE attribute, but I don't think this means is no longer backwards-compatible. In ChUI, this test shows different layout:

def var ch as char.
display "test" ch with frame f1 side-labels attr-space.
display "test" ch with frame f2 side-labels no-attr-space.

About GET-ITERATION - does this convert/compile properly in FWD?

message frame f1:get-iteration(i).

Constantin Asofiei wrote:

About GET-ITERATION - does this convert/compile properly in FWD?
[...]

Yes it does.

Created task branch 6438b from trunk revision 14703.

Rebased 6438b with recent trunk 14706. New revision is 14707.

Guys,

Can I merge this into trunk?

Rebased 6438b with recent trunk 14707. New revision is 14708.

Greg,

I have no plans to add new changes here. So probably we need to merge the current version to trunk? What do you think?

Rebased 6438b with recent trunk 14709. New revision is 14710.

Code Review Task Branch 6438b Revision 14710

The changes are good.

You can merge to trunk after 7589a.

Greg Shah wrote:

You can merge to trunk after 7589a.

OK. I'm starting.

Branch 6438b was merged to trunk as revno 14711 then it was archived.