FWD » Core Development » User Interface

If a customer has a lot of .NET Windows Form usage, I'd like to discuss the kinds of things we can do to effectively help them migrate to FWD.

For example, we have a customer that heavily uses WinForms, especially the Infragistics Ultragrid. I'm thinking we might want to implement some custom controls to replace things like that. I'm NOT suggesting that we implement full WinForms support. Given a compatible control, we would write conversion rules to remap the 4GL code usage for the parts we can support.

Looks like there are .NET to AWT bridges like https://jnbridge.com/ which integrate winforms with AWT/Swing. But to bring this to web, it may be more complicated than rewriting the winform controls in Java.

Idea 1¶

Looks like there are .NET to AWT bridges like https://jnbridge.com/ which integrate winforms with AWT/Swing. But to bring this to web, it may be more complicated than rewriting the winform controls in Java.

• infragistics to .Net that means actual drawing and programmatic state change (focus, selection, copy, export etc.)
• .Net to infragistics that means hooks on Windows events to allow implementing certain actions done by the user or triggered by the system.

From .NET to AWT do you mean both-ways? That is, drawing operations will happen in Java AWT and Java AWT controls will route the events back to .NET simulating WinAPI?

• infragistics sends to Web client the actual drawing and programmatic state change. How?
• Web client sends to infragistics the actions done by the user. How?

• infragistics sends to AWT the actual drawing of the component and then we project that onto Web. We can use existing tools for AWT to Web (I am sure that are plenty) or we do the projection in-house: snapshot bitmap, send to WS.
• The tricky part is getting it functional in terms of interaction. We can send any action we usually record on WS back to Java client with our driver and bridge them to AWT. At that point, the AWT event will be sent to .NET.

What is relevant for FWD: we can implement some projection layer like "web-swing". This is rendering screens on Java and it send them to WS. This is a performance killer, but maybe we can make it a bit more hybrid to happen only for some controls. Maybe it relates to Hynek's UI work where he generated actual HTML controls for testing Web. Maybe we can have a similar mode where we generate controls that simply mirror Java AWT component (like an iframe, but for AWT and drawn on canvas).

For Web Browser OCX we render actual iframes and integrate in Web Client, so I was thinking of a custom "FWD OCX" that works like an actual canvas. One can draw (actual lines and pixels) on from legacy code and get triggers on it. But on the other hand, it has AWT integration to route drawing done by infragistics. Of course, tons of caching is required :)

PS: If we want to cut out AWT completely, we can spawn Win clients, draw on actual WinForms and "project that" on Web, but this will lock FWD on Windows - yuck!

For example, we have a customer that heavily uses WinForms, especially the Infragistics Ultragrid. I'm thinking we might want to implement some custom controls to replace things like that. I'm NOT suggesting that we implement full WinForms support. Given a compatible control, we would write conversion rules to remap the 4GL code usage for the parts we can support.

There are very specific methods in there:

• ApplyPresetFromXml
• EnforceXsdConstraints
• CreateObjRef
• ClearUndoHistory

I am not sure how extensively is used, but supporting an infragistics widget seems a lot of custom work. But none of the methods above (and way more) are actually supported for any widget in FWD.

Idea 2¶

