Calling a another dialog based Winbatch Exe from within a callback procedure

[Thekub]

We have two complied WinBatch scripts that utilize Dialogs which we use in our organization, one to generate Active Directory user accounts and another used to generate standardized unique PC names.  We are introducing some new functionality into the user account tool.  The new functionality adds a new Dialog prompting for a computer name and a serial number, the intent being the EditBox for the computer name can be manually interacted with if a desired name is already at hand otherwise we have an additional button which can be used to generate a new name. 

I have a dialog callback procedure created for when the "generate name" button is clicked.  The desired effect is if the "generate name" button is selected some checks\housekeeping steps run then a RunWait command invokes the existing computer naming tool with a custom parameter.  The computer naming tool should run, slightly modifying its default behavior due to this added passed parameter.  The computer name tool is also Dialog based presenting several ItemBox options to select, once completed the generated computer name should be written to an INI file and exit at which point my code resumes and reads the value from the INI and updates the EditBox.

Where I seem to get stuck is my callback procedure triggers as expected, the computer naming tool starts as expected (it initializes, connects to a SQL table to populate lists for the ItemBox elements) but when its Dialog is to appear it stops and then windows reports that my executable is not responding.  If I terminate my executable the dialog for the naming tool then displays.  As a test, I moved my RunWait command outside of the callback procedure (which causes it to run when no active dialog is running) and the computer naming tool launched, displayed its dialog, wrote to the INI, and exited as expected and my code resumed as expected.

Any suggestions\guidance would be appreciated.

[JTaylor]

If you are not I would recommend disabling the first dialog immediately prior to RunWait() and then enable after.   I wouldn't think that would affect another EXE but might give it a try.

Curiosity question...Why use a separate EXE if it is WinBatch code?

Jim

[Thekub]

Worked like a charm.  Thanks Jim!

To satiate your curiosity, at the core both tools have different roles and uses.  For the computer naming tool, the vast majority of its use is as a standalone tool in a different workflow.  The functionality I was adding to my tool has a more edge case use and this implementation seemed more efficient then importing\including the other tools source and having to work through and tweak for issues like colliding variable names (tools are built maintained by separate team members).   

[td]

For reasons I wont go into here,  when a WinBatch process is executing a dialog callback the process does respond to many Windows kernel events.  However, when the dialog is disabled, the process message pump responds to most kernel events.  The exception being user interface events which are simply ignored.     

RunWait requires inter-process communication via kernel events to do its job.  But since the first process does not respond to the kernel events while it is in the callback, the second process hangs waiting for a response from the first process.