By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,456 Members | 1,390 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,456 IT Pros & Developers. It's quick & easy.

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

P: n/a
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 programmatically
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!
Nov 12 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
TC
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.Application". 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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
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 programmatically
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!

Nov 12 '05 #2

P: n/a
"TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>...
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.Application". 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.


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.
Nov 12 '05 #3

P: n/a
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 PathFromOLEField()
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.CurrentDb
Set loRst = loDb.OpenRecordset("Table1")
Set loFld = loRst.Fields("Hmmm")
Do Until loRst.EOF
varChunk = loFld.GetChunk(70, 500)
strRet = ""
For lngCount = LBound(varChunk) To UBound(varChunk)
strRet = strRet & Chr(varChunk(lngCount))
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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>...
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.Application". 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.


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.

Nov 12 '05 #4

P: n/a
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
Nov 12 '05 #5

P: n/a
TC
Where do the 70 & 500 come from? (getchunk 70,500)

TC
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderg1.core.theplanet.net. ..
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 PathFromOLEField()
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.CurrentDb
Set loRst = loDb.OpenRecordset("Table1")
Set loFld = loRst.Fields("Hmmm")
Do Until loRst.EOF
varChunk = loFld.GetChunk(70, 500)
strRet = ""
For lngCount = LBound(varChunk) To UBound(varChunk)
strRet = strRet & Chr(varChunk(lngCount))
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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>...
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.Application". 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.


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.


Nov 12 '05 #6

P: n/a

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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
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

Nov 12 '05 #7

P: n/a
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...
Where do the 70 & 500 come from? (getchunk 70,500)

TC
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderg1.core.theplanet.net. ..
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 PathFromOLEField()
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.CurrentDb
Set loRst = loDb.OpenRecordset("Table1")
Set loFld = loRst.Fields("Hmmm")
Do Until loRst.EOF
varChunk = loFld.GetChunk(70, 500)
strRet = ""
For lngCount = LBound(varChunk) To UBound(varChunk)
strRet = strRet & Chr(varChunk(lngCount))
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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>...
> 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.Application". 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.

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.



Nov 12 '05 #8

P: n/a
TC

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderm1.core.theplanet.net. ..
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.
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


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" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderg1.core.theplanet.net. ..
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 PathFromOLEField()
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.CurrentDb
Set loRst = loDb.OpenRecordset("Table1")
Set loFld = loRst.Fields("Hmmm")
Do Until loRst.EOF
varChunk = loFld.GetChunk(70, 500)
strRet = ""
For lngCount = LBound(varChunk) To UBound(varChunk)
strRet = strRet & Chr(varChunk(lngCount))
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" <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
> "TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>...
> > 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.Application". 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.
>
> 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.



Nov 12 '05 #9

P: n/a
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...

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderm1.core.theplanet.net. ..
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.


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


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" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderg1.core.theplanet.net. ..
> 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 PathFromOLEField()
> 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.CurrentDb
> Set loRst = loDb.OpenRecordset("Table1")
> Set loFld = loRst.Fields("Hmmm")
> Do Until loRst.EOF
> varChunk = loFld.GetChunk(70, 500)
> strRet = ""
> For lngCount = LBound(varChunk) To UBound(varChunk)
> strRet = strRet & Chr(varChunk(lngCount))
> 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" <ks*****@one.net> wrote in message
> news:3c**************************@posting.google.c om...
> > "TC" <a@b.c.d> wrote in message news:<1067313170.971034@teuthos>... > > > 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.Application". 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.
> >
> > 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. >
>



Nov 12 '05 #10

P: n/a
"Terry Kreft" <te*********@mps.co.uk> wrote in message news:<bn**********@newsreaderm1.core.theplanet.net >...
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?


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
Nov 12 '05 #11

P: n/a
TC
HUH?

Bye.

TC
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderg1.core.theplanet.net. ..
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...

"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bn**********@newsreaderm1.core.theplanet.net. ..
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.


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


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" <te*********@mps.co.uk> wrote in message
> news:bn**********@newsreaderg1.core.theplanet.net. ..
> > 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 PathFromOLEField()
> > 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.CurrentDb
> > Set loRst = loDb.OpenRecordset("Table1")
> > Set loFld = loRst.Fields("Hmmm")
> > Do Until loRst.EOF
> > varChunk = loFld.GetChunk(70, 500)
> > strRet = ""
> > For lngCount = LBound(varChunk) To UBound(varChunk)
> > strRet = strRet & Chr(varChunk(lngCount))
> > 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" <ks*****@one.net> wrote in message
> > news:3c**************************@posting.google.c om...
> > > "TC" <a@b.c.d> wrote in message