The specified solution also has Web components (https://www.infragistics.com/products/ignite-ui-react/react/components/grids/data-grid). Most probably it doesn't match completely, but considering it is provided by the same vendor, maybe there will be a certain level of compatibility and patterns. So this idea is more about re-writting it to some kind of Web component that will be replaced by the actual Web component (React or whatever). We convert the code on their part and link their grid directly to this widget on Web. Maybe this can be a general widget something like the OCX that renders arbitrary widgets within a frame. This time, it will render a React component for which we can route the API on C# to the API in JS and is more or less like having server-code that drives the Web component directly.

Using AWT won't solve much for us considering the target will surely be web. The ideas for re-routing the output and input seem to be quite complicated. I'd stay away from idea 1.

Idea 2 seems interesting. I'd consider the scenario where those controls were running inside our HTML Browser OCX replacement. But this depends on those controls meeting the customer's needs. My original suggestion is a lot of work for writing custom controls but it could be made to meet user requirements.

Idea 2 is supposed to be HTML components which may bring their own complications (as we will want to integrate this to mimic a Windows native app, not a browser app - so the most concerning part is overlapping widgets, which we will not match with browser components - but this applies to the AWT bridge, also).

So for full compatibility I think we need to have control over everything, and this means writing the custom controls.

Rewriting the controls will surely be the most code but I think the least troubles in the end. This will be a really good task for the AI powered tools - the scope is well defined, clear specs and validations.

Hynek Cihlar wrote:

Rewriting the controls will surely be the most code but I think the least troubles in the end. This will be a really good task for the AI powered tools - the scope is well defined, clear specs and validations.

I'm pretty sure we could easily automate most of the plumbings for the .NET controls in FWD (types, apis, conversion rules, etc.), this will be the easiest part.

Implementing the rendering and runtime behavior will be much harder, but I think we could to some extent automate this, too. The level of desired automation and how much effort we put into it will depend on how many .NET controls will be needed to convert and how feature rich they will be, but the following could work nicely I think.

We will create a Java UI mock closely matching the structure of our FWD UI (widgets and events) reusing the key types from p2j.jar. The goal is to allow rendering the outputs and exercise runtime behavior without the heaviness of FWD.

We will create simple test cases in .NET capturing the visual state (screenshots) and the UI state (ui elements positions, colors, fonts, etc.) for every test case.

We will create an agentic loop that will be fed with the individual test cases, the screenshots and the UI states. The agentic loop will give us 60-80% working mock UI.

The final mock UI will be then restructured into the final FWD widgets form. Since the mock UI will be similar in structure, this will be relatively simple task.

Rewriting the controls will surely be the most code but I think the least troubles in the end.

I would add "the least re-usability" :) While Progress has its own limited set of controls we support, we can still spot OCX that are quite complex and require manual rewrites. Unfortunately, we can't reuse any of that. I mean, the TREE and HTML browsers are now native to FWD and are reusable to stub OCX that do tree or HTML logic, but I am afraid of the long list of widgets, properties and methods just of Infragistics vendor. Of course, not all are used by a customer.

This will be a really good task for the AI powered tools - the scope is well defined, clear specs and validations.

AI could generate all these based on docs and guardrails - and I would be very glad to see it do that. In fact, it would be strategically huge if we would have an agent that can integrate arbitrary OCX / .NET widgets to FWD Web UI. But at the same time, we need this agent to take care of maintenance and testing as well. I think this is manageable.

The is also a blind-spot here:

• Even if we have the controls, we would need to route the C# code (that might be source of binary) back to FWD, right? Do we stub the infragistics dll with our own fwd-infragistics dll that will route the operations into the FWD run-time? This is the case when the UI library is used from within C# code and not directly in Progress. Maybe a customer has a wrapper on top of this library, like it simply has a "requestAuth" method that will implicitly open a WindowForm for user/pass somewhere nested in the code. The 4GL code doesn't even know that.
• Or do we know before-hand that the legacy 4GL code uses vanilla infragistics and we can transpile that as we do with OCX?

I was not planning to use any Infragistics or .NET binaries from any replacement controls. The idea is to implement those controls fully in Java/FWD the same way that we do it with replacements for OCX controls.

The key question is to what degree we can avoid replacing the larger set of Windows Forms classes. Can we focus on some critical controls like we would with an OCX?

Greg Shah wrote:

I was not planning to use any Infragistics or .NET binaries from any replacement controls. The idea is to implement those controls fully in Java/FWD the same way that we do it with replacements for OCX controls.

The key question is to what degree we can avoid replacing the larger set of Windows Forms classes. Can we focus on some critical controls like we would with an OCX?

Another question is the resulting runtime behavior. There will be similar elemental controls used in the legacy UI and Windows Forms (radios, combo boxes, etc.). If we find different runtime behaviors, is it OK to just assume the legacy behavior?

My last note is in regard to #11284. "NET Windows Form usage" can happen from within 4GL code or C# code. The link in #11283-1 is a clear example of its usage in C# (source).

The idea is to implement those controls fully in Java/FWD the same way that we do it with replacements for OCX controls.

OCX controls are used directly in 4GL code - they are loaded as COM-HANDLE and integrate in a well scoped manner.

