Is it possible to run the new GUI on repository based frameworks/tools like Dynamics and DWP?
I mean, it can be done dynamically right? Just checking...
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
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?
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)
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
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.
RUN initializeobject IN h.
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.....