New GUI and application repository

For Dynamics the answer is absolutely YES !

I haven't heard anything regarding a DWP status here at all. But that does not need to mean anything.

Technically it's not a problem at all. All .NET controls are generated at runtime anyway. There's usually no proprietary byte code or anything like that required to build screens. So pick your repository definition and run a (large) number of NEWs on .NET Controls in a loop and your done... More or less, I guess.

I'm currently working on an addition to the menu loader to grab a standard menu layout and convert it to a UltratooBar menu. At least most of the work will get done automatically

Ok, great!

And can you mix P4GL objects and .NET controls on the same container?

(container itself can be P4GL and .NET?)

So it could be possible to for example replace all P4GL browse objects by "UltraGrid" controls without changing the rest of the application (with the neccessary plumbing of course).

Also there is no need to use OpenEdge Architect in this case right?

Are there any restrictions, known limitations?

Do I need to write any MS .NET code in C# or whatever or can it all be done in 10.2A ABL?

Thanks.

I saw you posted the code in another thread. Maybe I will give it a try. Thanks.

from what I understand, a .net form can host a 4GL window / frame .. at least that what's in my confused and dazed mind

.NET Forms (and other container controls) can hosts ABL windows. But I have the feeling that this feature still requires a lot of testing. I encourage everybody interested in this feature to use the beta the to ensure a reliable product when it get's released. I'm still having a couple of issues with this mix & match on Form level.

OpenEdge Architect is not required at all - it's just a code generator. No more, no less.

I was albe to get rid of all the C# code in Dynamics4.NET and I have replaced it all with ABL code. Especially for dynamic instantiation of Controls/Forms and ABL embedding, I see no reason why you should be required to code somethig in C#.

The main window must be a .NET form?

Just checking because it is likely that the first thing that will be changed is the container, menu etc. and reuse the existing P4GL browsers/viewers.

(although I must say that it is tempting to replace the browsers by grid style objects as well)

BTW

We are using DWP...

It makes sense that way. It improved the first look impression of the application with usually little afford.

Another more important thing should be noted here:

The (one and only) WAIT-FOR statement of the application should be a

WAIT-FOR System.Windows.Forms.Application:Run(mainform).

or similar. This initializes the .NET event loop as the main event loop. Exceptions can be ABL dialog box frames and message box statements since they are modal.

So, can the .net form host a progress frame ? If that is the case, it may be a lot simpler, as all progress windows have a frame ...

I guess embedding complete ABL windows in a .NET form isn't a problem (see below).

But I am not sure if it is possible to replace parts on a ABL window by .NET controls like for example replace the ABL folder with a UltraTabControl and reuse the ABL viewers...

From OpenEdge® Development: Advanced GUI Programming, Using .NET Forms with ABL Windows:

"You can embed the client area of an ABL window that has not yet been realized in a .NET form. This allows all the client area widgets in the window to be displayed in the client area of the .NET form instead of in the ABL window to which they are attached. Using this feature, you can retain much of your existing ABL GUI code as you migrate from a traditional ABL GUI to an OpenEdge GUI for .NET application.

Using a common mechanism, ABL supports two basic ways to embed an ABL window in a .NET form:

Thus, this one feature allows you to migrate an existing ABL GUI to a GUI for .NET in several different ways. You can use it to transform your existing ABL GUI application into a .NET MDI application, migrate each window to a corresponding .NET form, migrate elements of more than one window into a single .NET form, or use a combination of these approaches in migrating your existing application."

yeah, I suspected as much. My main screen is a tabbed window, where the tabs take up all of the window space. Each tab has it's own defined frame.

So it probably would be easy to replace the window with a form, add the new toolbar and tab, and embed the original screen sans the window and activex tab into the new form, with a little code to view the appropriate frame on a tab click.

Probably look really ugly as well

I think what we need to do is have some step-by-step instructions on how to embed a standard app-builder created window (new->window) into a class form. What code needs to be changed, and what properties need to be changed in order to embed this window into a standard visual designer form.

