.Net and Progress Gui

[lloydt]

I'm not sure this is even possible but figured I'd throw it out there...

We have a legacy application, heavily based upon adm2. The idea is being explored to redo the UI, and instead of doing the entire app at once, the goal is to impliment pieces at a time. The solution that is being explored is to embed a web browser in the application, write the new functionality in Asp.net with ajax and utilize the embedded browser to view the page, essentially "overriding" the former functionality.
My preference would be to go the smart client route with this, and as a side expirement I'm researching writing winform user controls in .Net 2, making them Com visible, and attempting to embed them in the app. They need to be embedded because one of the rules is to avoid "popups" with this new functionality.
I've not had much luck implementing .Net com components into the Progress Gui, past results have ended up with them popping up outside of the container that I'm working in in Progress. I don't really care about event handling or any other "hook ups" to the .net control, it will handle everything in and of itself.
So my question to the community is has anyone got any ideas on how to do this or maybe some experience with it?
Using .Net 2.0, Progress 10.1b target environment, Win XP/2003, Terminal Services
Thanks in advance!

 

[tamhas]

If you have the resources, my recommendation would be a transformation to a WUI client as you describe, but if resources are more limited, you should certainly look into the Advanced GUI which is coming in 10.2 in the second half of next year. I know that is a while to wait, but if you are ready to dive in and work on it, there will be technology preview programs starting this summer and a beta which will be sometime next year.

The cool thing about the Advanced GUI option is that you can design a 100% .NET screen with a visual designer quite similar to Visual Studio ... without writing a single line of C# or VB.NET. For that matter, the visual designer writes most of the interface code for you, including the data bindings. This new .NET UI will run in the same session (not the same window) as existing ABL GUI, so you can target key screens which need advanced functionality or that you especially want to be pretty and leave any or all of the rarely used screens as they are or until you get around to it. Look for the INNOV-5 session from Exchange when it gets posted to PSDN.

Now, this is still a heavy client, but you are used to that. So, you still have the issue of needing the Progress install on all the user's PCs, which you would get away from with AJAX and a browser. But, for being able to make a minimal investment in rework and yet getting a big bang, it looks like it can't be beat. There will be a set of fully supported .NET controls come with the product and a set of advanced Infragistics controls, apparently available as an option, which will also be supported. But, any control from any source, even home grown, should be usable in this environment as long as it is well behaved in Visual Studio.

The implementation uses a CLR within the AVM and a bridge between the AVM and CLR which is aware of events and data and moves things back and forth as needed. It will run in any Progress environment with an AVM, including Webclient.

 

[rvkanten]

I've recently downloaded the 10.2ATP software and have done some reading on the Visual Designer.
My manger recently visited a Progress Conference in Brussels and was under the impression that it was possible to transform an existing ABL window to a .Net winform.
I've not read anything yet to support this.
Is it possible to transform/convert an existing ABL to act as a .Net winform by adding some statements? Or must the winform be rebuilt from ground up using the Visual Designer?

 

[Casper]

Although I'm sure it is always (more or less) possible to make code which provides this.
But AFAIK there is no out of the box solution for this.

Casper.

 

[tamhas]

I am not aware of any transform tool. I would be *really* surprised if such a thing existed because the structures are so very different. I am pretty sure it is something you need to build from scratch.

The one exception to this in some sense is that I believe Mike Fechner has been doing work on creating 10.2A .NET screens out of Dynamics, but, of course, that is starting with a data driven screen in the first place.