How can I determine filetype/extension of files stored in OLE fields?

[Keith Brown]

I have an application that allows embedded storage of ANY chosen file
in an OLE field. The file could have been dragged-and-dropped into
the field or it might have been selected and imported programmaticall y
using the common file dialog. Regardless, I need to determine the
filetype/extension of each of these files already stored in my OLE
fields and display it for the user.

Double-clicking the raw OLE field or using the
.Verb = acOLEVerbOpen
.Action = acOLEActivate
methods will launch whatever application is associated with the type
of file stored in the OLE field, so, somehow, that information (.XLS,
..DOC, .MPG, .PDF, etc.) must be available -- but where? I want to be
able to list, in a form, my records that contain the OLE fields along
with other info describing the OLE contents, such as size (obtainable
via the FileSize function). Is there a way for me to get at the file
extension as well?

Thanks for any help you can offer!

[TC]

Re: How can I determine filetype/extension of files stored in OLE fields?

The fact that it can launch the appropriate application, does not
necessarily mean that it knows the name of the original file. It might just
be storing a so-called ProgID, eg. "Excel.Applicat ion". That is enough to
identify the relevant application. If the object is embedded - not linked -
I doubt that the name of the original file is stored, at all.

HTH,
TC


"Keith Brown" <ksbrown@one.ne t> wrote in message
news:3cc9bca3.0 310271211.50ac7 45f@posting.goo gle.com...[color=blue]
> I have an application that allows embedded storage of ANY chosen file
> in an OLE field. The file could have been dragged-and-dropped into
> the field or it might have been selected and imported programmaticall y
> using the common file dialog. Regardless, I need to determine the
> filetype/extension of each of these files already stored in my OLE
> fields and display it for the user.
>
> Double-clicking the raw OLE field or using the
> .Verb = acOLEVerbOpen
> .Action = acOLEActivate
> methods will launch whatever application is associated with the type
> of file stored in the OLE field, so, somehow, that information (.XLS,
> .DOC, .MPG, .PDF, etc.) must be available -- but where? I want to be
> able to list, in a form, my records that contain the OLE fields along
> with other info describing the OLE contents, such as size (obtainable
> via the FileSize function). Is there a way for me to get at the file
> extension as well?
>
> Thanks for any help you can offer![/color]

[Keith Brown]

Re: How can I determine filetype/extension of files stored in OLE fields?

"TC" <a@b.c.d> wrote in message news:<106731317 0.971034@teutho s>...[color=blue]
> The fact that it can launch the appropriate application, does not
> necessarily mean that it knows the name of the original file. It might just
> be storing a so-called ProgID, eg. "Excel.Applicat ion". That is enough to
> identify the relevant application. If the object is embedded - not linked -
> I doubt that the name of the original file is stored, at all.[/color]

Right. I figured the full filename was no longer available and really
have no need for it. The ProgID you refer to might even be better
than an extension, since it spells out the actual name of the
associated application. I would be pretty happy if someone could show
me some code that could produce either one! Thanks for your response.

[Terry Kreft]

Re: How can I determine filetype/extension of files stored in OLE fields?

If you look at what's actually in the field you'll find that it contains the
filename and the full (short) path to the file.

So a nasty first stab at code to get this info could look like this

Function PathFromOLEFiel d()
Dim loDb As DAO.Database
Dim loRst As DAO.Recordset
Dim loFld As DAO.Field
Dim varChunk As Variant
Dim lngCount As Long
Dim strRet As String
Dim strFile As String
Dim strPath As String
Dim intInstr As Integer

Set loDb = Access.CurrentD b
Set loRst = loDb.OpenRecord set("Table1")
Set loFld = loRst.Fields("H mmm")
Do Until loRst.EOF
varChunk = loFld.GetChunk( 70, 500)
strRet = ""
For lngCount = LBound(varChunk ) To UBound(varChunk )
strRet = strRet & Chr(varChunk(ln gCount))
Next
intInstr = InStr(strRet, Chr(0))
strFile = Left(strRet, intInstr - 1)
strRet = Mid(strRet, intInstr + 1)
intInstr = InStr(strRet, Chr(0) & Chr(0))
strPath = Left(strRet, intInstr - 1)
Debug.Print strFile
Debug.Print strPath
loRst.MoveNext
Loop
Set loFld = Nothing
loRst.Close
Set loRst = Nothing
Set loDb = Nothing
End Function



