This archive contains four folders:
This contains the RC1 release of ikvm as downloaded from the web. This was used when trying out method pointers, which are no longer needed.
You may be able to use an earlier version of IKVM, but I haven't tested against the earlier versions.
This contains the java source files for the test functionality and are modified versions of those originally supplied.
buildJava.bat does a command line build of the ikvmTest.dll assembly which is used by the COM wrapper (see 3)
JeaCommand.java and JeaResponse.java are unchanged from the originals.
IKVMtest.java no longer refences any cli module, but instead implements callbacks using RunnableDelegate class. The method testCallback now takes a parameter for the RunnableDelegate callback and uses a worker thread to do the work. This prevents the method from blocking the caller.
The callback is called directly from the worker.
Unfortunately, the IKVM implementation of RunnableDelegate creates delegates which are parameterless. Since it is also marked as final, it cannot be sub-classed to overide the invoke method to take a parameter. The issue of passing the callback message has been circumvented by adding an extra method getCallbackMessage which the callback method in the COM component calls on receiving the callback.
worker.java is a new class to perform an asynchronous task - in this case, delay before calling the callback method.
Visual Studio solution containing a COM visible C# assembly to act as the glue between a visual basic 6 app and IKVM. This solution references ikvmtest.dll, and other necessary IKVM assemblies.
A simple VB6 project to exercise the COM wrapper and hence the java functionality. This project is a VB6 equivalent of the VB.Net project originally supplied.
1. The java source has some ugliness regarding IKVMtest passing itself to the worker so the worker can access the text strings. Since this is a POC rather than production quality code, I've left this as is. Hopefully, this sort of stuff will disappear with a fully designed implementation.
2. When VB6 displays a MsgBox, it appears to sink and discard events other than those it wants itself. The events are neither passed on nor resignalled when the MsgBox closes, meaning events raised whilst a MsgBox is open are lost. There are ways to avoid this issue:
a) Implement an acknowledgement mechanism whereby the VB6 event handler calls into the COM wrapper to acknowledge receipt of the event. The COM wrapper will retry raising the event until an acknowledgement is received - current retry interval is 500ms. This may need to be increased if thereis a performance hit. There is a small window of opportunity for events to fire twice if the sleep interval expires at the same time as an acknowledgement is sent. In addition, the event will only be received by VB6 once the blocking MsgBox is closed by the user.
b) Implement a VB6 class to replace MsgBox by calling the Win32 API MessageBox with the appropriate parameters. This works, but requires mltiple changes to existing code. This is the more robust solution, but is also more work due to the number of instances of MsgBox in existing code e.g. DesignBuilder has >500. Full implementation would remove the necessity for a above.
The curent sample projects implement both methods.
3. The sample projects have been implemented on the assumption that there is a single handler for an event. More sophisticated data structures will be necessary to accomodate multiple handlers on a single event and/or multiple events which would each need their own callback message/data.