.NET Integration in 10.x

GregTomkins

Active Member
I don't have and can't easily get 10.x on my PC here and I was hoping you v10 gurus could answer a few questions about the new .NET integration stuff;

I understand this means I can directly use .NET classes from within P4GL. Is that correct? If so:

1. Can I extend (inherit from) a C# class within P4GL the way you can extend a C# class in VB? If so, can you extend a P4GL class from within C#?

2. Is it limited to the GUI stuff or could I, for example, use the System.IO or System.XML classes from inside P4GL?

3. Do you need anything similar to P4GL wrappers like we used to need in v9 with ActiveX's?

4. I assume you still need to deploy the CLR and PSC runtime, eg. Progress is still reliant on the CLR when running .NET classes and its own runtime otherwise?

5. What are the major, in your view, limitations and problems?

Any input appreciated!
 
You can use most of .Net UI classes ABL.

1. You can extent .Net UI forms classes, with the rest of .Net classes not officially supoprted. You would need to try the class in question and see if it does work for you.
You can't write ABL class and use it in visual studio, at least not directly. You can run progress classes and procedures on App server thru a Proxy.

2. It is limited to GUI. Well, in most of the cases.

3. No, everything is built inside Progress using Progress OO.

4. Yes, you will have .r's and dll's together to deploy.

5. This is very hard discussion that could last forever with every participant having their own opinion about it. In my opinion, .Net UI from Progress is a major step for ABL, I really like that we finally have some modern stuff to work with. If you are a Progress shop you should look into .Net UI as soon as possible. I am sure that Progress will expand the language and support for .Net in future versions.

And you should check out sessions about .Net UI at progress exchange - they have lots of demos about this stuff.
 
Thanks for the awesome response! Very interesting.

My opinion is that no matter how good it is, I would never write a new Win32 app in P4GL, and probably not in anything other than C#. Actually, I wouldn't write it a Win32 app to begin with; GMail has convinced me that a good browser-based client is possible.

Given our mountain of legacy P4GL code, however, it's a different story; we'll be living with a P4GL Win32 Client for the rest of my lifetime, that's for sure ;)
 
My opinion is that no matter how good it is, I would never write a new Win32 app in P4GL
Not that I disagree, but lots of people have different thoughts about it.

, and probably not in anything other than C#
There are many technologies to choose from. Especially with .Net where you have 2 equal languages - vb.net and c#.

GMail has convinced me that a good browser-based client is possible.
You can achieve the same using WebSpeed.

Given our mountain of legacy P4GL code, however, it's a different story; we'll be living with a P4GL Win32 Client for the rest of my lifetime, that's for sure ;)
Using new .Net UI you can slowly move your old code to a new level. It allows you to mix new win forms and old .w's within the same session.
 
Of course WinForms are already passe (and I assume P4GL is way behind that curve)... all the cool kids are using WPF. (Or at least talking about it - another thing like teenage sex - you know, everyone is talking about WPF, but hardly anyone is actually doing it).
 
To clarify a couple of points.

The big limitation with the use of .NET classes in 10.2A seems to be classes with generics. This will be fixed by 10.2B.

You can use non-UI classes, but the terms of the license specify that the context must be UI. I.e., you can use them in the client, but are not allowed by license to use them on the server, even if they would work.

There is a lot of material on PSDN on this and I would get yourself over to register for the on-line Exchange ... still one more day, but all the presentations are there and can be played for 90 days. Check out Shelly Chase's talk on day 1 first thing in the morning for the basics. Suffice it to say that it is a very well done piece of work.

I have wondered myself how many people will use it. If one currently has an ABL GUI client, it is a stunning way to enhance the appearance of that client, especially since you can do it stepwise, embedding ABL GUI screens in WinForms containers so that you can polish up key screens and wait to get around to the routine maintenance stuff.

Like you, I have had a bias toward browser clients, but it looks like there are quite a few people who are going the route of using the ABL GUI for .NET with WebClient. That way, all development is in ABL, but they don't have to do continuous installs on all the clients. But, you should also check out Ken Wilner's talk RIA in perspective for a discussion on all the different client types these days and how PSC sees them. The biggest problem right now is the lack of any dominant leaders, so who do you back?

There seems to be a fairly high likelihood that PSC will get behind WPF and Silverlight because it leverages on what they have done already. They are looking at Flex, but I think Silverlight has more mind share. Prior to release 3, which is very new, it wasn't really ready for prime time business apps, but it might be now. But, it isn't clear that there is any real demonstration of that yet.

10.2B also includes serialization of ProDataSets to JSON, which is a nice boost to Ajax, but the Ajax world is full of a dizzying number of frameworks so it is hard to know what to do.
 
Just a clarification -- the "can only use classes in UI" restriction applies to the Infragistics Ultra controls. Other controls may have different restrictions (if any).
 
it is a stunning way to enhance the appearance of that client

I know this sounds crazy but I think our Win32 client is already fairly awesome looking, and I really have a hard time believing using .NET controls would make it noticeably better.

the Ajax world is full of a dizzying number of frameworks

That's an understatement ;)
 
you know, everyone is talking about WPF, but hardly anyone is actually doing it

Well actually we are moving to a wpf front end. We hope to have finished the project in the beginning of 2010.

Casper.
 
Back
Top