Terry

"Keith Brown" <ksbrown@one.ne t> wrote in message
news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...[color=blue]
> "TC" <a@b.c.d> wrote in message news:<106731317 0.971034@teutho s>...[color=green]
> > The fact that it can launch the appropriate application, does not
> > necessarily mean that it knows the name of the original file. It might[/color][/color]
just[color=blue][color=green]
> > be storing a so-called ProgID, eg. "Excel.Applicat ion". That is enough[/color][/color]
to[color=blue][color=green]
> > identify the relevant application. If the object is embedded - not[/color][/color]
linked -[color=blue][color=green]
> > I doubt that the name of the original file is stored, at all.[/color]
>
> Right. I figured the full filename was no longer available and really
> have no need for it. The ProgID you refer to might even be better
> than an extension, since it spells out the actual name of the
> associated application. I would be pretty happy if someone could show
> me some code that could produce either one! Thanks for your response.[/color]

[Keith Brown]

Re: How can I determine filetype/extension of files stored in OLE fields?

Terry,

Thanks so much for posting the code. I tried it out and,
unfortunately, was not able to get anything intelligible as output.
(The filename value [strFile] for each field was displaying as ".8"
and the pathname was empty.) Is it possible your code is what one
would use to display the contents of an OLE field containing a link to
a file, rather than a complete embedded file? All of my OLE fields
contain embedded files ONLY.

Keith

[TC]

Re: How can I determine filetype/extension of files stored in OLE fields?

Where do the 70 & 500 come from? (getchunk 70,500)

TC


"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
news:bnm210$ebs $1@newsreaderg1 .core.theplanet .net...[color=blue]
> If you look at what's actually in the field you'll find that it contains[/color]
the[color=blue]
> filename and the full (short) path to the file.
>
> So a nasty first stab at code to get this info could look like this
>
> Function PathFromOLEFiel d()
> Dim loDb As DAO.Database
> Dim loRst As DAO.Recordset
> Dim loFld As DAO.Field
> Dim varChunk As Variant
> Dim lngCount As Long
> Dim strRet As String
> Dim strFile As String
> Dim strPath As String
> Dim intInstr As Integer
>
> Set loDb = Access.CurrentD b
> Set loRst = loDb.OpenRecord set("Table1")
> Set loFld = loRst.Fields("H mmm")
> Do Until loRst.EOF
> varChunk = loFld.GetChunk( 70, 500)
> strRet = ""
> For lngCount = LBound(varChunk ) To UBound(varChunk )
> strRet = strRet & Chr(varChunk(ln gCount))
> Next
> intInstr = InStr(strRet, Chr(0))
> strFile = Left(strRet, intInstr - 1)
> strRet = Mid(strRet, intInstr + 1)
> intInstr = InStr(strRet, Chr(0) & Chr(0))
> strPath = Left(strRet, intInstr - 1)
> Debug.Print strFile
> Debug.Print strPath
> loRst.MoveNext
> Loop
> Set loFld = Nothing
> loRst.Close
> Set loRst = Nothing
> Set loDb = Nothing
> End Function
>
>
>
> Terry
>
> "Keith Brown" <ksbrown@one.ne t> wrote in message
> news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...[color=green]
> > "TC" <a@b.c.d> wrote in message news:<106731317 0.971034@teutho s>...[color=darkred]
> > > The fact that it can launch the appropriate application, does not
> > > necessarily mean that it knows the name of the original file. It might[/color][/color]
> just[color=green][color=darkred]
> > > be storing a so-called ProgID, eg. "Excel.Applicat ion". That is enough[/color][/color]
> to[color=green][color=darkred]
> > > identify the relevant application. If the object is embedded - not[/color][/color]
> linked -[color=green][color=darkred]
> > > I doubt that the name of the original file is stored, at all.[/color]
> >
> > Right. I figured the full filename was no longer available and really
> > have no need for it. The ProgID you refer to might even be better
> > than an extension, since it spells out the actual name of the
> > associated application. I would be pretty happy if someone could show
> > me some code that could produce either one! Thanks for your response.[/color]
>
>[/color]