Progress.Windows.Form OO classes are also well scoped and we have access to its use from 4GL code. If that is the case, I am completely OK with Hynek's idea.

My original understanding of #11283-1 is that the customer may have .NET Windows Form from within its .NET code. If that is a binary, we wouldn't even know that somewhere in the backstage some Windows API actions are happening and controls are rendered. I may have misunderstood, but this should be clarified with the customer if it is in the scope.

The key question is to what degree we can avoid replacing the larger set of Windows Forms classes. Can we focus on some critical controls like we would with an OCX?

I understand. The usage of .NET widgets is in a OO style (e.g. rOKButton = NEW UltraButton( ).). This is new to us, regarding the native 4GL widgets and OCX that are defined in a procedural fashion.

Idea 3¶

Can we focus on some critical controls like we would with an OCX?

Add wrappers¶

• this would not map exactly, but will work at some extent - at least to get a POC.
• The client won't change and will render simple buttons + will capture the right events.
• If we really need on-par compatibility, we can extend these wrappers so we would have (UltraButton that extends FWDButton).

In infragistics it is documented as:

The UltraButton is a standard windows button control and may be clicked using the mouse or keyboard (using the SPACE or ENTER keys).

It also has some extra-features:

The UltraButton has much of the same functionality as the inbox Button control with some additional features including the ability to fire the click event repeatedly while the button is pressed (AutoRepeat) and the ability to be displayed with non-rectangular shapes (ShapeImage). The default appearance of the button can be modified using the Appearance property. The HotTrackAppearance can be used to adjust the appearance of the button when the mouse is positioned over the button when ControlBase.UseHotTracking is set to true. The UltraButtonBase.PressedAppearance affects the appearance of the button when the button is pressed.

But if you mention "focus on critical controls", then we can be OK with having this out-of-scope initially.

Implement new controls¶

For UltraGrid, there is no evident wrapper. If this is critical, then we need to implement it. I guess we can take the "tree" path of having a native widget in FWD that will be wrapped with OO:

DEFINE GRID hGrid

with wrapper as:

grid = new Grid().

that will be transpiled from

grid = new UltraGrid().

What if we want to actually get more functionality on top of wrappers?¶

This is a problematic aspect. If we need to be on par with UltraButton, then our Button wrapper won't be enough. I would imagine that a sub-class UltraButton shall be implemented to extend server-side support, but what about client-side (reactive and drawing).

The customer reports that their entire UI is based on the .NET GUI. This means that we would need to implement more than just "critical controls" and that all of it will require compatibility.

We could consider reworking the widget hierarchy to implement a set of more generic base classes that map to WIN32 equivalents. For example, a button class that would implement the base features for both the 4GL button widget and the for the replacement UltraButton. Then these subclasses specialize the button to implement the specific differences.

The problem with that idea is that it doesn't consider ChUI and the fact that our implementation needs to support ChUI and GUI in a clean way.

Hynek: In regard to your idea from #11283-8, what do you estimate it would take to do a POC for implementing the UltraButton? Assume it would just be that button in a 4GL frame that otherwise has 4GL UI stuff.

Greg Shah wrote:

Hynek: In regard to your idea from #11283-8, what do you estimate it would take to do a POC for implementing the UltraButton? Assume it would just be that button in a 4GL frame that otherwise has 4GL UI stuff.

There will be some scaffolding needed. But I don't think it should take longer than about 5 days to have a working UltraButton and the dev workflow around it.

We could consider reworking the widget hierarchy to implement a set of more generic base classes that map to WIN32 equivalents. For example, a button class that would implement the base features for both the 4GL button widget and the for the replacement UltraButton. Then these subclasses specialize the button to implement the specific differences.

I do not suggest reworking the widget hierarchy. I was suggesting having new OO classes (as skeleton does) as fwd.oo.gui.Button that will be internally implemented as wrappers over the Win32 Button. The point is to allow OO integration of what we implemented for DEFINE/CREATE statements. Nothing will be changed internally; I only think to decorators.

Exposing the new .NET UI classes directly to 4GL OO code makes sense. The conversion would then be quite direct.

Hynek Cihlar wrote:

Greg Shah wrote:

Hynek: In regard to your idea from #11283-8, what do you estimate it would take to do a POC for implementing the UltraButton? Assume it would just be that button in a 4GL frame that otherwise has 4GL UI stuff.

