Returning a value from EXE

[IlyaRabyy]

Colleagues,
I have "Manager" EXE which calls "Worker" EXE.
That latter has to return a value to the calling "Manager" (say, numeric success code, or just Boolean one).
Will (in the "Worker")

Sub Main() As Integer
Dim lnSuccess As Integer = 0 ' Full success, initially
...
Return lnSuccess
End
End Sub

do the trick?

Regards,

Ilya

 

[strongm]

[tt]Environment.ExitCode[/tt] I believe

 

[IlyaRabyy]

Did you mean Environment.Exit(int32 exitCode)?
As in

https://docs.microsoft.com/en-us/dotnet/api/system.environment.exit?view=netcore-3.1

?

Regards,

Ilya

 

[strongm]

Yes

 

[strongm]

That'll show me to always pay attention. No, I didn't mean Environment.Exit(int32 exitCode)

I meant exactly what I said: Environment.ExitCode

 

[IlyaRabyy]

Hmmm... Am I correctly understand that in VB .NET

1. Parameters passed by the calling EXE shall be read by Environment.GetCommandLineArgs() method,
2. Property Environment.ExitCode is read by the calling EXE upon the called one's "retired"?

If so - then another, more complex scenario:
Imagine that Master.EXE calls more than 1 Worker, say Worker1.EXE and Worker2.EXE (and so on, up to, say, 12 Workers);
How the Master.EXE knows which WorkerN.EXE finished its run and returns that ExitCode?
(I looked up Environment class' description and found nothing that tells me the name of the called EXE bound to the returned ExitCode...)


Regards,

Ilya

 

[Andrzejek]

Not to state the obvious, but I would assume your EXE's deal with some kind of the data base.
If so, then why not just write what you want into a table and read anything anywhere from that table...


---- Andy

There is a great need for a sarcasm font.

 

[IlyaRabyy]

I would assume your EXE's deal with some kind of the data base

No, Andy, there's no DB/table to "supervise" the "Workers".

There is the solution, though: since Workers run each in its own subdir, each Worker creates a TXT (pure ASCII) file and, on exiting, writes the exit code into this file.
This is the solution used in our programs so far. But IMHO this solution is kinda clumsy... and I'm trying to find something better than that.
(In case you are wondering: I'm programming Master to have an array to keep track of the Worker.EXE copies launched, but like I've said: there's no table to "keep and eye" on Workers.)


Regards,

Ilya

 

[strongm]

>How the Master.EXE knows which WorkerN.EXE

How are you launching the Workers?

This code, for example, essentially illustrates being able to track each worker uniquely plus getting the exit code from each one
You'll need a form with two buttons on it. Remember, it illustrates some ideas; it is NOT production code.

[blue]Imports System.Threading
Public Class Form1
    Dim myproc As System.Diagnostics.Process

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        myproc = System.Diagnostics.Process.Start("<pathtoexeinstanceofthisveryapplication") [COLOR=green]' launch another copy of myself[/color]

        AddHandler myproc.Exited, AddressOf Proc_Exit
        MsgBox("Starting " & myproc.Id) [COLOR=green]' Unique ID for this process[/color]
        myproc.EnableRaisingEvents = True
        Dim worker As Thread = New Thread(New ThreadStart(Sub() myproc.WaitForExit())) ' spawn a thread so we don't block to monitor for process exit

    End Sub

    Private Sub Proc_Exit(sender As Object, e As EventArgs)
        Dim proc = DirectCast(sender, System.Diagnostics.Process)
        MsgBox("Stopping " & proc.Id & " Exit code: " & proc.ExitCode & " Named: " & proc.StartInfo.FileName) [COLOR=green]' Various bits of info about uniquely identifiable  exiting process[/color]
    End Sub

    Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
        Environment.ExitCode = 256
    End Sub
End Class[/blue]

 

[IlyaRabyy]

Threading, IOW, right?
Unfortunately, I've never done multi-threaded programs... but, as James Bond said in "The Spy Who Loved Me", "There's 1st time for everything"!
And I've never shied away from learning some new programming technique.


Regards,

Ilya

 

[strongm]

Er, well no not really - threading is not the point here. I included it as it was going to be the basis of a more complex, bigger solution (involving polling waitable events ...), but I decided against that. You can actually comment out the [tt]Dim Worker[/tt] line, and the code will still work fine.