Hello all,
is the Knowledgebase Entry P3096 still correct in that there is no way to create a callback function in OpenEdge ABL for passing it to a DLL?
According to ABL Reference this is still true.
Do you have any suggestions how to provide a solution, other than to lock for a different communication path like Web Services or to write your own C-routine?
Regards,
Stefan
ID: P3096
Title: "Does Progress support callback functions?"
Created: 05/31/2002 Last Modified: 09/13/2002
Status: Verified
Goals:
Does Progress support callback functions?
Fixes:
No, Progress does not support callback functions.
Callback functions need the address in memory of the function that they are going to call and the 4GL has no way to provide the address.
You can simulate a callback function by writing your own C DLL and using it within Progress.
Hallo Stefan,
what's the use case and what's the platform.
On windows you still have Active X (Com Objects, Automation Servers) available. The ABL can handle Com Object events. That's also a form of a call back.
But it probably requires some additional coding in a Microsoft development environment if you have a DLL function available that requires a callback (function pointer). But at least you won't need to build your own Progress executable.
Mike
Hi Mike,
Thanks for the reply. It is windows, TAPI 2.2.
Wrapping is a viable approach.
Thanks. Stefan
OE10 now has an IJW approach to .Net assemblies, including event binding ... may be worth a look to see if it fits into your framework.
Plan B - view all your custom dll's as sync processes, so in your stub dll;
1) call an entry point to initialise the link;
2) call an entry point to read string, which returns 'string' and 'bool' end-of-message flag,
3) process string and report point 2 while 'bool' == false;
The down side to this is that you will not be able to go down a multi-threaded direction, the ABL does not fully support this anyway.
Plan C - as per above post, rewrite your dll into an OCX and raise events rather than callbacks. Same result and the events can be captured by your control container (even with non-UI ABL code).
- Colin
OE10 now has an IJW approach to .Net assemblies,
including event binding ... may be worth a look to
see if it fits into your framework.
Looks like your talking about an OE10 release that has not yet been released
Plan C - as per above post, rewrite your dll into an
OCX and raise events rather than callbacks. Same
result and the events can be captured by your control
container (even with non-UI ABL code).
An automation server will work just the same. No need to involve any (in)visible UI Component to wrap the TAPI interface.
.. OE10 release that has not yet been released ..
Given up the watch on its release, 5+ years in the making
A great set of added functionality, and not just for the UI extensions, but a long time in the release queue.
ActiveX, in both forms, will work well - however beware of the registry/install fun, especially on external client machines which are locked down and may require admin rigths to install the classid links etc.
An advantage of the automation server is that it is external and will thus appear as an individual task under task manager ... which can be helpful with locating run away code during development
An advantage of the automation server
is that it is external and will thus appear as an
individual task under task manager ... which can be
helpful with locating run away code during
development
Hi Colin, I hope it's not too disappoointing to know, that an automation server (stored in a DLL) can run inside the prowin32.exe just like an Active X Control would do. And I bet every developer who every tried, managed to create a run-away instance of a prowin32.exe process easily.
Com-Interop .NET classes are used this way and loaded into the prowin32.exe process.