I know its possible to do this.. but if i wanted to launch Internet explorer with a specific website, and perhaps even a specific page, is this possible? Would it be the same syntax under W2000/XP/Vista?

Thanks.

Frank, this is how I do it. It works under W2000, server 2003, XP, and I think I tested it under Vista, but not sure.

mx'file'name = "http://www.lexicomcomputers.com"
mx'action = ""
mx'params = ""
mx'path = ""
mx'flags = 3

xcall miamex, mx_shellex, status, mx'file'name, &
mx'action, mx'params, mx'path, mx'flags

Thanks, Herman. I suppose if i wanted to go to a specific page i would just append that to the end of the command line?

Yes, I also do the following web site:
"http://www.lexicomsolutions.com/getip.php"

I also do things like

mx'file'name = "%miame%\scripts\service controller.exe"

and

mx'file'name = "http://www.docboard.org/docfinder.html"

and

mx'file'name = "notepad.exe"

Some I set the flag = 1 to force my app to wait

Note: the MX_SHELLEX operation on a filespec or URL with nothing specified for the ACTION parameter (i.e. using the default action) is equivalent to just typing the same filespec or URL into the Start..Run dialog.

Not only does that make it easy to test what a particular filespec/URL will do, but it also means that it will work more or less uniformly across all versions of Windows that have the Start..Run dialog (i.e. from W98 through Vista). Better still is the fact that under Vista, commands files launched this way will request "elevation" if necessary, whereas those executed via HOSTEX or AG_WINEXEC may not.

The one factor that can vary from individual PC to PC (with or without the same version of Windows) is the application that is associated with the particular type of file or URL. In general that's a good thing, since if you want to launch, say, a browser displaying a particular page, you don't care if one PC has their browser default set to IE7 while another uses Firefox. The issue mainly arises when you are dealing with uncommon file types. For example, just because you may have associated .BAS files with The Editor on your PC, on another, using MX_SHELLEX on a .BAS is likely to launch Visual Basic.

Gotcha.

Thanks very much for the input, gentlemen.. (u too, Herman..)

I'd like to bring this back from the dead because I'm having problems executing a WIndows program.

I'm trying to run wbadmin.msc (windows server backup log viewer)

I'm using the structure that Herman mentioned in the beginning of the thread:

mx'file'name = "%windir%\system32\wbadmin.msc"
mx'action = ""
mx'params = ""
mx'path = ""
mx'flags = 3

xcall miamex, mx_shellex, status, mx'file'name, &
mx'action, mx'params, mx'path, mx'flags

I've also tried specifically defining the path like below

mx'file'name = "c:\Windows\system32\wbadmin.msc"
mx'action = ""
mx'params = ""
mx'path = ""
mx'flags = 3

xcall miamex, mx_shellex, status, mx'file'name, &
mx'action, mx'params, mx'path, mx'flags

Either method gives the same error:

Windows cannot find 'C:\Windows\systems32\wbadmin.msc'

I have browsed to that folder and verified that wbadmin.msc does exist there.

Any ideas?

Thanks
Gregg

Wow - you've just jumped to the front in the competition for who can revive the oldest dormant forum thread (13+ years)! That's got to be worth something at the next Conference!

But the joy may end there, since although I at first thought I was able to reproduce this, I then realized that I don't have that file. I tried it with a similar file, eventvwr.msc, and got the same error, but then realized that I had a typo in my request. (Not sure if relevant, but you have one in your error message above, i.e. systems32 vs. system32). But to simplify matters, it appears to work (at least for me) by just entering the filename without the path, i.e. eventvwr.exe. (I used the MIAMEX[908,30] test program in the EXLIB for testing; you might want to try that just in case it behaves differently than your own.)

After I confirmed that it worked with just the filename, I tried again with the path "%windir%\system32\eventvwr.exe" and that worked as well. And both the abbreviated and fully qualified versions work when typed directly to the search bar. So at this point I'm leaning towards the typo theory.

But as an aside (and a possible clue), when it fails, it creates a file shellex.log in the current directory. I noticed that the log for my first failed attempt had an unmatched quote around the filespec, which could be an indication of an intermittent bug in the filespec converter. I've been unable to reproduce it though, even when deliberately mis-typing the filespec. So there could be something going on there. If you can get it to fail with the exact same spec that succeeds when typed in to the start..run or search bar, then send me or post a screen shot along with the shellex.log file and we can dig into this further. (No rush though - the current turnaround time for this thread is averaging about 3 years!! )

Hi Jack,

And here you thought I never looked back at the old stuff for answers. The problem seems to be with programs with the .msc extension. I can also launch programs with a .exe extension with no problem. The shellex.log reports the following when I try to launch the .msc file.

ShellExecute Failure Log...
fMask = 0x0
hwnd = 0x203ec
lpVerb =
lpFile = C:\Windows\system32\wbadmin.msc
lpParameters =
lpDirectory =
nShow = 3
hInstApp = 2
GetLastError() = 2

hmmmm

Apparently we need to upgrade our user surveillance techniques for keeping better track of what people are up to on this site. And where's the "Like" button anyway?

Then again, maybe there's nothing to like here. The log seems to indicate you've done everything right (assuming of course you actually have that file). Error 2 is "File Not Found".

Does it launch from the search bar?
Does it launch from a non-elevated command prompt? (If so, maybe there's an workaround there...?)
Does evntvwr.msc work? (If so, that would imply it's not simply the msc vs exe extension.)

wbadmin.msc does require that you be member of Backup Operators or the Administrators group, or something equivalent. (But presumably that's not the issue or you wouldn't be able to launch it by any means.)

I'll second your hmmmmm...

I'm testing all of this on a customer's server, under our Support account which is a member of the Supervisors group. I can run both wbadmin.msc and eventvrw.msc from the run prompt. I checked and I have shortcuts on the desktop for wbadmin.msc on my Support account as well as the various user level accounts, and those shortcuts launch the program correctly. To add even a bit more strangeness, eventvrw.msc will launch via AShell, but wbadmin.msc will not. (I just changed the name of what I was calling via AShell).

I also checked the security settings on both and they are identical. They both belong to the same Groups and or Users.

I'm at a loss at the moment

I think I'm gonna win the weirdness problem of the day award too....

Right. But I'm afraid there's no prize for that award.

Although I have a few more ideas to try (assuming you like beating your head against the wall)...

1. Try running A-Shell "as administrator". (It may be that the Run prompt automatically is doing that behind the scenes for msc files or some such trickery.)

2. See if there is a wbadmin.exe file. I don't have either the msc or the exe, but in the case of eventvwr, I have both. And I get the same result launching either one via MX_SHELLEX. But in the case of HOSTEX, only the exe version works (since .msc files aren't technically executable).

3. See if you can launch mmc.exe (which is the app that processes the .msc files), either via MX_SHELLEX or HOSTEX.

4. If that works, then try setting the parms argument of MX_SHELLEX to "c:\windows\system32\wpadmin.msc"

If none of that works, I suggest asking for advice at your local watering hole...