Run Program $TARGETDIR$\\xyz.exe

GW44 · Post by **GW44** » Thu Mar 02, 2006 3:52 pm

In the final dialog the user has the option to run the app.

Using this it tries to start the app from the Windows folder instead of the Target Folder and it fails as it needs the current info in the target folder.

Run Program $TARGETDIR$\\xyz.exe $TARGETDIR$\\xyz.exe

Added the command $TARGETDIR$\\xyz.exe thinking maybe that was needed but that made no diff.

Installation functions OK otherwise.

GW44

MichaelNesmith · Post by **MichaelNesmith** » Thu Mar 02, 2006 5:44 pm

You can try using Run Program As and specify a startup directory. Or, you may call the SetCurrentDirectoryA function in kernel32.dll using the Call DLL Function command to forcibly set the current path.

GW44 · Post by **GW44** » Thu Mar 02, 2006 7:42 pm

Is this a bug the way it is now?

If it is we'll wait for the next update.

GW44

GW44 · Post by **GW44** » Thu Mar 02, 2006 11:25 pm

Tried both.

Run as... and specifying the $TARGETDIR$ (and tried $TARGETDIR$\\) as startup folder does nothing.

i.e the program does not start at all.

GW44

GW44 · Post by **GW44** » Thu Mar 02, 2006 11:28 pm

Won't try the DLL function as we're getting away from calling Win APIs.

GW44

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 03, 2006 12:41 am

No, this is not a bug. Both Run Program and Run Program As call the CreateProcess Win32 API which is the correct way to launch new applications.

As you know, everything on the Windows platform, including .NET, is implemented internally using Win32 API calls; so I wouldn't hold back on calling SetCurrentDirectoryA.

GW44 · Post by **GW44** » Fri Mar 03, 2006 2:22 am

My comment is after filling in the blanks "Run Program" ... "Run program as ...." the app does NOT start.

Why are these "Run Program" and "Run Program AS" functions including the dialog boxes for these functions there than????

Your comment about .net using api calls does not make practical sense as it relates to this problem. Who in the world would use API calls when the same can be accomplished using existing functions in .NET.

Don't care what the function does internally or what and how it calls the internals. Just want the function to work. It doesn't so again why????

Don't tell the customer to use something else. If it is NOT supposed to be used as I indicate, what on earth it are these 2 functions for??? Yes we printed the user guide and checked.

If we are reading correctly, the intended use is to run the just installed app when the installation is complete like many other installation programs. The popup dialog has a spot for starting folder or something like that, just like the Win app shortcut properties dialog. Please explain if not.

The reason one uses a 3rd party installation program is so one does not have to call the API directly. Yes call them if there is no function for what one is trying to accomplish. Why do you think MS came out with .NET? Very few API calls needed after .NET 2.0 came out compared to earlier versions.

Pls explain.

GW44

Gizm0 · Post by **Gizm0** » Fri Mar 03, 2006 9:51 am

It looks like you have a lack of knownledge on the .Net framework.. to do "Tricky" stuff, you still need to call API's even on .Net 2.0.Most of the "Advanced" options on API's are hidden by the managed wrapper..Anyway, as for the Run Program and Run Program As.

They are there, to work.. But your .net exe, needs its startup directory set to run correctly.When you double click an .exe you pass through the ShellExecute and then CreateProcess etc etc, so the startup directory is set by the ShellExecute function..The ShellExecute reads the current directory set by the API Michael provided, so you HAVE to call that API in order to make .Net exe to work.. It's not a bug, nor InstallAWARE's fault.. It's .Net behavior..At least on my company, we do it that way.

And please stop bitching around and relax.Before starting accusing the product, ask..

Oh and MS come out with .Net not for the API's.. but for the dll hell and memory leak problems etc etc..

GW44 · Post by **GW44** » Fri Mar 03, 2006 12:17 pm

Still have not answered why "Program run as" does not work. What are we doing wrong.

Only asking again, not bitching, because we don't get an answer or explanation. Simple as that.

The startup dir is provided. Are you saying that this is insufficient:

Run Program $TARGETDIR$\\XYZ.exe , startup in folder $TARGETDIR$

If it isn't, how about showing the code needed to make it work?

No I guess we don't get it.

Yes we know about the reasons for .NET and that's why we've been using it since it came out.

As you'll note some other user, and not tech support, finally had to provide the simple answer we were looking for in an other post.

GW44

GW44 · Post by **GW44** » Fri Mar 03, 2006 12:41 pm

From the User Guide below.

It says to use ShellExecute where again???

GW44

Run Program As

The Run Program As command enables you to execute a program on the target system with advanced options. For simpler execution, use the Run Program command.

Run Program

Type the full path to the executable that is to be run.

Working Directory

Type the full path for the startup folder of the executable. Leave empty for the default (current) folder.

Command Line

If you will be using any command line parameters, enter them in this field.

Environment

If you wish to pass any environment variables to the program, or override any pre-defined variable values, enter them in this field.

Program Window

Choose a display mode for the program window.

User Name

If you wish to run the program under a different user account than the current logged on user, enter that account name here.

Password

If you entered a user account in the User Name field, enter the password for that account here.

Domain

If you wish to run the program under a different domain than the current logged on user's domain, enter that domain name here. You must also populate the User Name field.

Return Result in Variable

If the program you are running sets a return value, you may capture it inside a variable by providing the name of the variable in this field.

Notes

Some programs may have difficulty with long path names used in their command lines. It may be best to use the Convert Path command on such paths before executing the program.

jimo · Post by **jimo** » Fri Mar 03, 2006 1:49 pm

Try something like this;

Set Variable INSTALLDIR to $TARGETDIR$
Convert to Short Path: INSTALLDIR
Call DLL Function kernel32.dll->SetCurrentDirectoryA (get result into variable LASTERROR) (Of cousre the dir to set is $INSTALLDIR$)
Run Program $INSTALLDIR$\\myapp.exe

GW44 · Post by **GW44** » Sat Mar 04, 2006 4:25 pm

Thks jimo!

GW44

I guess it must be too difficult for TS to give more than a one line answer.

MichaelNesmith · Post by **MichaelNesmith** » Sat Mar 04, 2006 5:48 pm

Please keep your comments in these forums professional. Thank you for your cooperation.

Gizm0 · Post by **Gizm0** » Sat Mar 04, 2006 6:03 pm

GW44 wrote:Thks jimo!

GW44

I guess it must be too difficult for TS to give more than a one line answer.

Actually, support is here to help you on troubles you may have, not to build your installation..We/they(michael) provided an answer how to do it, i don't think he or i have to code it for you as well..

GW44 · Post by **GW44** » Tue Mar 14, 2006 4:02 pm

Yes and when ones asks a question and gets an answer like:

You can try using Run Program As and specify a startup directory. Or, you may call the SetCurrentDirectoryA function in kernel32.dll using the Call DLL Function command to forcibly set the current path.

and when we specifically tried the suggestion:

"Run Program As and specify a startup directory." Never mind the ",or..."

It didn't work. Looking in the wrong folder for the app when trying to run the app from the Run dialog.

No big deal, we removed the Run checkbox from the Dialog box.

So looks like a bug to us.

GW44