[Terry Kreft]

Re: How can I determine filetype/extension of files stored in OLE fields?


No I wrote it using embedded files.

I did a test on it with 3 different file types (*..txt, *.zip and *.mdb) and
it works for each of these.

What file type are you embedding?

Terry



"Keith Brown" <ksbrown@one.ne t> wrote in message
news:3cc9bca3.0 310281034.1a894 5af@posting.goo gle.com...[color=blue]
> Terry,
>
> Thanks so much for posting the code. I tried it out and,
> unfortunately, was not able to get anything intelligible as output.
> (The filename value [strFile] for each field was displaying as ".8"
> and the pathname was empty.) Is it possible your code is what one
> would use to display the contents of an OLE field containing a link to
> a file, rather than a complete embedded file? All of my OLE fields
> contain embedded files ONLY.
>
> Keith[/color]

[Terry Kreft]

Re: How can I determine filetype/extension of files stored in OLE fields?

Empiricism.

By grabbing a number of different records I observed that:-
1) the filename consistently appeared at byte 70
2) the filename was terminated with a single Null character (Chr(0))
3) the filename was followed by the full path terminated by a pair of
Null characters.
4) the path was in short form and therefore the length of the path plus
file path are
unlikely to exceed 500 bytes (520 (2 * MAX_PATH ) would have been a
better bet)

but as I say it's dirty code. Which means it shows a principle.

Terry


"TC" <a@b.c.d> wrote in message news:1067394655 .92126@teuthos. ..[color=blue]
> Where do the 70 & 500 come from? (getchunk 70,500)
>
> TC
>
>
> "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> news:bnm210$ebs $1@newsreaderg1 .core.theplanet .net...[color=green]
> > If you look at what's actually in the field you'll find that it contains[/color]
> the[color=green]
> > filename and the full (short) path to the file.
> >
> > So a nasty first stab at code to get this info could look like this
> >
> > Function PathFromOLEFiel d()
> > Dim loDb As DAO.Database
> > Dim loRst As DAO.Recordset
> > Dim loFld As DAO.Field
> > Dim varChunk As Variant
> > Dim lngCount As Long
> > Dim strRet As String
> > Dim strFile As String
> > Dim strPath As String
> > Dim intInstr As Integer
> >
> > Set loDb = Access.CurrentD b
> > Set loRst = loDb.OpenRecord set("Table1")
> > Set loFld = loRst.Fields("H mmm")
> > Do Until loRst.EOF
> > varChunk = loFld.GetChunk( 70, 500)
> > strRet = ""
> > For lngCount = LBound(varChunk ) To UBound(varChunk )
> > strRet = strRet & Chr(varChunk(ln gCount))
> > Next
> > intInstr = InStr(strRet, Chr(0))
> > strFile = Left(strRet, intInstr - 1)
> > strRet = Mid(strRet, intInstr + 1)
> > intInstr = InStr(strRet, Chr(0) & Chr(0))
> > strPath = Left(strRet, intInstr - 1)
> > Debug.Print strFile
> > Debug.Print strPath
> > loRst.MoveNext
> > Loop
> > Set loFld = Nothing
> > loRst.Close
> > Set loRst = Nothing
> > Set loDb = Nothing
> > End Function
> >
> >
> >
> > Terry
> >
> > "Keith Brown" <ksbrown@one.ne t> wrote in message
> > news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...[color=darkred]
> > > "TC" <a@b.c.d> wrote in message news:<106731317 0.971034@teutho s>...
> > > > The fact that it can launch the appropriate application, does not
> > > > necessarily mean that it knows the name of the original file. It[/color][/color][/color]
might[color=blue][color=green]
> > just[color=darkred]
> > > > be storing a so-called ProgID, eg. "Excel.Applicat ion". That is[/color][/color][/color]
enough[color=blue][color=green]
> > to[color=darkred]
> > > > identify the relevant application. If the object is embedded - not[/color]
> > linked -[color=darkred]
> > > > I doubt that the name of the original file is stored, at all.
> > >
> > > Right. I figured the full filename was no longer available and really
> > > have no need for it. The ProgID you refer to might even be better
> > > than an extension, since it spells out the actual name of the
> > > associated application. I would be pretty happy if someone could show
> > > me some code that could produce either one! Thanks for your response.[/color]
> >
> >[/color]
>
>[/color]