There will be some scaffolding needed. But I don't think it should take longer than about 5 days to have a working UltraButton and the dev workflow around it.

I would expect it to take longer, but if you can really do it in 5 days I'll be very impressed. We need to move ahead with this for 3 reasons:

1. It will validate the suggested development process.
2. It will inform our estimates for the larger work.
3. It will prove the concept works from a technical perspective (for us and also for the customer).

Hynek: Let me know how you think this can fit in to your current workload.

Greg Shah wrote:

Hynek: Let me know how you think this can fit in to your current workload.

Since Lyra is moving into a maintenance mode I should be able to handle this together with my other assignments.

Some more thoughts.

The .NET UI is a completely different beast from the legacy UI. It's fundamentally different programming model bolted onto the same language runtime. The controls are different, the interaction paradigm is different, the data binding model is different, and the way the app logic is structured around the UI is different. Almost nothing carries over conceptually except that both ultimately show data on screen and let users interact with it.

Functionally, the overlap between the two is minimal. Legacy 4GL UI is declarative, frame-based, blocking, and coupled to the database transaction model. .NET UI is imperative, object-based, event-driven, and completely decoupled from ABL's data and transaction layers.

The programming model goes from declarative to imperative. You can't wrap an object-based, manually-constructed control hierarchy in a frame-based abstraction without making the abstraction so complex it becomes hard to use or maintain.

Control flow goes from sequential and blocking to event-driven and non-blocking. Legacy code assumes UPDATE stops the world. .NET code assumes nothing stops, everything happens in handlers.

This leads me to the question. Do we actually want to extend our implementation of the legacy UI to cover the .NET side? I would say a new UI stack makes a better sense considering the above.

Besides, the scope of the work is larger than the controls themselves. We will also need the integration plumbing Progress provides to allow the .NET and the legacy UI coexist, and any runtime support for the specific event handling, data binding, validation, theming, i18n, error handling, etc (albeit to the extent the customer app uses).

Hynek Cihlar wrote:

This leads me to the question. Do we actually want to extend our implementation of the legacy UI to cover the .NET side? I would say a new UI stack makes a better sense considering the above.

The .NET UI will be a lot richer than the old legacy UI. This calls for a different aproach than what we do now with canvas rendering. Canvas rendering has its limits and with it we won't be able to achieve the same UI UX. The UI will need to live in the browser space.

Having the UI in the browser space opens doors for a plan B. If it turns out the customer uses many different and the complex Infragistics controls we can use the Infragistics controls library for web and map to these controls.

Legacy 4GL UI is declarative, frame-based, blocking, and coupled to the database transaction model. .NET UI is imperative, object-based, event-driven, and completely decoupled from ABL's data and transaction layers.

The programming model goes from declarative to imperative. You can't wrap an object-based, manually-constructed control hierarchy in a frame-based abstraction without making the abstraction so complex it becomes hard to use or maintain.

Control flow goes from sequential and blocking to event-driven and non-blocking. Legacy code assumes UPDATE stops the world. .NET code assumes nothing stops, everything happens in handlers.

Yes, I understand.

This customer has the distinction of having created their entire UI in the .NET GUI. They say they have no legacy UI. BUT, on the other hand they also use OCX controls which might mean they actually do have legacy UI there (but not think about it they way we would). Let's assume that there is some legacy UI but it is minimal. In other customers, we will find the opposite: mostly legacy UI and some .NET GUI (often around menuing/navigation and look-and-feel). We need to support the full range of these scenarios.

I will also point out that they have reported that they use timers to "simulate multithreading". They are still bound by the WAIT-FOR and single-threaded nature of OE.

Having the UI in the browser space opens doors for a plan B. If it turns out the customer uses many different and the complex Infragistics controls we can use the Infragistics controls library for web and map to these controls.

This is an interesting idea. I recall that use of .NET GUI must be on a Windows Form as the container and there are specific ways to integrate that with the legacy 4GL. If we map the Windows Form and .NET controls into a browser-based implementation, we would still need to honor the legacy UI stuff in the same JavaScript session. In other words, the browser-based windows form stuff would be coexist and interact with our canvas based legacy web UI.

