This content has been marked as final. Show 4 replies
Can you please clarify the use case? It sounds like you are trying to add a custom VueAction (modifying autovue.properties to append new JAR in autovue.classpath entry?) to extends AutoVue's functionality? Please confirm if it is the case.
We have a need to override certain VueBean/JVue method calls to meet our document handling(documents need to handle metadata information and hence change the document loading cycle, ie markup loading/XRef resolution is dynamic). Also the invokeAction/invokeSubAction do not allow parameter passing(which we have requirements for certain actions again due to metadata) so we would like to override the invokeAction method to include custom processing(we will encode the action with parameters).
We are already using Custom VueActions for other simpler UI event handling that don't have parameter requirements.
As I said above, these use cases were relayed to the engineering team and senior staff members in early December and we were told that we could proceed with overriding the main class in the autovue.properties file. I have SR(s) opened with a long thread detailing this so I really don't want to go through this again.
A custom VueAction does not seem to work because it binds to late in the object call/event stream.
Any update from you on this issue?
Sorry for the late reply.
Currently Desktop Deployment ActiveX does not allow accessing VueBean APIs and the ActiveX APIs are not as extensive as the VueBean APIs (e.g. There's no functions to obtain list of XREFs or Markups). The only way to access VueBean APIs in the ActiveX is to implement a custom VueAction. I am not in the conversation about the main class overriding with autovue.properties, could you please provide me the SR# that contains the details?
Is it a hard requirement to integrate AutoVue with your application through ActiveX technology? Or if Java applet would be an alternative?