news:<1067313170.971034@teuthos>... > > > > 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.Application". 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.
> > >
> > > 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.
> >
> >
>
>



Nov 12 '05 #12

P: n/a
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bnooak$p5a$1
@newsreaderm1.core.theplanet.net:
Empiricism.


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).Value
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)
Nov 12 '05 #13

P: n/a
TC

Keith Brown <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"Terry Kreft" <te*********@mps.co.uk> wrote in message

news:<bn**********@newsreaderm1.core.theplanet.net >...
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?


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.)

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

TC

Nov 12 '05 #14

P: n/a

"TC" <a@b.c.d> wrote in message news:1067590381.686524@teuthos...

Keith Brown <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"Terry Kreft" <te*********@mps.co.uk> wrote in message news:<bn**********@newsreaderm1.core.theplanet.net >...
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?
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.)

Why do you say there is no documentation? It is probably just MS

"structured storage".

TC


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.

Nov 12 '05 #15

P: n/a
Hi Lyle,

I am getting an error when I attempt to run your code on the line that reads:

For Each v In .Fields(0).Value

When I hover over the variant v, it reads "empty" and .Fields(0).Value reads 2.
There are two fields in the table that I was using to run the test, an
autonumber PK and an OLE Object field. There are three test records with
embedded images ("Microsoft Photo Editor 3.0 Photo). Do you know what is
causing this error? The code compiles fine.

Tom
___________________________________

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bnooak$p5a$1
@newsreaderm1.core.theplanet.net:
Empiricism.


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).Value
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)
Nov 12 '05 #16

P: n/a
I forgot to mention the error message is:
"Run-time error '13':
Type mismatch

which would be expected, since v is empty.
___________________________

"Tom Wickerath" <AOS168 AT Comcast DOT com> wrote in message
news:Hn********@news.boeing.com...

Hi Lyle,

I am getting an error when I attempt to run your code on the line that reads:

For Each v In .Fields(0).Value

When I hover over the variant v, it reads "empty" and .Fields(0).Value reads 2.
There are two fields in the table that I was using to run the test, an
autonumber PK and an OLE Object field. There are three test records with
embedded images ("Microsoft Photo Editor 3.0 Photo). Do you know what is
causing this error? The code compiles fine.

Tom
___________________________________

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bnooak$p5a$1
@newsreaderm1.core.theplanet.net:
Empiricism.


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).Value
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)

Nov 12 '05 #17

P: n/a
"Tom Wickerath" <AOS168 AT Comcast DOT com> wrote in
news:Hn********@news.boeing.com:
I forgot to mention the error message is:
"Run-time error '13':
Type mismatch

which would be expected, since v is empty.
___________________________

"Tom Wickerath" <AOS168 AT Comcast DOT com> wrote in message
news:Hn********@news.boeing.com...

Hi Lyle,

I am getting an error when I attempt to run your code on the line that
reads:

For Each v In .Fields(0).Value

When I hover over the variant v, it reads "empty" and .Fields(0).Value
reads 2. There are two fields in the table that I was using to run the
test, an autonumber PK and an OLE Object field. There are three test
records with embedded images ("Microsoft Photo Editor 3.0 Photo). Do
you know what is causing this error? The code compiles fine.

Tom
___________________________________

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bnooak$p5a$1
@newsreaderm1.core.theplanet.net:
Empiricism.


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).Value
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


..Fields(1) ???

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #18

P: n/a
TC

"Stephen Lebans" <Fo****************************************@linval id.com>
wrote in message news:mV*******************@ursa-nb00s0.nbnet.nb.ca...

"TC" <a@b.c.d> wrote in message news:1067590381.686524@teuthos...

Keith Brown <ks*****@one.net> wrote in message
news:3c**************************@posting.google.c om...
"Terry Kreft" <te*********@mps.co.uk> wrote in message

news:<bn**********@newsreaderm1.core.theplanet.net >...
> 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?

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.)

Why do you say there is no documentation? It is probably just MS

"structured
storage".

TC


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.


Ok, thanks for that info. I'm quite surprised at that. I have a huge book on
OLE automation at home, & I assumed the info would be in there.

TC

Nov 12 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.