The problems to solve:

1. Infragistics will just be part of the widget set, there will be some non-trivial usage of base classes/controls from Windows Forms. We need to support those too, not just because of this first project but because that is going to be a common requirement for other NET GUI users.
2. The Infragistics web controls may not be fully compatible with the .NET versions.
3. Does the customer code call any C# code or binaries that implement direct drawing or UI work (outside of the 4GL code)?

Greg Shah wrote:

Legacy 4GL UI is declarative, frame-based, blocking, and coupled to the database transaction model. .NET UI is imperative, object-based, event-driven, and completely decoupled from ABL's data and transaction layers.

The programming model goes from declarative to imperative. You can't wrap an object-based, manually-constructed control hierarchy in a frame-based abstraction without making the abstraction so complex it becomes hard to use or maintain.

Control flow goes from sequential and blocking to event-driven and non-blocking. Legacy code assumes UPDATE stops the world. .NET code assumes nothing stops, everything happens in handlers.

Yes, I understand.

This customer has the distinction of having created their entire UI in the .NET GUI. They say they have no legacy UI. BUT, on the other hand they also use OCX controls which might mean they actually do have legacy UI there (but not think about it they way we would). Let's assume that there is some legacy UI but it is minimal. In other customers, we will find the opposite: mostly legacy UI and some .NET GUI (often around menuing/navigation and look-and-feel). We need to support the full range of these scenarios.

I will also point out that they have reported that they use timers to "simulate multithreading". They are still bound by the WAIT-FOR and single-threaded nature of OE.

The new UI stack would still need to cooperate with the legacy UI, the same way OE does it. That is the event queues would have to be interconnected and you would still be able to show the .NET UI in CONTROL-FRAME. We would use the same iframe mechanism as we do now for OCX controls.

Greg Shah wrote:

This is an interesting idea. I recall that use of .NET GUI must be on a Windows Form as the container and there are specific ways to integrate that with the legacy 4GL. If we map the Windows Form and .NET controls into a browser-based implementation, we would still need to honor the legacy UI stuff in the same JavaScript session. In other words, the browser-based windows form stuff would be coexist and interact with our canvas based legacy web UI.

Yes, see my previous post.

The problems to solve:

1. Infragistics will just be part of the widget set, there will be some non-trivial usage of base classes/controls from Windows Forms. We need to support those too, not just because of this first project but because that is going to be a common requirement for other NET GUI users.

Yes. But implementing the common controls will be much easier part than implementing the AAA controls like the ultra grid.

1. The Infragistics web controls may not be fully compatible with the .NET versions.

Yes, we would adjust them if needed.

The programming model goes from declarative to imperative. You can't wrap an object-based, manually-constructed control hierarchy in a frame-based abstraction without making the abstraction so complex it becomes hard to use or maintain.

I am aware of the declarative part that is very visible in ChUI for instance, with frames, DOWN, UPDATE, ENABLE, WAIT-FOR and these statements that scaffold a screen and allow you to be declarative about it.
But from the ADM2 heavy usage I saw in some customer applications (with AppBuilder mostly), I can say that FWD already faced very dynamic behavior. Or, the "emulated browse through a grid of fill-ins" widget per-se is a very good example of a dynamic widget that if far from "declarative", but very imperative at its end.

Also, I am a developer that worked scarcely with ChUI, but quite extensively with GUI. My test programs in 4GL are usually very dynamic because of my early Swing knowledge. I really use btn:VISIBLE = true as btb.show() and CREATE BUTTON as new JButton and so on. This was my instinct early on as a Java dev with little to no 4GL knowledge and it still works to this day. Maybe that is why I write crappy UI code in FWD; I should be more retrospective about this ... anyway :)

TL;DR I think that .NET UI code is more like a "everything is a dynamic widget" approach to this subject. This makes them a little more on-part considering the programmatic technique - imperative. That is why I was suggesting on wrappers using handles on-top of MS controls (like 4GL does).

Functionally, the overlap between the two is minimal. Legacy 4GL UI is declarative, frame-based, blocking, and coupled to the database transaction model. .NET UI is imperative, object-based, event-driven, and completely decoupled from ABL's data and transaction layers.

