ShellExecute general question

[Dymondjack]

Hello and thanks in advance.

I'm using the ShellExecute API to open a text based file for the user to
view. I was wondering if it is possible to halt the vb code until the file
is closed (perhaps a dialog or modal mode?) I've done a quick search on the
net for arguments concerning this but there doesn't seem to be anything with
the Shell function that provides a way to do it.

I'm just wondering of there is an easy way to do this... I'm fairly new to
API's. I do have an idea about running a loop that checks for the file open,
and would not stop the loop until the file closes, but this seems like a
heavy performance deficiency for the db.

Thanks
Jack

 

[Dirk Goldgar]

Hello and thanks in advance.

I'm using the ShellExecute API to open a text based file for the user to
view. I was wondering if it is possible to halt the vb code until the
file
is closed (perhaps a dialog or modal mode?) I've done a quick search on
the
net for arguments concerning this but there doesn't seem to be anything
with
the Shell function that provides a way to do it.

I'm just wondering of there is an easy way to do this... I'm fairly new to
API's. I do have an idea about running a loop that checks for the file
open,
and would not stop the loop until the file closes, but this seems like a
heavy performance deficiency for the db.

As long as you know the name of the executable that is associated with the
document -- and as long as it accepts command-line arguments -- you can use
the ShellWait function posted here:

http://www.mvps.org/access/api/api0004.htm
API: Shell and Wait

For example, one could write:

ShellWait "notepad.exe C:\Temp\MyTextFile.txt", WIN_NORMAL

You could use the code posted here:

http://www.mvps.org/access/api/api0023.htm
API: Find the associated EXE file

to get the name and path of the appropriate executable.

 

[Dymondjack]

Thanks Dirk, this is exactly what I was looking for. Just out of
curiousity, for anyone who would like to answer, what type of performance
effects do API's have on an access db? I'm gathering quite the collection as
I progress, between filepickers, opening files, testing server connections,
manipulating the access window, ect ect...

I tend to write code for the majority of things that my application does, I
prefer not to let access make it's own descisions where I don't have to, but
even for the 7000+ lines of code I have, API's seem to have a massive amount
of arguments compared to general VB funtions. So far I haven't noticed any
major performance issues, but being new to this, I have no idea how much
memory the system can use before it starts to become an issue.

Again, just a curiousity question...

Thanks
Jack

 

[Dirk Goldgar]

Thanks Dirk, this is exactly what I was looking for.

After posting that, I decided that it might come in handy for me, too, so I
wrote the function below to use the ShellWait and fFindExe functions (from
the links posted) to open a document and wait for it to be closed:

'----- start of code -----
Function fOpenDocAndWait( _
pstrDocPath As String, _
Optional plngWindowStyle As Long = WIN_NORMAL) _
As Long

' Written by: Dirk Goldgar, DataGnostics LLC
' Feel free to use this in your own applications, but I'd appreciate
' your not selling it separately.

On Error GoTo Err_Handler

Dim strFileName As String
Dim strFolder As String
Dim strExePath As String
Dim strCommandLine As String

Const Q As String = """"

strFileName = Dir(pstrDocPath)
If Len(strFileName) = 0 Then
fOpenDocAndWait = 53 ' File not found
Exit Function
End If

strFolder = Left$(pstrDocPath, Len(pstrDocPath) - Len(strFileName))

strExePath = _
Trim(Replace(fFindEXE(strFileName, strFolder), Chr(0), " "))

If Len(strExePath) = 0 Then
fOpenDocAndWait = 17 ' Can't perform requested operation
ElseIf strExePath Like "Error:*" Then
fOpenDocAndWait = 17 ' Can't perform requested operation
Else
strCommandLine = Q & strExePath & Q & " " & Q & pstrDocPath & Q
ShellWait strCommandLine, plngWindowStyle
fOpenDocAndWait = 0
End If

Exit_Point:
Exit Function

Err_Handler:
fOpenDocAndWait = Err.Number
Resume Exit_Point

End Function
'----- end of code -----

Just out of
curiousity, for anyone who would like to answer, what type of performance
effects do API's have on an access db? I'm gathering quite the collection
as
I progress, between filepickers, opening files, testing server
connections,
manipulating the access window, ect ect...

In my opinion, the API call will generally be at least as fast, and usually
faster than doing something similar using built-in methods, because either
the built-in method will be a wrapper around the API call, or else will
involve more elaborate programming with the overhead of using code objects
and loops that would otherwise not be required.

I tend to write code for the majority of things that my application does,
I
prefer not to let access make it's own descisions where I don't have to,
but
even for the 7000+ lines of code I have, API's seem to have a massive
amount
of arguments compared to general VB funtions. So far I haven't noticed
any
major performance issues, but being new to this, I have no idea how much
memory the system can use before it starts to become an issue.

I will normally use a built-in function or feature where it's available and
its performance is at least close to that of a corresponding API call, just
because it is better documented. Also, not all API calls are available on
all versions of the operating system (though as older OS versions are fading
from use, this is less of a concern). But I'll use an API call in
preference to an ActiveX control, because those generally require specific
references to be set, and are vulnerable to broken references, versioning
problems, and distribution/licensing issues.

 

[Stephen Lebans]

There are no detrimental effects to the performance/working of your MDB by
calling Windows functions via the API.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Stephen Lebans]

Copied and saved...thanks Dirk!

 

[Dymondjack]

Thanks for the input guys... good food for thought. And thanks for the code
Dirk, I expect to implement that pretty soon