SETTING PROGRAM VARIABLES FIXED WHILE CHAINING PROGRAMS
I have a first module wich lets the user login, he makes choice wich printer wants to use while running etc.
Then I would like to run in this first module (is kind off menu choices) a function wich
opens a file wich contains: datapath for all ledgerdata, datapath for all faxes, datapath for orders, etc. Then this variables I want to have available in any program chained so I only have to do maintence in first module.
Chaining example:
Private sub Invoices_click()
Shell("k:\vbaua\invoices.e
' I would like to have at chaining allready: Shell (programs & "invoices.exe",vbNormalFoc
' and take all varibles like username with me to invoices.exe
end Sub
Then I would like to run in this first module (is kind off menu choices) a function wich
opens a file wich contains: datapath for all ledgerdata, datapath for all faxes, datapath for orders, etc. Then this variables I want to have available in any program chained so I only have to do maintence in first module.
Chaining example:
Private sub Invoices_click()
Shell("k:\vbaua\invoices.e
' I would like to have at chaining allready: Shell (programs & "invoices.exe",vbNormalFoc
' and take all varibles like username with me to invoices.exe
end Sub
You actually have two EXEs and want to share variables between them. Is that right?
It is my recommendation that you not do this. Shelling is bad practice anyway.
You should instead merge the two into a single .EXE. If this is not an option, then the only way I can think of to do this is to pass the variables as a dataset through some medium such as a temporary file, MQ, etc. It can't very well be a "live" means such as sockets, named pipes, etc. because the shelled program may not be ready when you think it is, and the program that launches it doesn't return control to you until the process ends (and the called EXE closes). The only way I can see this happening is if you first start another thread before you shell, and have that thread answer communication with the shelled EXE. This is not a pretty solution.
It is my recommendation that you not do this. Shelling is bad practice anyway.
You should instead merge the two into a single .EXE. If this is not an option, then the only way I can think of to do this is to pass the variables as a dataset through some medium such as a temporary file, MQ, etc. It can't very well be a "live" means such as sockets, named pipes, etc. because the shelled program may not be ready when you think it is, and the program that launches it doesn't return control to you until the process ends (and the called EXE closes). The only way I can see this happening is if you first start another thread before you shell, and have that thread answer communication with the shelled EXE. This is not a pretty solution.
ASKER
The reason I do shell (I think , because I'm a old dos-programmer switching to VB6),
that programs I'm converting are big , realy big.
They have different functions, so what we did in dos was having a main.exe and in that
main.exe users 'chained' instead of 'shellling' to what ever they had to do.
I could not find a 'chain' function in VB thats why I do shell.
I do protect them from not more then one shell at the time, so always return to calling
main-module.exe
If there would be a better solution, I will be happy to learn
Regards Jack
that programs I'm converting are big , realy big.
They have different functions, so what we did in dos was having a main.exe and in that
main.exe users 'chained' instead of 'shellling' to what ever they had to do.
I could not find a 'chain' function in VB thats why I do shell.
I do protect them from not more then one shell at the time, so always return to calling
main-module.exe
If there would be a better solution, I will be happy to learn
Regards Jack
If you have the source code for the apps then modify them so they accept command line parameters. Then you can pass the values to the next app in your Shell() statement.
Idle_Mind
Idle_Mind
That's how it goes sometimes. The called process is also a windows application, is it not? If so, you could store a value in the registry telling it where the common medium is (be sure to watch for multiple instances of your app), or better yet, as Idle Mind pointed out, a command-line parameter.
If there is a lot of data to pass or if it is complex, my recommendation for this medium is an XML document.
If it's simple data, you could just pass the values instead ofa descriptor of the medium.
If there is a lot of data to pass or if it is complex, my recommendation for this medium is an XML document.
If it's simple data, you could just pass the values instead ofa descriptor of the medium.
ASKER
Yes I have all source because we rewrite the dos-stuff to Vb-stuff, I think that what Idle_Mind suggest would solve it right?, because 1st. main.exe is small can open in main.exe 'a parameter' file for wich I can make a maintenance module if changes needed.
Then a Case situation were to goto and what parameters to 'chain' are,
Could you please give (short) syntax what a 'call' woul look like, and the 'chained' module has as syntax to extract parameter.
e.g. Username$ = "jack": Password$ = "OK" : datapath$ ="I:\data"
Then a Case situation were to goto and what parameters to 'chain' are,
Could you please give (short) syntax what a 'call' woul look like, and the 'chained' module has as syntax to extract parameter.
e.g. Username$ = "jack": Password$ = "OK" : datapath$ ="I:\data"
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start the application throgh that module G. [no need].
Set the value of that variable in that module G. So, you can access them in all the modules.