Yet Java is imperative and both GUI and Web drivers are built that way. The blocking, frame-based, blocking behavior is part of the compatibility layer making Java UI not work like Java :) Integrating .NET will allow Java to work like Java. In other words, FWD to its core is imperative, but there are several layers on top that make it 4GL-compatible. I would imagine .Net support would simply bypass that.

This leads me to the question. Do we actually want to extend our implementation of the legacy UI to cover the .NET side? I would say a new UI stack makes a better sense considering the above.

• FWD implementation effort for supporting controls core (Win32 basic functionality including drawing, mouse, keys, etc.) might be regarded as A
• FWD implementation effort to simulate 4GL shenanigans (declarative, blocking, etc.) might be regarded as B

So instead of trying to make the .NET effort named C extend B, what about having parallel implementations so that B and C are unrelated, yet both inherit A.

You are suggesting that, but I think you are pessimistic with A scope. Button, ButtonWidget and ButtonGuiImpl are part of A IMHO (drawing, API, server-client communication, etc.), because they are in fact the low-level Win32 Button. The C# button from Window Forms is 99% IMHO the Win32 button. Maybe it has a bit more extras, but I think that FWD already have that extras (e.g. setting colors) or can extend them easily (support both image and text in button). I can definitely agree that there are new controls that do not map to what FWD has - so be it. In other words, wrappers would make sense for the A part and I agree with you that the B part is unusable in C#.

The Infragistics web controls may not be fully compatible with the .NET versions.

Greg, we really need to understand if the customer does drawing or UI work from within C# code or binaries. This might be really upsetting. If there is a .dll that draws or does something directly through WinAPI (like we have seen at some customers already to manage focus), then it will be really tricky to integrate. For example:

• There are some mouse position capturing, some drawing on top of a component, change colors from WinAPI, etc.
• There might be some Win events that trigger certain actions automatically like clipboard copy/paste or control manipulation (focus next > focus next > copy > focus next > paste).
• Inject an image inside the window to bypass some control limitations.
• The 4GL code sends the WinHANDLE to a dll.

In vanilla 4GL, the programs are well scoped and only some customers employed some WinAPI customization that FWD partially support. But I can imagine that .NET users might go rogue and start doing UI tricks. If they rely on some funky custom drawing ops or control capturing outside 4GL, this may create bigger problems than simply rewritting C# widgets.

The Infragistics web controls may not be fully compatible with the .NET versions.

I also had this POV in #11283-4 (Idea 2) and there is some feedback on the idea.

Alex, I think we are both on the same trajectory with your ABC decomposition. The question is what should be still considered as A and what should be already B.

Your ABC makes sense conceptually, but the codebase doesn't have a clean separation between A (core widget) and B (4GL compatibility). They're fused together. Here is a few points for illustration why I think extending the existing widgets would be harder than building a parallel stack.

AbstractWidget assumes every widget lives in a frame (enclosingFrame()), manages ScreenBuffer state, and participates in 4GL event loops (EDITING, WAIT-FOR). These aren't optional behaviors you can skip.

ButtonGuiImpl reads parent frame's DEFAULT-BUTTON, generates SE_CHOOSE triggers, calls UiUtils.locateFrame(). Click handling and 4GL frame integration are in the same methods.
In FillInGuiImpl ~70% is 4GL-specific: dual-state management (screen value vs real value via ScreenBuffer), Progress format masking (appFormat/appDataPres), SE_ENTRY/SE_LEAVE handling. A .NET TextBox wouldn't need most of this.
BrowseGuiImpl is tied to Progress query objects, ScreenBuffer arrays, ROW-DISPLAY triggers. Not much overlap with UltraGrid's data-source model.

Automatic frame tab-order insertion, specific widget ENTER/LEAVE behavior, frame visibility propagation (setChildrenVisible()), realization checks that block runtime property changes, down-frame iteration, format masking. You'd override so many methods to suppress these behaviors that you'd effectively write a new implementation.

These classes encode decades of 4GL behavioral fixes. The changelogs in FillIn.java and Browse.java have hundreds of entries like "fixed ENTRY event in GUI with fill-in that is not yet visible." Each is a hard-won compatibility fix. Adding "skip if .NET control" conditionals to AbstractWidget or BaseEntity puts every one of those at risk. The testing surface explodes.

