The non-blocking command line parameter
-
A simple kind of integration between two application is that one application calls the other application via the command line, passing a few parameters. A customer wanted to call our application from their main application. On the configuration form, he entered the parameters to be passed:
OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2]
When calling
OurProgram
from theirMainApplication
,MainApplication
parses the command line parameters and replaces internal values with their present values, i.e. it eventually calls:OurProgram.exe /param1=John /param2=Doe
It works, but there is a catch: the user cannot work now in
MainApplication
because it waits forOurProgram
to exit. Our customer called the manufacturer ofMainApplication
, and they told him to add another parameterdontblock
, i.e.OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2] /dontblock
When
MainApplication
finds thedontblock
parameter while parsing the command line, it knows that it need not wait for the called application to exit. It works, but again, there is a catch. It now callsOurProgram.exe /param1=John /param2=Doe /dontblock
and
OurProgram
complains that it does not know the parameterdontblock
. Great design! -
A simple kind of integration between two application is that one application calls the other application via the command line, passing a few parameters. A customer wanted to call our application from their main application. On the configuration form, he entered the parameters to be passed:
OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2]
When calling
OurProgram
from theirMainApplication
,MainApplication
parses the command line parameters and replaces internal values with their present values, i.e. it eventually calls:OurProgram.exe /param1=John /param2=Doe
It works, but there is a catch: the user cannot work now in
MainApplication
because it waits forOurProgram
to exit. Our customer called the manufacturer ofMainApplication
, and they told him to add another parameterdontblock
, i.e.OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2] /dontblock
When
MainApplication
finds thedontblock
parameter while parsing the command line, it knows that it need not wait for the called application to exit. It works, but again, there is a catch. It now callsOurProgram.exe /param1=John /param2=Doe /dontblock
and
OurProgram
complains that it does not know the parameterdontblock
. Great design!Sounds like [Manufacturer] is passing the buck instead of having to deal with it...
I wasn't, now I am, then I won't be anymore.
-
A simple kind of integration between two application is that one application calls the other application via the command line, passing a few parameters. A customer wanted to call our application from their main application. On the configuration form, he entered the parameters to be passed:
OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2]
When calling
OurProgram
from theirMainApplication
,MainApplication
parses the command line parameters and replaces internal values with their present values, i.e. it eventually calls:OurProgram.exe /param1=John /param2=Doe
It works, but there is a catch: the user cannot work now in
MainApplication
because it waits forOurProgram
to exit. Our customer called the manufacturer ofMainApplication
, and they told him to add another parameterdontblock
, i.e.OurProgram.exe /param1=[InternalValue1] /param2=[InternalValue2] /dontblock
When
MainApplication
finds thedontblock
parameter while parsing the command line, it knows that it need not wait for the called application to exit. It works, but again, there is a catch. It now callsOurProgram.exe /param1=John /param2=Doe /dontblock
and
OurProgram
complains that it does not know the parameterdontblock
. Great design!Perhaps a better way would have been to use the start command. Do they not know DOS? :)