[TC]

Re: How can I determine filetype/extension of files stored in OLE fields?


"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
news:bnooak$p5a $1@newsreaderm1 .core.theplanet .net...[color=blue]
> Empiricism.
>
> By grabbing a number of different records I observed that:-
> 1) the filename consistently appeared at byte 70
> 2) the filename was terminated with a single Null character (Chr(0))
> 3) the filename was followed by the full path terminated by a pair of
> Null characters.
> 4) the path was in short form and therefore the length of the path plus
> file path are
> unlikely to exceed 500 bytes (520 (2 * MAX_PATH ) would have been a
> better bet)
>
> but as I say it's dirty code. Which means it shows a principle.[/color]

Maybe! But there is tons of dirty space inside many MS file structures. So
the appearance of particular data, at a particular place, on a few
occasions, could easily arise from random causes.

TC

[color=blue]
>
> Terry
>
>
> "TC" <a@b.c.d> wrote in message news:1067394655 .92126@teuthos. ..[color=green]
> > Where do the 70 & 500 come from? (getchunk 70,500)
> >
> > TC
> >
> >
> > "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> > news:bnm210$ebs $1@newsreaderg1 .core.theplanet .net...[color=darkred]
> > > If you look at what's actually in the field you'll find that it[/color][/color][/color]
contains[color=blue][color=green]
> > the[color=darkred]
> > > filename and the full (short) path to the file.
> > >
> > > So a nasty first stab at code to get this info could look like this
> > >
> > > Function PathFromOLEFiel d()
> > > Dim loDb As DAO.Database
> > > Dim loRst As DAO.Recordset
> > > Dim loFld As DAO.Field
> > > Dim varChunk As Variant
> > > Dim lngCount As Long
> > > Dim strRet As String
> > > Dim strFile As String
> > > Dim strPath As String
> > > Dim intInstr As Integer
> > >
> > > Set loDb = Access.CurrentD b
> > > Set loRst = loDb.OpenRecord set("Table1")
> > > Set loFld = loRst.Fields("H mmm")
> > > Do Until loRst.EOF
> > > varChunk = loFld.GetChunk( 70, 500)
> > > strRet = ""
> > > For lngCount = LBound(varChunk ) To UBound(varChunk )
> > > strRet = strRet & Chr(varChunk(ln gCount))
> > > Next
> > > intInstr = InStr(strRet, Chr(0))
> > > strFile = Left(strRet, intInstr - 1)
> > > strRet = Mid(strRet, intInstr + 1)
> > > intInstr = InStr(strRet, Chr(0) & Chr(0))
> > > strPath = Left(strRet, intInstr - 1)
> > > Debug.Print strFile
> > > Debug.Print strPath
> > > loRst.MoveNext
> > > Loop
> > > Set loFld = Nothing
> > > loRst.Close
> > > Set loRst = Nothing
> > > Set loDb = Nothing
> > > End Function
> > >
> > >
> > >
> > > Terry
> > >
> > > "Keith Brown" <ksbrown@one.ne t> wrote in message
> > > news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...
> > > > "TC" <a@b.c.d> wrote in message news:<106731317 0.971034@teutho s>...
> > > > > The fact that it can launch the appropriate application, does not
> > > > > necessarily mean that it knows the name of the original file. It[/color][/color]
> might[color=green][color=darkred]
> > > just
> > > > > be storing a so-called ProgID, eg. "Excel.Applicat ion". That is[/color][/color]
> enough[color=green][color=darkred]
> > > to
> > > > > identify the relevant application. If the object is embedded - not
> > > linked -
> > > > > I doubt that the name of the original file is stored, at all.
> > > >
> > > > Right. I figured the full filename was no longer available and[/color][/color][/color]
really[color=blue][color=green][color=darkred]
> > > > have no need for it. The ProgID you refer to might even be better
> > > > than an extension, since it spells out the actual name of the
> > > > associated application. I would be pretty happy if someone could[/color][/color][/color]
show[color=blue][color=green][color=darkred]
> > > > me some code that could produce either one! Thanks for your[/color][/color][/color]
response.[color=blue][color=green][color=darkred]
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Terry Kreft]

