Opening a second application using the Shell() command. 1

[rarubio1]

I have written a VB6 application that is a able to open a second application through the use of the Shell() command. The second application always appears minimized in the task bar. How do I get the second application to open up maximized on the screen?

Thanks in advance,
RR

 

[EBGreen]

Try:
Shell("Blah.exe", 1)

[blue]"Well, once again my friend, we find that science is a two headed beast. One head is nice, it gives us aspirin and other modern conveniences,...but the other head of science is BAD! Oh, beware the other head of science, Arthur; it bites!!" - The Tick[/blue]

 

[bjd4jc]

Check out the help in Vb and it will tell you that you can pass a second (optional) parameter to determine the window state of the shelled application.

 

[rarubio1]

I will try it right away. Thank you both.

RR

 

[VBrit]

shell "my executable", vbMaximizedFocus

There ya go.

 

[rarubio1]

Thanks all. VBrit's solution worked for me. I could not get Shell("MyExecutable.exe",1) to work.

RR

 

[bjd4jc]

Did you check out the VB help for the explanation?

 

[techkate]

rarubio1,

I believe Shell("MyExecutable.exe", 1) may not have worked if you weren't retaining the return value of the function. If you're keeping track of the return value, you would use the syntax in the first example (includes parentheses). If you don't care about the return value, you would use the syntax in the second example:

x = Shell("MyExecutable.exe", 1)
Shell "MyExecutable.exe", 1

Other functions work the same way, such as MsgBox.

Hope this helps.

 

[bjd4jc]

Shell("MyExecutable.exe", 1) will open the window 'normally' whereas Shell("MyExecutale.exe", vbMaximizedFocus) will always open it Maximized. If the 'normal' state of the window is minimized then using a value of 1 will open it minimized. If the 'normal' state of the window is maximized, 1 will open it maximized.

the constant value for vbMaximizedFoucus is 3. It is the same as doing

Shell("MyExecutable.exe", 3) whereas Shell("Myexecutable.exe", 1) is the same as doing Shell("MyExecutable.exe", vbNormalFocus)

It has nothing to do with whether or not you capture the return value.

 

[johnwm]

As k8e said, the issue of the return value only relates to the use of the brackets.
[tt]
Shell("MyExecutable.exe", 1)[/tt]
on its own won't work, as its using a function format.
[tt]
x = Shell("MyExecutable.exe", 1)
[/tt]
will work fine and assign the return value to X

If you want to call it as a Sub then don't use brackets:
[tt]
Shell "MyExecutable.exe", 1
[/tt]

________________________________________________________________
If you want to get the best response to a question, please check out FAQ222-2244 first

'If we're supposed to work in Hex, why have we only got A fingers?'

 

[bjd4jc]

I guess when rarubio1 said he couldn't get Shell("MyExecutable.exe",1) to work I didn't take it as a syntax problem but that it didn't give him the desired result.

This would be the case because if the window opens minimized normally, this command would not have worked for him.

 

[VBrit]

If you use a function call with brackets then the syntax implies there is a return value - for example:

HowManyWheels(1) is a syntax error

but

CarWheels = HowManyWheels(1) will make CarWheels equal to the return value of HowManyWheels(1)

Also you shouldn't use real integers like
shell "fred.exe", 1

VB functions that have enumerations in their definition, should prompt the programmer to use them. Use the VB enumerations (eg. vbMaximizedFocus) - it makes code more legible and more easily supported.

When you all get a payrise I want a cut!!!

 

[strongm]

>HowManyWheels(1) is a syntax error

No, it isn't

 

[VBrit]

Actually mate, yes it is. In VB6 and ASPand any other VB based language.

Also in C++.

Brackets imply that a calculation takes place on supplied variables.

Any such variables supplied without brackts implies they can not be changed or calculated upon.

Hence when a return value is returned to a function it is parenthesised. If it wasnt then it could not be returned or midified or calculated upon with a result expected from the callee.

Hence if you call a function with no expectant return values no parenthersis are required, but if variables are expected to be returned then another item has to be used to store the pointer to the expected results, and imply the calculation the processor needs to be prepared to return.

I hope this clarifies the area you were confuesed about.

 

[strongm]

I'm not confused.

When calling a procedure or function

HowManyWheels(1)

is not in itself a syntax error, no matter how much you want it to be. It may not always do exactly what one expects, but that does not make it a syntax error.

HowManyWheels(1,1), however, is a syntax error when used by itself, and the specific reason {b]why[/b] it is a syntax error is the cause of TomThumbKP's original solution failing for rarubio1