I'm having trouble getting non-graphical .NET assemblies to work under AcuToWeb. CREATE statements that return a handle under normal circumstances return no handle under AcuToWeb. In fact, they seem to be ignored altogether, because changing the namespace to something non-existent, which would normally cause an error, has no effect.
The syntax I'm using to create the control is:
NAMESPACE IS "My.Test.Namespace"
CLASS-NAME IS "MyClass"
HANDLE IS MY-NONGUI-HANDLE.
I've also tried using the AcuToNet.dll interface, but got the CoCreate Instance Failed error.
As I understand it, instantiating non-graphical .NET assemblies with CREATE is supported, so is there something I need to do differently to get it to work under AcuToWeb?
I managed to instantiate a COM object in AcuToWeb by adding SERVER-NAME to the CREATE statement, but I've had no luck with the .NET assembly. I tried adding FILE-PATH to the CREATE statement (though the DLL is in the same directory as the runtime anyway), but it didn't help.
About the COM object: Though I'm able to create an Excel application and generate a worksheet, trying to make the application visible doesn't seem to work. Is that a limitation of AcuToWeb?
It occurs to me that using SERVER-NAME is probably not the way to go, because Excel needs to run on the client. I tried it because using 'SERVER-NAME is "Local:127.0.0.1"' was the only way I could get the CREATE statement to return a handle. I'm testing all this on one machine, so the distinction between what happens on the client and what happens on the server is sometimes lost on me.
I've tested this use of Excel under Thin Client (without the use of SERVER-NAME) and it works. Could the failure to return a handle to a COM object under AcuToWeb be related to the .NET issue?