Shell gone to hell

[NauticalGent]

Has anyone experienced a problem with the Shell function lately? The following code has worked for years until yesterday.

I am getting an error (I can't recall it from memory but can once I get back to work if need be).

RetVal = Shell("C:\WINDOWS\NOTEPAD.EXE", 1)

My IT dept does nightly updates to our workstations (Windows 7), I asked them about patch info but they have not gotten back to me yet. Figured I would shoot the moon and see if anyone else has experienced this.

I even tried some other programs like calculator and write to see if the problem was with notepad (which works just fine), but I get the same error.

Thanks for your time...

 

[The_Doc_Man]

Try removing and reestablishing the references (.DLL files) as a quick and dirty thing. I doubt it is the NOTEPAD-related files - but MIGHT be related to Windows Scripting or other behind-the-scenes references. Should stand out like a sore thumb if you open a code window, then Tools>>References. If the patch whacked a library, it should now show up as a broken link. That is because even though it appears that the reference is by name, it is more likely that the reference is actually some sort of internal file pointer. If they change the .DLL file or replace it, that pointer will change, too.

 

[NauticalGent]

Thanks Doc...how do I tell if the link is broken? I read about that possibility on a google search but when I checked the Refernces, nothing really stood out.

Since it is a gov system (SIPR), I doubt if I can access the registry. For grins and giggles I tried a similar command on a NIPR station and got the same error.

I thought updates were a good thing...?!?

 

[JHB]

Have you tried to use the ShellExecute?
Here is an example how to use it, else Google it:
http://www.pptfaq.com/FAQ00479_ShellExecute_Example.htm

 

[NauticalGent]

Thanks JHB, looks like something that might work. I will try it first thing tomorrow and let you know how it goes.

Thanks again!

 

[JHB]

You're welcome, let's see if it works.

 

[The_Doc_Man]

how do I tell if the link is broken

When you open the reference list, one of the references will have "Missing:" or something like that between the checkbox and the library common name.

 

[NauticalGent]

No missing or any other messages. Just for kicks, I unchecked all the boxes I could, compiled, saved and exited.
Restarted Access and relinked the references...compiled and saved. I still get the same error which is:

Runtime Error '5': Invalid Procedure Call or Argument

The full code is:
Open "C\path\(file).txt" For Output as #1
Print #1, (field) ' this is the memo field that holds the text
Close #1

RetVal = Shell("C:\Windows\NotePad.exe C\path\(file).txt",1)

Going to try JHB's suggestion and see what happens.

There is a commented out bit of code for ZoomBox which I tried and it works well, problem is the users didn't like the modal properties of the ZoomBox so they went to the Shell thingy.

I will try the ShellExecute COA just to see how it works.

Again, thanks for chiming in...

 

[JHB]

...
Runtime Error '5': Invalid Procedure Call or Argument

The full code is:
Open "C\path\(file).txt" For Output as #1
Print #1, (field) ' this is the memo field that holds the text
Close #1

RetVal = Shell("C:\Windows\NotePad.exe C\path\(file).txt",1)

Maybe a typo, but I think you're missing a : after the drive letter.

Open "C[B][COLOR=Red]:[/COLOR][/B]\path\(file).txt" For Output as #1
..
RetVal = Shell("C:\Windows\NotePad.exe C[B][COLOR=Red]:[/COLOR][/B]\path\(file).txt",1)

I suppose that "path" and "(file)" only are placeholders.

 

[NauticalGent]

Right on all accounts... I tried the ShellExecute example but it didn't work, it gave no indication of ANYTHING happening.

I did a Debug.Print on one of the variables (integer) and it did return a 5, so I know the code is running. I can only assume it is something with the OS.

 

[AccessBlaster]

My notepad and calculator are located in the C:\Windows\system32 folder try:

RetVal = Shell("C:\Windows\system32\notepad.exe", 1)

 

[NauticalGent]

Update: It was a security setting our IT has set. They really lock-down our workstations so not everything works like you would like it to.

I finally got a call from the tech who was assigned who made an "exception" and pushed the update. Everything works as it should and it only took 4 months.

Just figured I would let you all hear the other shoe fall...

 

[The_Doc_Man]

As soon as you said "SIPR" I should have guessed. Our other forum members probably didn't catch the acronym because they don't live in that particular glass bubble.

SIPR is based on a Secure Internet Protocol Router while NIPR is based on a Non-secured Internet Protocol Router. With us (current or former) Dept. of Defense persons, you can run into secured or normal subnets. The rules on the SIPR side of the house are more stringent and the terminals are more tightly locked down.

My next question, Gent: Did the SIPR security folks demand blood sacrifices, and if so, how many doves must you slaughter each week for the next year in return for that spot "exception" to their stringent lock-down rules?

 

[NauticalGent]

My next question, Gent: Did the SIPR security folks demand blood sacrifices, and if so, how many doves must you slaughter each week for the next year in return for that spot "exception" to their stringent lock-down rules?

If I answer that then you lose ALL plausible deniability...AND...given your retired status, you may not have a "Need to Know".

You trying to get me fired 1 day after I got extended??!?

 

[The_Doc_Man]

Probably correct about "need to know." As to plausible deniability, you forget contractor's rules #1 and its corollaries:

#1 The government is always right.
#2 When in doubt, see rule #1

Corollary 1: It is always the contractor's fault.
Corollary 2: Don't deny anything. Take full blame. (If you are a valuable employee, forgiveness is cheaper than permission.)