On top of all that there is still the UX. Can we deliver a rich and fluent UI with canvas style client/server rendering designed for a generation older and static UI?

So instead of trying to make the .NET effort named C extend B, what about having parallel implementations so that B and C are unrelated, yet both inherit A.

This was my point in #11283-13 that "We could consider reworking the widget hierarchy to implement a set of more generic base classes that map to WIN32 equivalents.".

we really need to understand if the customer does drawing or UI work from within C# code or binaries

You're right. I've added this to the list in #11283-22.

This was my point in #11283-13 that "We could consider reworking the widget hierarchy to implement a set of more generic base classes that map to WIN32 equivalents.".

Understood. Current widget hierarchy is per client type (abstract > ChUI > GUI) instead of (win > progress). If it was the second in the first place, it would make sense to have (win > progress and win > .NET in parallel). Hynek and Greg, I now understand that having (abstract > ChUI > GUI > .NET) hierarchy might be a complete ostrich-camel (i.e. Romanian saying for a confusing anomaly that is half ostrich - half camel). So indeed, reworking was also my option.

In FillInGuiImpl ~70% is 4GL-specific: dual-state management (screen value vs real value via ScreenBuffer), Progress format masking (appFormat/appDataPres), SE_ENTRY/SE_LEAVE handling. A .NET TextBox wouldn't need most of this.

This is because Progress takes control of the native Windows text-box and does some extras (like appFormat). .Net does the same, but with a different flavor. Yet, both rely on the same Windows control they just manipulate to their liking.
The high couple of A and B in FillInGuiImpl is something painful here, I agree.

BrowseGuiImpl is tied to Progress query objects, ScreenBuffer arrays, ROW-DISPLAY triggers. Not much overlap with UltraGrid's data-source model.

This is something I did not want to bring to discussion. I think browse and UltaGrid might not be compatible at all. In fact, is the browse a native Windows widget controlled by 4GL or is it built from scratch (i.e. CreateWindow)? If it is from scratch, it would make sense not to recycle it.

The new UI stack would still need to cooperate with the legacy UI, the same way OE does it. That is the event queues would have to be interconnected and you would still be able to show the .NET UI in CONTROL-FRAME.

Would this new UI stack have the win > infragistics hierarchy? This way we can achieve the dream of having the win controls alone, while also allowing us to add new widgets along the way. If we ever consider refactoring the 4GL widget tree, we can eventually move widgets one by one on the new UI stack (e.g. make FillInGuiImpl extent WindowsTextBox)?

We would use the same iframe mechanism as we do now for OCX controls.

So .NET controls will be rendered in iframes?

Alexandru Lungu wrote:

So .NET controls will be rendered in iframes?

Yes, not in canvas but in DOM. There are potential advantages to that. Better UX and the possibility to employ the Infragistics web framework.

Previously I mentioned it would be impossible to provide good UX using the canvas rendering approach, but I think moving some of the rendering and user interaction to JS could address this. The result would be still purely canvas rendering, but now with half in Java and half in JS.

Previously I mentioned it would be impossible to provide good UX using the canvas rendering approach, but I think moving some of the rendering and user interaction to JS could address this.

Completely agreed! I mentioned previously that UltraGrid for instance has a React component (and for other main-stream UI frameworks). Maybe this can be unified within a "ReactComponentIframe", so we can employ a certain level of integration (e.g. properties of React be mapped way back to converted-code attributes). Of course, this needs some research whether UltraGrid is actually that similar or not.

The result would be still purely canvas rendering, but now with half in Java and half in JS.

Neat!

In regard to the widget hierarchy rework, I think we might be well served to extract the WIN32 control behavior into its own class hierachy that is separate from the existing 4GL widget hierarchy. The existing GUI widgets can contain an instance (instead of inheriting from that control) of the matching WIN32 control and delegate processing to it.

That would enable us to solve the WIN32 behavior in one place for both 4GL and .NET controls.

In regard to the widget hierarchy rework, I think we might be well served to extract the WIN32 control behavior into its own class hierachy that is separate from the existing 4GL widget hierarchy. The existing GUI widgets can contain an instance (instead of inheriting from that control) of the matching WIN32 control and delegate processing to it.

Absolutely!