Application can’t Shut Down – Unknown script Running.

[vithaljoshi]

Hi,

I get the following message when we shut down XMetal.

The application can't shut itself down completely because an unknown script is still running. Please shut down the application by using the Task Manager.

I am using a 5.5 Essential version. This does not happen everytime. The file opened closes intermittently and when we close the XMetal we get the above error.  The xmetal55.exe is running and the services that accesses this is closed.

I am still trying to figure out the reason. If anyone can give me a quick reason that will be great !!

Reply

[vithaljoshi]

We get the following error too, sometimes on shutdown:

XMetaL 5.5 has encountered a problem and needs to close.  We are sorry for the inconvenience.

On clicking debug the following message appears:
Unhandled exception in xmetal55.exe (OLEAUT32.DLL): 0xC0000005: Access Violation.
I fear both the problems are related to each other.

Reply

[Derek Read]

This issue is very likely intimately related to the customization you are loading for the documents in question. I would recommend attempting to debug any scripts that are loaded as a first step. Scripts that may be loaded will be in the following files (where < and > indicate variable values as described):

macrosxmetal.mcr
macrosmacros.mcr
macros.mcr
startup*.mcr.mcr.ctm
Rules.ctm

Or in the MCR or CTM file contained within the XAC file being loaded.

In most cases these types of errors will arise when you instantiate an ActiveX control and then fail to force it to “null” at the first possible logical point in your scripts or during XMetaL Author shutdown (in JScript you set the variable originally declared =null, in VBScript you set it =nothing.

In theory the Windows Script Host (the engine that drives JScript and VBScript) is supposed to do regular cleanup of these types of things (garbage collection). In actual practice the timing of this cleanup may not occur before a user attempts to shut down XMetaL Author, or it just might not be possible for the engine to know what to do. In either case any outstanding references to such objects are detected by XMetaL Author (it asks the scripting engine if stuff is still going on or not and basically just gets a yes or no reply and decides if it can shut down or not, hence the message). This may occur all the time for some users, or it may never occur, or it may appear to be random (this is the nature of the automatic cleanup being done by the particular engine, which might also be PerlScript, Python or anything else for which you have an engine installed).

Unfortunately, in my experience, it is often the case that unless you are conscious of this and write your code to always cleanup these things when they are no longer needed they are hard to detect later (in a project of any significant size) due to that strange quirk of Murphy's Law where bugs in script will tend to happen only after deployment when users (authors) are using your scripts and that they often tend to stay hidden for developers. So, first off, my recommendation is to hunt down every declaration of any ActiveX object in any of the files above and make sure your code also forcefully cleans them up.

Reply

[vithaljoshi]

Well , i had an embedded ocx in an XFT form , could not set the object as null in the XFT form though , so set the XFT form as null instead. This worked !!

It was never a problem with the lower version of XMetal , seems like XMetal 5.5 does a lot of good stuff in the background !!

I have also not received this error till now:
XMetaL 5.5 has encountered a problem and needs to close.  We are sorry for the inconvenience.

Was this error also due to the same reason? I just hope this does not come again !!

Reply

[Derek Read]

It is impossible to tell what might have caused the error “XMetaL 5.5 has encountered a problem and needs to close…” without seeing all of your code.

We obviously try to capture any exception that might cause the application to crash (standard programming practices). However, in some cases it is still possible to specifically program a script to crash, throw errors, or put the application into an endless loop, call 3rd party software that itself makes Windows instable, etc (these are things you must specifically avoid doing yourself).

In some cases if a client attempts to script something nobody else has done before (the product is very flexible as you have no doubt found), that might  expose an unanticipated limitation. In this case (if you really feel it is a bug with XMetaL) it would be best to submit your customization to XMetaL Support to see if they can reproduce the issue and log a defect report with development if necessary. XMetaL Support does not debug customizations for clients, so ideally if you can create a simple test case with as few lines of code as possible explaining exactly what your could is trying to do that would be best. In some cases it is possible to rewrite scripts to accomplish the same goal while avoiding a newly found issue.

Reply

[Author]

Posts