Can you tell I'm struggling ?

I've tried to modify the instructions given in pg 5-12 of the Advanced GUID programming guide to no avail ..

This seems to work:

DEFINE VARIABLE h AS HANDLE NO-UNDO.

RUN mywin.w PERSISTENT SET h.

hwin = h:CURRENT-WINDOW.

/* Create the WindowContainer, embedding the window into it. */

WinContainer = NEW Progress.Windows.WindowContainer( ).

WinContainer:Location = NEW Point( 10, 10 ).

WinContainer:Size = NEW Size( hwin:WIDTH-PIXELS, hwin:HEIGHT-PIXELS ).

WinContainer:EmbeddedWindow = hwin.

WinContainer:Parent = MainForm.

WinContainer:Show( ).

RUN initializeobject IN h.

Hi Simon,

I know that the example code works - what I was trying to do was to see how hard it is to embed an existing window written in the AppBuilder / UIB rather than just the sample code.

For example, you cannot embed a standard .w as it complains that the window is already realized. I was wanting to know what would need altering to make a standard .w embeddable.....

The code above is different from the example code from the documentation...

(in this example an external window mywin.w is used)

See attachments.

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

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

I guess Julian is not neccessarly talking about smart windows, right?

As usually smart windows make the life of a developer really easy. Before running initializeObject you can use the documented methods to embed it before it get's realizer.

For a non smart window, the problem is, that the appbuilder generater code causes the realization of the window (like for loading the icon) before you can insert your first line of code. The only way of embedding non smart windows I have found was, to open the file in the editor and change the generated code. But that of course will cause the appbuilder to treat the file as damaged.

Smart Objects ? What are they ?

joking

Yes, I was talking about standard .w files generated by the appbuilder. Since all of our .w files are created using the Appbuilder (not SO) I was trying to get a handle on the complexity of the changes required to make the code work embedded.

Ah, ok...

You could make the window initially hidden (search & replace).

Move the main-block to an include including the enable_UI (search & replace).

Unhide the window in the main block in the current application.

For the new UI run the enable_UI after the WindowsContainer:PARENT stuff.

That should work... Hopefully...

heh. I'll try that right after I've reinstalled. I broke my infragistics installation somehow and can't drop a grid or combo-box onto the form without getting an exception.

Uninstalling infragistics from the add/remove programs has taken 35 minutes so far ...

...and of course in the new UI application don't run the enable_UI in main block or you will end up with the "Can't embed window - it's already realized" message again.

See attachments.

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

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

Thanks for the example!

Hi Julian,

I think what we need to do is have some step-by-step

instructions on how to embed a standard app-builder

created window (new->window) into a class form. What

code needs to be changed, and what properties need to

be changed in order to embed this window into a

standard visual designer form.

I don't have a step-by-step guide for you, but I can point you at an example. The AutoEdge updates use a main (MDI) form which launches either other .Net UI forms or ABL GUI (ie AppBuilder-built) windows.

The code to do this is in autoedge/dealer/gui/autoedge/mainviewaui.p, in the StartFrame() procedure.

The embedding of the ABL window needs to be done before the window's realised. Window realisation is done by viewing or un-hiding the window, or by calling the LOAD-ICON() method. The AB writes this call almost immediately after the window widget is created. This means that in order to embed such windows, the LOAD-ICON() call must be moved into some code that runs after the main block executes: into an internal procedure or function, such as InitializeObject (for ADM2 windows). I haven't tried putting the call into Enable_UI but that may also work.

-- peter

Thanks - I'll give that a try

AFAIK as I know there are no plans to re-write the DWP screen painter in 10.2

The only short-term benefit is that you re-write the menu program - perhaps making an MDI version where the standard DWP screens run in.

Do you know the reason for not rewriting the screen painter? Just curious...

beats me

IMHO this is a matter of time. As a DWP user I will certainly make my case of moving forward to an Advanced GUI renderer even though this will probably take a longer period of time to realize. That's okay, Q2 2009 will be fine...

