does anyone know how to check if a network path like
\\SomeComputer\SomeDirectory is available ? With files or local directories
i used the "Dir" function
to check that. If it returns "" then the file isnt there. But when i pass a
network path instead, i keep getting "Runtime Error 52" which indicates i
spelled the path / filename wrong but obviously that isnt the case.
And yes i checked in explorer, the networked computer is available and so is
the path.

Any ideas ? Thanks in advance !

Marshal

Public Function OkToWrite(ThisPath As String) As Boolean
Dim fso As New FileSystemObject, CanWrite As Boolean, PathArray As
Variant, _
    ThisFolder As String, Index As Variant

'trap empty string
If ThisPath = "" Then
OkToWrite = True
Exit Function
End If

CanWrite = True

PathArray = Split(ThisPath, "\")

'check drive exits

If fso.DriveExists(PathArray(0)) Then GoTo CheckFolder
CanWrite = False
Call MsgBox("textThing couldn't find the drive you are trying to write
to in " & vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")
GoTo Failed

'create folder string
CheckFolder:
ThisFolder = ""
For Each Index In PathArray
If InStr(Index, ".") < 1 Then ThisFolder = ThisFolder & Index & "\"
Next

'check folder exists

If fso.FolderExists(ThisFolder) Then GoTo CheckFolderPermission
CanWrite = False
Call MsgBox("textThing couldn't find the folder you are trying to
write to in " & vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")
GoTo Failed

'check write permission for folder
CheckFolderPermission:
Debug.Print "CheckFolderPermission",
fso.GetFolder(ThisFolder).Attributes = ReadOnly
Debug.Print "CheckFolderPermission",
fso.GetFolder(ThisFolder).Attributes And ReadOnly
If (fso.GetFolder(ThisFolder).Attributes And ReadOnly) = 0 Then GoTo
CheckFilePermission
CanWrite = False
Call MsgBox("The folder you are trying to write to is read only " &
vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")
GoTo Failed

'check write permission for file
CheckFilePermission:
'check it's actually a file
If InStr(ThisPath, ".") < 1 Then GoTo Failed
'check to see if it exists
' if not, don't test
If Not fso.FileExists(ThisPath) Then GoTo Failed
'test write
If (fso.GetFile(ThisPath).Attributes And ReadOnly) = 0 Then GoTo
Failed
CanWrite = False
Call MsgBox("The file you are trying to write to is read only " &
vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")

Failed:
OkToWrite = CanWrite

End Function

Public Function OkToRead(ThisPath As String) As Boolean
Dim fso As New FileSystemObject, CanRead As Boolean, PathArray As
Variant, _
    ThisFolder As String, Index As Variant

CanRead = True

PathArray = Split(ThisPath, "\")
'check drive exits
If fso.DriveExists(PathArray(0)) Then GoTo CheckFile
CanRead = False
Call MsgBox("textThing couldn't find the drive you are trying to read
from: " & vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")
GoTo Failed

'check file exists
CheckFile:
If fso.FileExists(ThisPath) Then GoTo Failed
CanRead = False
Call MsgBox("textThing couldn't find the file you are trying to read
from: " & vbCrLf & ThisPath, _
    vbExclamation, "textThing file problem")

Failed:
OkToRead = CanRead

BTW - what makes you think a Filename has to contain '.'  ?

<snip>

Hey thanks, thats great. I had allready found out about the filesystem
object
myself but your code is way more advanced than what i had in mind :) I am
going to merge it with my code that checks for filename validity and then i
should be fine. Thx for your help.

Anyone who cannot *write* a FSO is a pillock
- anyone who uses it is a fool
- since most people with any sense turn it off.

could you please tell me what exactly you are talking about ? If you
dont like all the comfort that such a high high high high level
language like vb has to offer then why arent you programming in
assembler ONLY ? Or pure binary input maybe ?

I for myself am only using this "language" because i have to. Its
my work and if my boss wants me to code in vb then i have no choice.
I am using c/c++ for about 4 years now and am having NO problems
implementing anything i like in my code. (While still using API calls
or MFC instead of reinventing the wheel time and again).

No i had to use this vb stuff for about a week. The only source of
help i got was that "limited" integrated help system and this ng.
Thats why i dont consider myself a fool just because i use a FSO
or whatever and i have not (yet) been de-skilled by M$.

Oh but if your are that kind of code god *G* that you seem to be why
dont you tell me how to do it the "right" way. Because having no
literature available at work, i think i will never get much better
using trial, error and the online help :/ Yeah sure and my brain...

cya
   Johnny

P.S.: Sorry but i am just that type of fool that allways thinks he
      has to defend himself even if its as pointless as it is in

It does very little more than one can do with pure VB - and just as
simply.

True I do like writing in pure ASM - unfortunately there is little
need for that nowadays. It is useful to know what is going on 'under
the hood'.

It might be an idea for you to check out what other programmers on the
NGs think of the FSO - you could find that you change your mind.

We all know that sometimes time pressures will force us to do dodgy
stuff to get the code done.. but we should do that with the knowledge
that we are indeed not writing the best code we could.

Public Funtion GetPathAvail(uncPath As String) As Boolean
On Error Resume Next
ret = GetAttr(uncPath)
If Not Err Then _
        GetPathAvail = ret And vbDirectory = vbDirectory
End If

I haven't tested this, but let us know if it works. :)
And stick around, this is good place to learn from.

Ps: No offence intended calling you a "newbie", Newbie.   ;-)

Frank's example of using GetAttr to check the existence of a directory
is the best method I have found - from years before Windows

A variation on it is the way to check for the existence of a File.

The code that you put up would have looked better as :-

    Sub CheckFile( FileName$, Erm$ )
           Dim Drive$, Path$

           Erm$ = ""  

           Drive$ = ExtractFileDrive( FileName$ )
           If DriveExists( FileName$ ) = False Then
              Erm$ = "Drive " + Drive$ + " does not exist"
              Exit Sub
           End If

           If DriveReady( Drive$ ) = False Then
              Erm$ = "Drive " +  Drive$ + " is not ready"
              Exit Sub
           End if

           Path = ExtractFilePath( FileName$ )    
           etc      

Like this you have a number of generic functions that you only ever
need to write once - you also produce simple and easy to read code.

Notice that there is no error handling - that is because it is all
tucked away inside the Functions.

I personally am not a fanatic about the use of Goto - or rather
avoiding the use of Goto - however it makes a great deal of sense to
*avoid* using it - if it does not *simplify* code.

You'll also note how the Error message is passed out of the routine as
a string - this means that you only have one MsgBox for the whole
routine - very handy if you want to log errors to a file - also handy
for 'customizing' the display of error messages.

There is another good reason for not using the FSO - it is one more
component that has to be distributed

- in general it is wise to keep down the number of OCXes and third
party DLLs that need distribution - the phrase 'DLL Hell' turns up
frequently in these NGs

We all 'cludge' code occasionally - but in general it makes quite a
lot of sense to write code as if someone else is going to review it.

It means that one takes a little longer - but usually this saves time
in the medium (let alone the long) term.

One further point - some people say that there is no point in
'reinventing the wheel' - that would be true if it were not for the
fact that most 'wheels' are pretty hooky.

If you write your own 'wheel' then you can re-use it and enhance it at
will - if you use someone else's then very often you spend more time
and effort finding out how it works - and building workarounds because
it does not do exactly what you need.

Boxing some File Handling in a Class makes a lot of sense - by
reading/writing large chunks one can obtain dramatic performance
improvements.  One can also simplify one's Application code.

One can knock up something that is really useful in minutes - it is
not writing code that takes the time - most of the problem is knowing
_what_ to write.

If you like some features of the FSO then by all means knick them -
doing that is not 're-inventing the wheel' it is making a 'wheel' that
suits you.

HTH

In all my projects, which have to be used across 11 servers in my firms wide
area network, I only use one (none 3rd party) OCX (I need the rich textbox).

I have had problems with date functions (DateDiff, DateAdd) not processing
dates correctly due to defaulting to US despite the machines Locales being
set to English (United Kingdom) and correct short and long date formats.
The users are a mix of Win 95, 98 & 2000 pro.

I wrote my own Public Functions (MyDateDiff, MyDateAdd) which take the same
parameters as the VB ones, but as my code does all the work inside them I
*know* they will function correctly whatever the locales are set to on the
users PC's.

The point I am trying to make is I can now as you say re-use this code all
over the place and more importantly I can trust it to work properly.  I
think the original poster needs to understand that if his code does not work
(or even worse, works incorrectly) telling the people at the top that it is
not his fault, it is Microsoft's OS/Functions/DLLs, will not get him very
far at all.  It may be true, but my employers want something that works, and
if it does not it is *my* problem and it better get fixed.

I don't use the FSO of course.

<snip>

Did you know that you can 'Out Scope' VB Functions/Procedures

Here is what I do to Val

' #####################################################
'
' 15/6/00 JF,
' ',' added 16/6/00 JF
' '&' Removed 23/6/00 JF (Hex)
'
Function Val(ByVal S$) As Double

    Call StrReplaceStr(S$, ",", "")
    Val = VBA.Val(S$)
End Function

The initial reason for 'out scoping' it was because VBA.Val can throw
an error on some numbers containing %

Later I was so fed up of having to remove ',' from numbers that I
decided to 'enhance' Val to do that for me.

Going back to the Dates stuff, there is a really strong case for
'outscoping' nearly all of VB's date routines.

The thing I love most is the simplicity of the solution.

Thanks again.