Re: How can I determine filetype/extension of files stored in OLE fields?

If you're trying to start an argument then go ahead, you're only arguing
with yourself.

I refer you back to my original posting.

Take note of the phrase "... a nasty first stab at code ..." .

This was meant to imply that
1) the code cited was not tested to any great degree but that it did
work on the tests carried out.
2) it would need work on it to polish and improve it , even to possibly
disprove it as a method.

Of course if you are in the know on how an OLE Object field in Access stores
the object and the relevant references to it then go ahead and enlighten us,
otherwise we're stuck with the empirical approach.


Terry



"TC" <a@b.c.d> wrote in message news:1067475808 .597311@teuthos ...[color=blue]
>
> "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> news:bnooak$p5a $1@newsreaderm1 .core.theplanet .net...[color=green]
> > Empiricism.
> >
> > By grabbing a number of different records I observed that:-
> > 1) the filename consistently appeared at byte 70
> > 2) the filename was terminated with a single Null character (Chr(0))
> > 3) the filename was followed by the full path terminated by a pair of
> > Null characters.
> > 4) the path was in short form and therefore the length of the path[/color][/color]
plus[color=blue][color=green]
> > file path are
> > unlikely to exceed 500 bytes (520 (2 * MAX_PATH ) would have been[/color][/color]
a[color=blue][color=green]
> > better bet)
> >
> > but as I say it's dirty code. Which means it shows a principle.[/color]
>
> Maybe! But there is tons of dirty space inside many MS file structures. So
> the appearance of particular data, at a particular place, on a few
> occasions, could easily arise from random causes.
>
> TC
>
>[color=green]
> >
> > Terry
> >
> >
> > "TC" <a@b.c.d> wrote in message news:1067394655 .92126@teuthos. ..[color=darkred]
> > > Where do the 70 & 500 come from? (getchunk 70,500)
> > >
> > > TC
> > >
> > >
> > > "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> > > news:bnm210$ebs $1@newsreaderg1 .core.theplanet .net...
> > > > If you look at what's actually in the field you'll find that it[/color][/color]
> contains[color=green][color=darkred]
> > > the
> > > > filename and the full (short) path to the file.
> > > >
> > > > So a nasty first stab at code to get this info could look like this
> > > >
> > > > Function PathFromOLEFiel d()
> > > > Dim loDb As DAO.Database
> > > > Dim loRst As DAO.Recordset
> > > > Dim loFld As DAO.Field
> > > > Dim varChunk As Variant
> > > > Dim lngCount As Long
> > > > Dim strRet As String
> > > > Dim strFile As String
> > > > Dim strPath As String
> > > > Dim intInstr As Integer
> > > >
> > > > Set loDb = Access.CurrentD b
> > > > Set loRst = loDb.OpenRecord set("Table1")
> > > > Set loFld = loRst.Fields("H mmm")
> > > > Do Until loRst.EOF
> > > > varChunk = loFld.GetChunk( 70, 500)
> > > > strRet = ""
> > > > For lngCount = LBound(varChunk ) To UBound(varChunk )
> > > > strRet = strRet & Chr(varChunk(ln gCount))
> > > > Next
> > > > intInstr = InStr(strRet, Chr(0))
> > > > strFile = Left(strRet, intInstr - 1)
> > > > strRet = Mid(strRet, intInstr + 1)
> > > > intInstr = InStr(strRet, Chr(0) & Chr(0))
> > > > strPath = Left(strRet, intInstr - 1)
> > > > Debug.Print strFile
> > > > Debug.Print strPath
> > > > loRst.MoveNext
> > > > Loop
> > > > Set loFld = Nothing
> > > > loRst.Close
> > > > Set loRst = Nothing
> > > > Set loDb = Nothing
> > > > End Function
> > > >
> > > >
> > > >
> > > > Terry
> > > >
> > > > "Keith Brown" <ksbrown@one.ne t> wrote in message
> > > > news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...
> > > > > "TC" <a@b.c.d> wrote in message[/color][/color][/color]
news:<106731317 0.971034@teutho s>...[color=blue][color=green][color=darkred]
> > > > > > The fact that it can launch the appropriate application, does[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > > > > necessarily mean that it knows the name of the original file. It[/color]
> > might[color=darkred]
> > > > just
> > > > > > be storing a so-called ProgID, eg. "Excel.Applicat ion". That is[/color]
> > enough[color=darkred]
> > > > to
> > > > > > identify the relevant application. If the object is embedded -[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> > > > linked -
> > > > > > I doubt that the name of the original file is stored, at all.
> > > > >
> > > > > Right. I figured the full filename was no longer available and[/color][/color]
> really[color=green][color=darkred]
> > > > > have no need for it. The ProgID you refer to might even be better
> > > > > than an extension, since it spells out the actual name of the
> > > > > associated application. I would be pretty happy if someone could[/color][/color]
> show[color=green][color=darkred]
> > > > > me some code that could produce either one! Thanks for your[/color][/color]
> response.[color=green][color=darkred]
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Keith Brown]

Re: How can I determine filetype/extension of files stored in OLE fields?

"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message news:<bnoniq$os 7$1@newsreaderm 1.core.theplane t.net>...[color=blue]
> I did a test on it with 3 different file types (*..txt, *.zip and *.mdb) and
> it works for each of these.
> What file type are you embedding?[/color]

The purpose of the app is to allow the users to embed ANY type. The
records I tested contained (I am pretty sure) Microsoft Word .doc
files. I will set up a test using the types that seemed to give good
results for you and see what happens!

Thanks for the time you have put into this. (By the way, it seems
pretty clear to me that, in the absence of documentation from
Microsoft, all we are left with is empirical data.)

Keith

[TC]

Re: How can I determine filetype/extension of files stored in OLE fields?

HUH?

Bye.

TC


"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
news:bnqng4$3be $1@newsreaderg1 .core.theplanet .net...[color=blue]
> If you're trying to start an argument then go ahead, you're only arguing
> with yourself.
>
> I refer you back to my original posting.
>
> Take note of the phrase "... a nasty first stab at code ..." .
>
> This was meant to imply that
> 1) the code cited was not tested to any great degree but that it did
> work on the tests carried out.
> 2) it would need work on it to polish and improve it , even to[/color]
possibly[color=blue]
> disprove it as a method.
>
> Of course if you are in the know on how an OLE Object field in Access[/color]
stores[color=blue]
> the object and the relevant references to it then go ahead and enlighten[/color]
us,[color=blue]
> otherwise we're stuck with the empirical approach.
>
>
> Terry
>
>
>
> "TC" <a@b.c.d> wrote in message news:1067475808 .597311@teuthos ...[color=green]
> >
> > "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> > news:bnooak$p5a $1@newsreaderm1 .core.theplanet .net...[color=darkred]
> > > Empiricism.
> > >
> > > By grabbing a number of different records I observed that:-
> > > 1) the filename consistently appeared at byte 70
> > > 2) the filename was terminated with a single Null character[/color][/color][/color]
(Chr(0))[color=blue][color=green][color=darkred]
> > > 3) the filename was followed by the full path terminated by a pair[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > Null characters.
> > > 4) the path was in short form and therefore the length of the path[/color][/color]
> plus[color=green][color=darkred]
> > > file path are
> > > unlikely to exceed 500 bytes (520 (2 * MAX_PATH ) would have[/color][/color][/color]
been[color=blue]
> a[color=green][color=darkred]
> > > better bet)
> > >
> > > but as I say it's dirty code. Which means it shows a principle.[/color]
> >
> > Maybe! But there is tons of dirty space inside many MS file structures.[/color][/color]
So[color=blue][color=green]
> > the appearance of particular data, at a particular place, on a few
> > occasions, could easily arise from random causes.
> >
> > TC
> >
> >[color=darkred]
> > >
> > > Terry
> > >
> > >
> > > "TC" <a@b.c.d> wrote in message news:1067394655 .92126@teuthos. ..
> > > > Where do the 70 & 500 come from? (getchunk 70,500)
> > > >
> > > > TC
> > > >
> > > >
> > > > "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> > > > news:bnm210$ebs $1@newsreaderg1 .core.theplanet .net...
> > > > > If you look at what's actually in the field you'll find that it[/color]
> > contains[color=darkred]
> > > > the
> > > > > filename and the full (short) path to the file.
> > > > >
> > > > > So a nasty first stab at code to get this info could look like[/color][/color][/color]
this[color=blue][color=green][color=darkred]
> > > > >
> > > > > Function PathFromOLEFiel d()
> > > > > Dim loDb As DAO.Database
> > > > > Dim loRst As DAO.Recordset
> > > > > Dim loFld As DAO.Field
> > > > > Dim varChunk As Variant
> > > > > Dim lngCount As Long
> > > > > Dim strRet As String
> > > > > Dim strFile As String
> > > > > Dim strPath As String
> > > > > Dim intInstr As Integer
> > > > >
> > > > > Set loDb = Access.CurrentD b
> > > > > Set loRst = loDb.OpenRecord set("Table1")
> > > > > Set loFld = loRst.Fields("H mmm")
> > > > > Do Until loRst.EOF
> > > > > varChunk = loFld.GetChunk( 70, 500)
> > > > > strRet = ""
> > > > > For lngCount = LBound(varChunk ) To UBound(varChunk )
> > > > > strRet = strRet & Chr(varChunk(ln gCount))
> > > > > Next
> > > > > intInstr = InStr(strRet, Chr(0))
> > > > > strFile = Left(strRet, intInstr - 1)
> > > > > strRet = Mid(strRet, intInstr + 1)
> > > > > intInstr = InStr(strRet, Chr(0) & Chr(0))
> > > > > strPath = Left(strRet, intInstr - 1)
> > > > > Debug.Print strFile
> > > > > Debug.Print strPath
> > > > > loRst.MoveNext
> > > > > Loop
> > > > > Set loFld = Nothing
> > > > > loRst.Close
> > > > > Set loRst = Nothing
> > > > > Set loDb = Nothing
> > > > > End Function
> > > > >
> > > > >
> > > > >
> > > > > Terry
> > > > >
> > > > > "Keith Brown" <ksbrown@one.ne t> wrote in message
> > > > > news:3cc9bca3.0 310280703.13a6d e9b@posting.goo gle.com...
> > > > > > "TC" <a@b.c.d> wrote in message[/color][/color]
> news:<106731317 0.971034@teutho s>...[color=green][color=darkred]
> > > > > > > The fact that it can launch the appropriate application, does[/color][/color]
> not[color=green][color=darkred]
> > > > > > > necessarily mean that it knows the name of the original file.[/color][/color][/color]
It[color=blue][color=green][color=darkred]
> > > might
> > > > > just
> > > > > > > be storing a so-called ProgID, eg. "Excel.Applicat ion". That[/color][/color][/color]
is[color=blue][color=green][color=darkred]
> > > enough
> > > > > to
> > > > > > > identify the relevant application. If the object is embedded -[/color][/color]
> not[color=green][color=darkred]
> > > > > linked -
> > > > > > > I doubt that the name of the original file is stored, at all.
> > > > > >
> > > > > > Right. I figured the full filename was no longer available and[/color]
> > really[color=darkred]
> > > > > > have no need for it. The ProgID you refer to might even be[/color][/color][/color]
better[color=blue][color=green][color=darkred]
> > > > > > than an extension, since it spells out the actual name of the
> > > > > > associated application. I would be pretty happy if someone[/color][/color][/color]
could[color=blue][color=green]
> > show[color=darkred]
> > > > > > me some code that could produce either one! Thanks for your[/color]
> > response.[color=darkred]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Lyle Fairfield]

