Using the Advanced GUI to create cool new interfaces for our 4GL/ABL applications is very helpful for us. However, we are wondering if you can use Progress.Windows.Form and other methods to display ABL forms in a Visual Basic/C# application. Below doesn't work, but just put in to get my meaning.
Dim hProgress As Progress.Windows.Form
Dim hProForm As Progress.Windows.IForm = Nothing
Dim hProHandle As Progress.ClrBridge.ProHandle
hProgress = New Progress.Windows.Form()
hProHandle = New Progress.ClrBridge.ProHandle
hProForm = New Progress.Windows.Form
hProForm.ProWinHandle = hProHandle
hProgress.Container.Add(hProForm)
NO, that won't ever be possible. You may be able to run your VB.NET application in a progress runtime (as if it were a control) but you won't (probably ever) be able to do what you want. That would require ABL to be a .NET programming language compiled to .NET objects, while it's an independent language that happens to have a bridge to .NET.
I was actually thinking of the bridge going both ways to implement this. If VB.NET could call the bridge to start an ABL form and pass the events back and forth. It wouldn't have to be Progress.Windows.Form, but something that would start a session. It should be that hard, right:)
What's the use case for going in reverse?
If you have an AVM already running, why isn't it in charge?
If you only have a CLR running, why would you expect it to know how to start an AVM?
Hi Don,
The bridge is purposed for communication from the ABL. The only avenue back through the bridge is for .NET event callbacks. If you want to use ABL code from .NET, "Open Client for .NET" is the correct product.
From a technical perspective it is mainly that the threading and eventing models are extremely different in the CLR and the AVM. The way the bridge works now, we have control of the interaction which queues up event callback requests when necessary. Doing this the other way would not be trivial.
-Shelley
I understand the difficulty. But to explain Tom's why...
We currently have many applications in our suite using various frameworks and languages; VB, VC#, VC++, Progress 4GL, and more. There are places where one application wants to display the information from another application. It is easy for the Progress application to display some of the Visual Studio forms because they can be represented by ActiveX and now .NET. However, the other teams and applications can't reuse the Progress application's forms. If they want to bring up the ABL forms, we have to have a session in memory and call the forms via not so elegant methods. Yes we could use Open Client (which we do and have been doing for many years), but at a minimum it requires a 4GL form, VS form, Proxy DLL, and AppServer calls. Then if you remove the AppServer (some installs are client/server), you no longer have the Open Client.
Sounds like a confusing environment!
I can see the urge to re-use, but wouldn't the more natural thing be to either use the Open Client or straight SQL to get the data?
Either that, or use the 10.2A technology to make the Progress app the master.
If you only have a CLR running, why would you expect
it to know how to start an AVM?
In a similar fashion that a JVM knows how to control (start, stop, launch .p) an AVM. Look at your favorite IDE for a sample.
But I doubt that's a suitable approach for a business application used by users and not by geeks. The issues with the network communication between the two processes (and one of them is single threaded) are hardly tolleratable by "normal" users.
NO, that won't ever be possible. You may be able to
run your VB.NET application in a progress runtime (as
if it were a control) but you won't (probably ever)
No need to make it a control. You should be able to run the whole app from within the PVN when you compile is into a dll assembly rather then an exe file.