Advanced GUI client code

not sure what you are wanting here ... is it a ABL 10.2 version of the code ?

Is this the dwp framework? If so, I think Mike can answer some of the questions .

Sorry, the code was just an random example of existing DWP client code to illustrate the use of some typical client code like MODIFIED/CHECKED/SENSITIVE, APPLY TO etc. See attachment.

I guess the attributes will be replaced by Infragistics attributes, The IF-THEN-ELSE etc. will remain the same. Things like APPLY TO to interact with the objects will remain the same as well?

[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/client_5F00_code.txt:550:0]

Ah, Ok.

1) attributes will have to be replaced with the .net equivalent

2) All non-UI ABL logical will remain the same

3) APPLY statements (for example) will have to be replaced with the .net equivalent for each control

Generally, all UI statements will need replacing with .net equivalent

Julian

Ok, I understand. Maybe some of you have examples of typical Advanced GUI client code like the one in the previous attachment? Thanks very much!

Mike! Help !

Yeah, really, Mike is the goto man on this one. Not even much point even talking to the rest of us!

Mike, you are hereby nominated to deal with this thread. Do I have a Second ?

Do I have a Second?

You keep handing me such good straight lines ...

Ok guys. Looks like I'm the new DWP expert. Honestly, I've never seen a single line of DWP client code - until now. But I guess I need to get in touch with our graphics designer to get "DWP expert" added to my business card title.

Nobody from Netsetup in this forum? They should be qualified to answer Simon's questions.

I guess you need to look very close at how client code has been developed in the particular framework or how developers not using a framework have been writing their code.

There are not many different ways you can deal with widgets in the ABL UI.

1.) using properties and methods.

There some issues here: Either translate your code, to talk to the Text property or use OO to create something with a SCREEN-VALUE property. Please remember, SCREEN-VALUE is more powerful than just the Text property - so I doubt that it could simply be replaced by :Text in .NET.

Think of MODIFIED (also used in the sample code provided by Simon). A MS TextBox or an UltraTextBox have never heard of a property getting even close to MODIFIED. Think about HIDDEN and VISIBLE... Think of the SCREEN-VALUE of a Check-Box. Nothing similar, with the Text property of a ToggleBox.

I've spend a lot of time to write a compatibility layer that deals with these differences. It's part of Dynamics4.NET. Besides the ability to use these advanced ABL properties, this makes it possible to replace the controls used. I've done this at the beginning of this year, when I substituted the MS Controls with Infragistics Controls and I could do it again if I need to. It required some discussion with Progress to convince them to remove all unnecessary reserved keyword restrictions when writing my own classes. And before you ask: When moving on, I still allow a developer to access the IG Controls directly to get "everything" out of them - if required. I'm also pretty sure, that this compatilibiy layer might be interested outside of Dynamics.

Another issue is the fact, that a HANDLE variable can't "hold" an object reference. No matter if it's .NET or ABL.

In Simon's sample code, the only change required in Dynamics4.NET would be

DEFINE VARIABLE hHoldReas# AS HANDLE NO-UNDO.

DEFINE VARIABLE hHoldText# AS HANDLE NO-UNDO.

to

DEFINE VARIABLE hHoldReas# AS SomeClassInTheCompatibilityLayer NO-UNDO.

DEFINE VARIABLE hHoldText# AS SomeClassInTheCompatibilityLayer NO-UNDO.

I guess, you get the point here.

2.) A framework designed for UI independence should have provided a client logic API. Dynamics has it's client logic API (check the Dynamics documentation for details). And I've reimplemented it.

So a Dynamics developer could have used functions like

assignWidgetValue ("widgetName", "new widgetvalue")

or

widgetValue ("widgetName")

instead of the SCREEN-VALUE property. And he's ready for 10.2A and beyond - .NET or the next generation!

3.) access using statements like ENABLE, DISABLE, DISPLAY and APPLY TO

out of these APPLY TO seems to be the only one widely used in modern apps. No way we can do anything for code compatibility with these statements. You need a pseudo-syntax (using methods or include files or something simlar).

The rest is "simply" taking care that all APIs and methodologies used in the framework, so all connection points between the framework and the client code, keep on working. In the case of Dynamics that would be the ADM2, rendering engines and the managers.

Simon, Julian and whoever might be interested: I'll be presenting Dynamics4.NET during the PUG Challenge in Veldhoven. The amount of client code compatibility achieved will definitively be subject of that presentation.

Sorry for not getting into this thread earlier Julian... I was having dinner and was trying to mentally prepare for our pistol shooting duel tomorrow at dawn...

so what is the line ? We're all waiting ... better be good

so what is the line ? We're all waiting ... better be

good

Good enough?

A suggesting to the European participants of this forum: Why don't we meet for a beer during PUG Challenge and continue this discussion face to face?

so what is the line ? We're all waiting ... better

be

good

Good enough?

A suggesting to the European participants of this

forum: Why don't we meet for a beer during PUG

Challenge and continue this discussion face to face?

When is the challenge ? And do you mean proper beer, not that lager rubbish ?

Will Thomas do the 2.000 today?

The next post will tell ..

Halloween. Check www.pug.nl

But I doubt they serve Kölsch in the Netherlands....

http://www.psdn.com/library/entry.jspa?entryID=6072

Damn, can't make that. Oh well. next year ...

There were several, but none really good in a necessary sort of way.

Consider it a good turn for the Fellowship of the Hyphens.

Ok guys. Looks like I'm the new DWP expert.

Thanks Mike! DWP was just an example. Because in essence the "4GL structure" will remain intact I think it will be possible to auto-replace the current code to Advanced GUI with new constructs that will communicate with the .NET objects through the compat layer as you call it.

Yepp. Always look at the .NET controls as pretty but dumb or stupid. Don't over-estimate their abilities when you are used to Progress widgets (like the good old browse widget)

The rest is "simply" taking care that all APIs and

methodologies used in the framework, so all

connection points between the framework and the

client code, keep on working. In the case of Dynamics

that would be the ADM2, rendering engines and the

managers.

Ok, so for all the leave, entry, value-changed etc. client triggers you had to find equivalent trigger code for the Infragistics controls, adjust your framework code and regenerate the code... (after doing the necesary changes to the trigger code in the repository)

I will probably attend the PUG meeting so maybe we will see each other there...

In Simon's sample code, the only change required in

Dynamics4.NET would be

DEFINE VARIABLE hHoldReas# AS HANDLE NO-UNDO.

DEFINE VARIABLE hHoldText# AS HANDLE NO-UNDO.

to

DEFINE VARIABLE hHoldReas# AS

SomeClassInTheCompatibilityLayer NO-UNDO.

DEFINE VARIABLE hHoldText# AS

SomeClassInTheCompatibilityLayer NO-UNDO.

And how is de link between the actual control (e.g. TextBox) and the DEFINE VAR AS compat layer class being made? So the SCREEN-VALUE knows what Text property to return. You have the NEW() it and send the object als a parameter? Sorry, new to this stuff...