Script not exiting fully.

[mhall]

Hi All,

I have two scripts with dynamic dialogs. Script1 runs Script2 via the run() command, using command line arguments to control it.

One of the command line arguments is intended to control whether or not Script2 will exit when its work is finished.

Script2 is a small email script. The send action is executed in the dialog callback section for the default OK button. But I cannot get the script to exit when complete. When I include an exit statement within the handler for the SEND/OK button in the dialog callback the dialog disappears, but the script is still running (the WIL/WBT icon remains in the taskbar and in the Processes list of the Task Manager). I've also tried using a return (RET_DO_DEFAULT) statement rather than exit, but that isn't working either. Script2 also remains running after I close Script1. I have to terminate it manually in the Task Manager.

However, if I do not try to exit in the OK handler, but instead manually click the close button on the dialog (which has no code attached to it in the dialog callback other than return( RET_DO_DEFAULT ) ) the script terminates as it should.

This is basically how it's setup ...

Code: [Select]

case MSG_BUTTONPUSHED

if sendEmail_Name == "PushButton_OK"               ; &Send

*do stuff here*                    ;--> stuff executes just fine, emails are sent
exit                               ;--> does NOT exit
return( RET_DO_DEFAULT )           ;--> also does NOT exit

return( RET_DO_NOT_EXIT )

elseif sendEmail_Name == "PushButton_Cancel"       ; Cancel

                                ;// exits just fine!

return( RET_DO_DEFAULT )

endif                                              ; sendEmail_Name
return( RET_DO_DEFAULT )


Any insight on this? Am I simply missing some aspect to the run command when using it to run another Winbatch script? I've also tried runShell() and shellExecute() but neither makes any difference.

Regards,
Micheal

[JTaylor]

In the msg_init section do you have the PushButton Event defined?   I'm guessing the Cancel button is working because the "value" is set to zero.

Jim

[mhall]

Hi Jim,

Yep, most definitely.

The button push for OK is what actually handles the email send and that is all working fine ... up to exit. At which point the dialog itself disappears, but the script continues to run.

Regards,
Micheal

[td]

The most likely cause is something in the '*do stuff here*' part.

[JTaylor]

Following on Tony's post...if you comment out the "doing stuff" does it exit properly?   If so, I'd start commenting out lines one-by-one, or multiple if needed, and see when it stops working properly.

If that doesn't help I'd try something like Return 9 instead of the exit, making sure the exit or end of script was after the Dialog code, of course.

Jim

[mhall]

Thanks guys,

Of course, I should have known to try that ... but that's what I get for doing this on a lack of sleep. 

All is now handled ... but, for the curious I've included what I found as it does have me scratching my head a bit.

I narrowed the issue down to a small function I have that updates the contents of a ComControl in the dialog.

I use the same pattern for all of my dialog scripts - I create a subroutine called getControlValues() which reads out control values into a set of variables I can access easily. This subroutine is called in the dialog callback to update values and control statuses based on user interactions.

The getControlValues() subroutine was calling a function (updatePreviewImage) to update the ComControl.

The call to updatePreviewImage was the culprit. If I didn't call the updatePreviewImage function, everything exited fine.

This only seems to be a problem when executing that updatePreviewImage() function and exiting inside the same handler in the dialog callback. i.e. - My OK button processing only fails to exit when I include the getControlValues() -> updatePreviewImage() call within it. As soon as I remove the call to updatePreviewImage() from the getControlValues() subroutine, it will exit. Likewise, my Close button processing was working properly, but as soon as I included a getControlValues() with updatePreviewImage(), it failed to exit.

So my solution was to move where I called the updatePreviewImages function into the dialog callback directly and everything is now working fine.

But I've included the function out of curiosity ... it's my first time using a ComControl ... am I missing something I should be doing?

Code: [Select]

#defineFunction updatePreviewImage( dialogHandle, controlName, preview_path )


;// GET OBJECT REFEFENCE TO COMCONTROL AND LOAD HTML DOCUMENT
document      = dialogObject( dialogHandle, controlName, 3 )
globalsArray  = ptrGlobal( globalsArray )
configDir     = arrayValueGet( *globalsArray, 'config' )
doc_template  = fileGet( configDir:'\resources\web\html\dialog_image_preview.html', '' )

document.open()

if fileExist( preview_path )
doc_template = strReplace( doc_template, '{{img}}', '<img id="preview" class="preview_image" src="':preview_path:'">' )
else
doc_template = strReplace( doc_template, '{{img}}', '<p id="preview">Preview Not Available.</p>' )
endif

document.write( doc_template  )

document.close()
document = 0

return 1

#endFunction


Regards,
Micheal

[td]

Guess is you are missing something.  Generally, when you get a hanging process it is because a COM server isn't getting shutdown properly because it is waiting for a method call to finish or a reference to be released or something like that.  It may also be some kind of timing problem that is only manifest when you add the slowing overhead of a UDF call.

You are dealing with MSFT's COM cover for its browser implementation which can be a bit temperamental. It can be a challenge to resolve problems like this but it might be worth investigating a bit further as it may appear on other systems even when you don't us your UDF.

[JTaylor]

What COM Control are you using?   Sorry if I missed that answer in one of the posts.

Jim

[mhall]

Thanks Tony.

---

Jim,

It's the mshtml ComComponent.

Regards,
Micheal

[JTaylor]

Hmmmmmmmmmm....I always use Shell.Explorer.x so not sure of all the differences.   Perhaps create your "document" object in the msg_init section of the Callback and pass that to your Function rather than the DialogHandle?   Maybe embedding that inside the function is somehow interfering with it shutting down properly???

Jim

[mhall]

I was thinking that same thing. Will try it out and see.

Thanks,
Micheal

[td]

Theoretically, using a UDF should not make any difference because creating a new variable with DialogObject simply increments the object's reference count.  Tearing down the object simply decrements the reference count and frees a few WinBatch related resources that are not used by the object itself.  But as previously mentioned the HTMLDocument and WebBrowser interfaces can be a bit flaky. 

Please let us know if moving the creation outside the UDF fixes the problem.  The issue may warrant further investigation.   

[DAG_P6]

About a year ago, I had a similar issue, also involving a COM component. In my case, it was the XCeed FTP ActiveX control. The issue was solved when I explicitly set the control to zero before it went out of scope. Just telling it to close itself was insufficient.

[mhall]

Thanks for the info David.

Unfortunately, that didn't work for me (I saw that in the Help file and tried it out before I posted).

Regards,
Micheal

[DAG_P6]

Michael,

Thanks for the info David.

Unfortunately, that didn't work for me (I saw that in the Help file and tried it out before I posted).

Regards,
Micheal

I'm sorry that didn't solve it. Unfortunately, as Tony has pointed out in several recent posts, the Web Browser control is pretty unstable.