Synchronous Communication wIth External .exe or .bat Files and VB6 under WIndows 10

[SwampeastMike]

Are my hours of study correct in that it is still impossible to share an updating value between a shelled .bat file and a running (even if waiting under ShellEx) VB6 program? The purpose of this is, obviously for something of a progress update as I'm working with tens, hundreds and thousands of files of different sizes and types among potentially hundreds of folders.

I can accomplish this one-by-one with simple shell statements on a file-by-file basis but execution speed varies from OK to hideous regardless it seems of the priority settings as compared to doing all of the work using the exact same series of conversions in a batch file.

I attempted to communicate via the clipboard to utter failure as VB kept returning a runtime error indicating that the clipboard was not available/shared.

I know that I can create multiple batch files that call each other in sequence at my selected interval to receive update at the completion of each batch.

Perhaps an alternative exists.

I found this while searching here:

Here's two examples

1) RunEXEFromResource.zip

Load Client.vbp into the IDE and run it

This will extract the EXE from the resource file. It then saves it to your App.Path as "serverapp.exe" and then Shell's it.


2) RunEXEFromResourceInMemory.zip

Load Project1.vbp into the IDE and run it.

This one extracts the EXE (Project2) from resource and loads it into main memory and runs it from there. No Shell used.
Attached Files Attached Files
File Type: zip RunEXEFromResource.zip (5.4 KB, 306 views)
File Type: zip RunEXEFromResourceInMemory.zip (8.3 KB, 307 views)

in this thread: https://www.vbforums.com/showthread....ude-EXE-in-VB6

Am I correct that, once loaded. the .exe file used will stay resident and available in memory preventing the sort of slowdowns that occur when I repeatedly use the Shell command to "escape" VB to run the .exe while still waiting (via ShellEx) for each individual process to complete before taking action and proceeding?

I would [I think] prefer the second option (loading the .exe into memory while needed) as I can also make very quick (processing wise) and broad assumptions for the most accurate status update while still displaying a filename for at least enough time for the user to at least flash read the first few characters.

[VanGoghGaming]

You don't need to extract a new EXE from resources, you could just execute your own app once again but with different command line parameters that would instruct it to do something else. However the most elegant method would be to convert your app into a Standalone ActiveX EXE instead of a Standard EXE and then it could just create new instances of itself that would raise events back when finished processing.

[dz32]

You should be able to create a small command line app you can run from bat commands that will send a notification back to the main controller exe using some ipc technique like wm_copydata - http://sandsprite.com/openSource.php?id=70

I really dislike bat files though. I think I would include a reference to the ms script control in the parent app and use a vbs or js script to do all the processing then keeping track of status and updating the main ui is easy plus you get more complex logic and can do major functions on the vb side giving the script access to whatever type of functions you can dream of

[Zvoni]

My first point of entry would be to look, what those batch-files actually do.....