Progress upgrade policy for 3rd party products?

Based on the pattern with other things, e.g., Eclipse, I would expect the version they supplied to be supported, but for there to be information available on whether newer versions might work or not, but no actual PSC support on those newer versions until there is a shift in what PSC is supplying.

We are currently moving our application from ADM1 to DWP. At this point we use the DWP Progress renderer but in the near future want to move to a Microsoft .NET client.

I am trying to get e feeling about the amount of "freedom" I would have if I choose the DWP .NET renderer (no Advanced GUI but full .NET capability) or a (to be developed) DWP Advanced GUI renderer.

For the .NET client, I would guess it didn't matter ... observe the proper protocol and the AppServer won't have any idea what you have deployed. Of course, that is said independent of DWP since I don't know what kind of issues that has.

I am trying to get e feeling about the amount of

"freedom" I would have if I choose the DWP .NET

renderer (no Advanced GUI but full .NET capability)

or a (to be developed) DWP Advanced GUI renderer.

Can you define the "freedom" you are seeking for? My understanding of DWP is, that their renderer is closed source. That makes you very dependent from the "freedom" they offer you. I guess you need to discuss DWPs roadmap with the vendor.

Can you define the "freedom" you are seeking for? My

understanding of DWP is, that their renderer is

closed source. That makes you very dependent from the

"freedom" they offer you. I guess you need to discuss

DWPs roadmap with the vendor.

True, the DWP source is closed source. If the vendor would develop an Advanced GUI renderer I presume that would be closed source as well. But we don't want to develop our own .NET renderer. Of course there is the issue of "client code" that we have to deal with (*) but we will try to minimize this as much as possible.

(*) with Advanced GUI you can write your client code in ABL?

And yes, the "freedom" is relative because we are dependant on the vendors development of the renderers. If the vendor will only use plain basic Microsoft controls we are stuck on a "Microsoft .NET Progress look-a-like user interface".

But we could still influence development. And I am trying to get a feeling of the possibilities and limitations of a non-Progress .NET client (using the latest .NET 3.5 SP1) and a Progress .NET client (Advanced GUI).

I think the Advanced GUI is not compatible with all .NET controls. And you cannot use WPF controls. And...???

(*) with Advanced GUI you can write your client code

in ABL?

Yes - that's what it's all about. Being able to write client code in ABL and not requiring a Visual Studio at all / requiring you to learn a new language - and keep up to date with it.

But we could still influence development. And I am

trying to get a feeling of the possibilities and

limitations of a non-Progress .NET client (using the

latest .NET 3.5 SP1) and a Progress .NET client

(Advanced GUI).