I can understand if a supplier want to make money from the current product investment, bugfix/stabilize the current product, add functionality to the current product etc. That can be a good thing as long R&D, future product investment is part of the plan as well. I guess it is still early if you look at 10.2A / Advanced GUI so let's see what happens...

How is the work on Dynamics.NET going?

Really, really well!

Great stuff. And you are going to offer Dynamics4.NET to existing Dynamics customers?

Absolutely. The site http://dynamics4.net will be updated with much more detailed information for FCS of OpenEdge 10.2A, when Dynamics4.NET will be released as well.

I already have one successful 3rd party reference implementation. Actually I'm looking for Dynamics users that participate in the beta program and are interested in evaluating Dynamics4.NET. Interested parties should drop me a note off line.

Are you going as far as replacing for example the ABL browsers by UltraWinGrid controls, the ABL viewers by Ultra* controls etc. or are you reusing those ABL objects in Advanced GUI .NET containers?

Well even though I was one of the biggest requesters for the embedding features simple embedding wouldn't be the big deal, do you agree?

My main focus during the developement was a complete redesign of the rendering engine. I use Infragistics controls for browsers, viewers, trees, menus, toolbars etc.. But rendering is just one aspect of it. Making it prettier was rather simple compared to maintaining the heart and soul. The bigger challenge was the ADM2 which is that heart and soul of a Dynamics application. I've developed ADM2.NET as a rewrite of the ADM2. Being able to talk to strong typed classes and controls instead of Progress widgets.

The result is the fact, that you "just" need to register a different rendering procedure (done using subclassing in the repository) with a set of objects and your container renders to Infragistics/.NET. A few added properties make it possible to control additional .NET features. For instance, instead of my Infragistics based default combo-box you can name a different combo-box class (a sub-class) to achieve combo-boxes with images etc. I'm reusing the Dynamics managers with almost no changes at all. The only bit of Dynamics that I don't use is the resizing process. It makes so much more sense to use .NETs anchoring and docking in combination with real splitter bars etc..

Static components like the login dialog, message dialog and filters have been rewritten using a combination of the Visual Designer and the existing code to maintain compability. All client side logic APIs have been implemented so that existing custom code (client logic procedure) will run in the new rendering engine with no or only little changes.

My ADM2.NET contains no SDO/SBO/DataView code. This non visual SmartObjects are still using the standard ADM2 code. This was a very important design goal for me!

I also support the embedding of Progress windows. The main reason for this is that many Dynamics applications also have some screens that have been developed statically (for Active X support, or just because something seemed to complex within the rendering engine). Embedding ensures the possibility of a step by step migration of these screens.

In this scenario, I am able to dynamically replace the Progress toolbar/menu with an Infragistics toolbar. That alone makes a big difference to the appearance of those screens.

For both types of rendering (.NET and Progress widgets) I support 2 container modes that a developer can pick however he likes it:

Embedded into the MDI container or launched as a separate window (MDI or SDI). And dockable panes – I shouldn’t have forgotten dockable panes…

My personal preference is to have the browser windows (Object controller) in the MDI container and the detail windows (Folder window) as a separate window. This is somehow a little bit like Outlook.

The third possible types of containers in the whole scenario are completely new developed screens. Designed for instance in the Visual Designer. They can be launched from the repository (once registered) and also have access to the well documented Dynamics managers framework.

By the way to make that even more efficient, we are in the process of developing an OO wrapper on top of the Dynamics managers.

That's in /short/ the status. I don’t know how well you know Dynamics – let me know, if you have additional questions.

Migration of Dynamics screens is a matter of minutes when you do it manually or seconds using conversion routines.

Well even though I was one of the biggest requesters

for the embedding features simple embedding wouldn't

be the big deal, do you agree?

We are not using Dynamics but DWP but it is good to hear and reassuring that you have managed to replace the renderer, developed ADM2.NET etc.

Thank you for the explanation.

It's doable. And somebody had to do it. But I'm not sure, if I'd ever do it again