Re: How can I determine filetype/extension of files stored in OLE fields?

"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in news:bnooak$p5a $1
@newsreaderm1.c ore.theplanet.n et:
[color=blue]
> Empiricism.[/color]

Empiricism suggests (to me) we can obtain terms such as

Package
Photo Editor Photo
Worksheet

by grabbing the string bounded by the first
string of 4 consecutive 255s
and the first following null character.

I used ado and the value as a byte array to look at this ...
as below ... (for the nillions who might be interested)

Sub temp()
Dim p(1) As Long
Dim r As ADODB.Recordset
Dim s As String
Dim v As Variant
Set r = New ADODB.Recordset
With r
.CursorType = adOpenStatic
.LockType = adLockReadOnly
.Open "SELECT * FROM Table1", CurrentProject. Connection
If .BOF Then
MsgBox "No Records"
Exit Sub
End If
Do While Not .EOF
s = ""
p(0) = 0
p(1) = 0
For Each v In .Fields(0).Valu e
s = s & Chr$(v)
p(0) = InStr(1, s, String(4, Chr$(255)))
If p(0) <> 0 Then p(1) = InStr(p(0), s, vbNullChar)
If p(1) <> 0 Then Exit For
Next v
Debug.Print Mid(s, p(0) + 4, p(1) - p(0))
.MoveNext
Loop
End With
End Sub

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[TC]