The biggest challenge will probably be to write client code in a different language than server code (C#/VB.NET vs. ABL) and to go full OO.

I think the Advanced GUI is not compatible with all

.NET controls. And you cannot use WPF controls.

And...???

WPF is still a very young technology. I believe it has been a good choice for Progress to wait and see in which direction it will evelop. Still most .NET developers in Visual Studio seem to be starting with Windows Forms Controls rather than WPF Controls.

There have been some issues with some controls that occured during the beta - but isn't that what beta testing is all about? The goal at least is to support any control by any vendor. Some language limitations (the missing support for generics has been discussed here) in the 10.2A ABL might make it difficult to use all features of all controls. But that's AFAIK that's somewhere on the roadmap of PSC.

Anyway - when looking at a framework like DWP you will probably decide to stick with the control set used by the framework vendor. Mixing control sets in a single application might cause significant inconsistencies in the user interface. Nobody will like to see that.

(*) with Advanced GUI you can write your client

code

in ABL?

Yes - that's what it's all about. Being able to write

client code in ABL and not requiring a Visual Studio

at all / requiring you to learn a new language - and

keep up to date with it.

I find that a dangerous claim which shouldn't be made, it's going to cause a lot of disappointment. You do have to learn a new language. The ABL knowledge you need for the Advanced GUI is completely different from the old 4GL and you need a complete new way of thinking.

If you didn't already know a .NET language learning to use the Advanced GUI is just as hard as learning a new language. But with the disadvantage that there are far less ready-to-use examples available online and far less newsgroups and fora to ask questions to.

There are a lot of advantages to the Advanced GUI but getting used to it really is like learning an entirely new language, at least to me.

I find that a dangerous claim which shouldn't be

made, it's going to cause a lot of disappointment.

You do have to learn a new language. The ABL

That's simply not true. You have to know how OO abl works, and then how the .net control model works. No matter what .net language you use, you still have to "learn" the .net model for the component.

knowledge you need for the Advanced GUI is completely

different from the old 4GL and you need a complete

new way of thinking.

If you've been using OO since, oh, 10.1A then you "know" all there is to know about using .net controls in the ABL . What you don't know is the .net_ control_ itself.

If you didn't already know a .NET language learning

to use the Advanced GUI is just as hard as learning a

You must separate the problem into the 2 areas:

OO ABL (a prerequiste for advanced UI)

.net controls

new language. But with the disadvantage that there

are far less ready-to-use examples available online

and far less newsgroups and fora to ask questions to.

There are a lot of advantages to the Advanced GUI but

getting used to it really is like learning an

entirely new language, at least to me.

is it the OO or the control that is causing you problems ? I have problems learning the models for the controls.

I find that a dangerous claim which shouldn't be

made, it's going to cause a lot of disappointment.

You do have to learn a new language. The ABL

That's simply not true. You have to know how OO abl

works, and then how the .net control model works. No

matter what .net language you use, you still have to

"learn" the .net model for the component.

Indeed, but that's the point, it's learning to think in OO that's hard, not learning some syntax.

knowledge you need for the Advanced GUI is

completely

different from the old 4GL and you need a complete

new way of thinking.

If you've been using OO since, oh, 10.1A then you

"know" all there is to know about using .net controls

in the ABL . What you don't know is the .net_

control_ itself.

Indeed, but how many users, not yet coding in another OO language have really used OO in 10.1A? I have not idea really but it would surprise me if there are a lot.

If you didn't already know a .NET language

learning

to use the Advanced GUI is just as hard as learning

a

You must separate the problem into the 2 areas:

OO ABL (a prerequiste for advanced UI)

.net controls

new language. But with the disadvantage that there

are far less ready-to-use examples available

online

and far less newsgroups and fora to ask questions

to.

There are a lot of advantages to the Advanced GUI

but

getting used to it really is like learning an

entirely new language, at least to me.

is it the OO or the control that is causing you

problems ? I have problems learning the models for

the controls.

Both. Well, somewhat, I already have a little bit experience with Java and OO design so I can deal with it, but whenever starting to code in 10.2 beta I have the feeling I no longer really know the language I'm using.

To me the big advantage to .NET in ABL is that you can still use thinks like FOR EACH and the wonderful temp-table, so you get a .NET language on steroids. But it does feel like learning a new language. A new language with a lot of familiar things.

You must separate the problem into the 2 areas:

OO ABL (a prerequiste for advanced UI)

.net controls

Couldn't agree more with this!

OO coding is a new language concept. Not limited to the .NET UI. OO coding can be used in business logic code as well.

OO coding is not required for the Advanced GUI at all. If you just use the Visual Designer to start with it's enough to be able to substitue (in your imagination) a method statement with in internal procedure.

You can still call procedures (.p or internal procedures of persistent procedures) with the event handling.

You don't need to be able to create complex inheritance modells at all.

But error handling, transaction control, record access (tt or db) - the whole flow in a program is still the same. Isn't this what ABL programs are all about? And this all would be completely gone in a .NET client.

When using a migrated framework, it's the responsibility of the vendor to enable reuse of existing client side code and business logic. I've been very successful on this area in Dynamics4.NET and see no reason why other frameworks should not be able to reach the same level of code compability.

Don't forget: The Advanced UI is 100% compatible with procedural code. It's the generated code, that might suggest, that OO is the only supported programming concept.

The .NET Controls are a beast of their own. Yes. But a certain level of opportunities does never come for free. Active X Controls are a beast of their own as well. That can't be a matter of deciding between one environment to use the controls or another. Fameworks can and should hide the complexity. For sure.

You must separate the problem into the 2 areas:

OO ABL (a prerequiste for advanced UI)

.net controls

Couldn't agree more with this!

OO coding is a new language concept. Not limited to

the .NET UI. OO coding can be used in business logic

code as well.

OO coding is not required for the Advanced GUI at

all. If you just use the Visual Designer to start

with it's enough to be able to substitue (in your

imagination) a method statement with in internal

procedure.

You can still call procedures (.p or internal

procedures of persistent procedures) with the event