Re: How can I determine filetype/extension of files stored in OLE fields?


Keith Brown <ksbrown@one.ne t> wrote in message
news:3cc9bca3.0 310301450.4b36a 25d@posting.goo gle.com...[color=blue]
> "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message[/color]
news:<bnoniq$os 7$1@newsreaderm 1.core.theplane t.net>...[color=blue][color=green]
> > I did a test on it with 3 different file types (*..txt, *.zip and *.mdb)[/color][/color]
and[color=blue][color=green]
> > it works for each of these.
> > What file type are you embedding?[/color]
>
> The purpose of the app is to allow the users to embed ANY type. The
> records I tested contained (I am pretty sure) Microsoft Word .doc
> files. I will set up a test using the types that seemed to give good
> results for you and see what happens!
>
> Thanks for the time you have put into this. (By the way, it seems
> pretty clear to me that, in the absence of documentation from
> Microsoft, all we are left with is empirical data.)[/color]


Why do you say there is no documentation? It is probably just MS "structured
storage".

TC

[Stephen Lebans]

Re: How can I determine filetype/extension of files stored in OLE fields?


"TC" <a@b.c.d> wrote in message news:1067590381 .686524@teuthos ...[color=blue]
>
> Keith Brown <ksbrown@one.ne t> wrote in message
> news:3cc9bca3.0 310301450.4b36a 25d@posting.goo gle.com...[color=green]
> > "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message[/color]
> news:<bnoniq$os 7$1@newsreaderm 1.core.theplane t.net>...[color=green][color=darkred]
> > > I did a test on it with 3 different file types (*..txt, *.zip and[/color][/color][/color]
*.mdb)[color=blue]
> and[color=green][color=darkred]
> > > it works for each of these.
> > > What file type are you embedding?[/color]
> >
> > The purpose of the app is to allow the users to embed ANY type. The
> > records I tested contained (I am pretty sure) Microsoft Word .doc
> > files. I will set up a test using the types that seemed to give[/color][/color]
good[color=blue][color=green]
> > results for you and see what happens!
> >
> > Thanks for the time you have put into this. (By the way, it seems
> > pretty clear to me that, in the absence of documentation from
> > Microsoft, all we are left with is empirical data.)[/color]
>
>
> Why do you say there is no documentation? It is probably just MS[/color]
"structured[color=blue]
> storage".
>
> TC
>
>[/color]

There is no publicly available information regarding the file format of
OLE embedded files. If you know otherwise please post the info here.
AFAIK there are suggested guidelines but that's it.
The OLE server can write the object to file basically any way it wants
to. As long as the server responds to the requests from the host
container it does not matter how the data is stored.

--

Stephen Lebans

http://www.lebans.com

Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.