handling.

You don't need to be able to create complex

inheritance modells at all.

But error handling, transaction control, record

access (tt or db) - the whole flow in a program is

still the same. Isn't this what ABL programs are all

about? And this all would be completely gone in a

.NET client.

That's an extremely good point. But then maybe one should not explicitly state you don't have to learn a new language but rather that:

All you need to do is learn the .NET model without loosing all the advantages of the ABL.

That's an extremely good point. But then maybe one

should not explicitly state you don't have to learn a

new language but rather that:

All you need to do is learn the .NET model without

loosing all the advantages of the ABL.

Not quite - learning the OO parts of the ABL is nothing to do with .NET. However, you do need to know the OO parts to use .NET

OO is a new part of the language. Just like widgets were a new part of the language when Progress v7 came out. Just like persistent procedures when v7.3 came out. Just like Prodatasets in 10.1

The ABL is evolving - with 10.2 you can still use standard widgets and the appbuilder. Just like you can still code in character mode. But in order to use the new .net features, you have to understand how to use OO in the ABL.

Message was edited by:

Julian Lyndon-Smith

That's an extremely good point. But then maybe one

should not explicitly state you don't have to learn a

new language but rather that:

All you need to do is learn the .NET model without

loosing all the advantages of the ABL.

I stay with my point. It's the FOR EACH, FIND, DEFINE QUERY, DO TRANSACTION, ON ERROR UNDO, LEAVE, .... that makes up the ABL as a language.

Not the oButton = NEW System.Windows.Forms.Button () .

The ".NET model" you are refering to is more the handling of .NET Controls. You'd need to learn that anyhow.

If you compare the quality of many posts in this beta forum with many of the post in the Infragistics forum, you'll see that the same "how to achieve this and thatwith the IG controls" style of questions is asked there. It's specific to the Controls - not the language (C# or VB.NET is discussed there the most). So we can expect that to happen on the public PSDN forums as well when 10.2A get's release.

But I don't expect any growth in the number of basic ABL questions (like how to start a transaction in ABL).

Not quite - learning the OO parts of the ABL is

nothing to do with .NET. However, you do need to know

the OO parts to use .NET

But that's really just like a new widget set. You don't need to be able to perform any kind of OO modeling / framework design skills.

OO is a new part of the language. Just like widgets

were a new part of the language when Progress v7 came

out. Just like persistent procedures when v7.2 came

out. Just like Prodatasets in 10.1

Didn't persistent procedures came out later, as in v7.3 or v8.2?

The ABL is evolving - with 10.2 you can still use

Isn't that great...! Not to evolve would be a step backwards. We had that long enough on the UI side of the ABL.

standard widgets and the appbuilder. Just like you

can still code in character mode. But in order to use

the new .net features, you have to understand how

to use OO in the ABL.

Just like some time ago you had to learn, that using UPDATE statements in ABL GUI apps works, but does not work well. It's the integrated WAIT-FOR that causes trouble in multi-window apps with persistent windows...

The ABL gives you the "freedom" (do reuse a term of Simons initial post) to decide when you believe that you are ready to use some of the new features in combination with existing ones. It's not the release cycle of the vendor that forces you to change your code. I like that.

Didn't persistent procedures came out later, as in

v7.3 or v8.2?

ummmm, errrrr,

That's what I said .... ;=)

(after a very quick edit ...)

OO coding is not required for the Advanced GUI at all.

I agree. Common reactions are: I have to OO rewrite my framework / application / backend. All my programmers have to learn OO programming. Etc.

And this is not true at all. I think it is possible to leave a lot of the framework, transaction model, temp-table stuff, business logic constructs intact and replace the front-end by a new Advanced GUI renderer. Like you did with Dynamics. Okay, this is over-simplified because you will have to do a bit more than this but the point is you should not have to rewrite you're complete application or re-educate all your programmers to be OO programmers.

I don't have any OO experience besides the general theory behind OO. And I am probably using the class/methods just like persistent procedures/internal procedures in a very basic way but am quite at ease with Advanced GUI programming. In my experience interfacing with the Infragistics controls is the biggest challenge.

So for us, DWP users, I think there is not that much that will change. Even if the vendor will provide us with a Advanced GUI or rewrite the framework in OO. The only point of concern is the client code. It is a big advantage that it is possible to use ABL instead of C#.