ZIP code module without DLL dependencies???

ZIP code module without DLL dependencies???

am 19.11.2007 10:56:00 von The Frog

Hi Everyone,

I am trying to find a solution for handling zipped data without the
need to ship / install any DLL files with the database. Does anybody
know of code to handle ZIP files that does not require any external
references? If I can ship it 'built-in' as either a class module or
standard module then that would be perfect.

Any help would be greatly appreciated.

Cheers

The Frog

Re: ZIP code module without DLL dependencies???

am 19.11.2007 15:33:34 von Tom van Stiphout

On Mon, 19 Nov 2007 01:56:00 -0800 (PST), The Frog
wrote:

That would require you to implement the zip file format and zip
decompression in VBA. Good luck with that.

-Tom.


>Hi Everyone,
>
>I am trying to find a solution for handling zipped data without the
>need to ship / install any DLL files with the database. Does anybody
>know of code to handle ZIP files that does not require any external
>references? If I can ship it 'built-in' as either a class module or
>standard module then that would be perfect.
>
>Any help would be greatly appreciated.
>
>Cheers
>
>The Frog

Re: ZIP code module without DLL dependencies???

am 19.11.2007 17:37:38 von Stephen Lebans

I cannot find it right now but I have downloaded a VB6 class that supports
the ZIP file format. A Google search for "Zip Visual Basic class" should get
you started.

--

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


"The Frog" wrote in message
news:58cc3f9c-1b18-4e8a-bb8e-4613a683c48d@d61g2000hsa.google groups.com...
> Hi Everyone,
>
> I am trying to find a solution for handling zipped data without the
> need to ship / install any DLL files with the database. Does anybody
> know of code to handle ZIP files that does not require any external
> references? If I can ship it 'built-in' as either a class module or
> standard module then that would be perfect.
>
> Any help would be greatly appreciated.
>
> Cheers
>
> The Frog

Re: ZIP code module without DLL dependencies???

am 20.11.2007 01:00:55 von Chuck Grimsby

Create, extract, or both?

If the target machine is XP SP2, then all the DLLs you need are
already installed.

(Although to be honest, I've only does this with a VBScript file, not
in VBA.)



On Mon, 19 Nov 2007 01:56:00 -0800 (PST), The Frog
wrote:
>I am trying to find a solution for handling zipped data without the
>need to ship / install any DLL files with the database. Does anybody
>know of code to handle ZIP files that does not require any external
>references? If I can ship it 'built-in' as either a class module or
>standard module then that would be perfect.
>Any help would be greatly appreciated.

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 20.11.2007 05:13:10 von Tony Toews

Chuck Grimsby wrote:

>
>Create, extract, or both?
>
>If the target machine is XP SP2, then all the DLLs you need are
>already installed.
>
>(Although to be honest, I've only does this with a VBScript file, not
>in VBA.)

Interesting. Got any URLs with VBScript code?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 21.11.2007 01:40:07 von Chuck Grimsby

On Tue, 20 Nov 2007 04:13:10 GMT, "Tony Toews [MVP]"
wrote:

>Chuck Grimsby wrote:
>>Create, extract, or both?
>>If the target machine is XP SP2, then all the DLLs you need are
>>already installed.
>>(Although to be honest, I've only does this with a VBScript file, not
>>in VBA.)

>Interesting. Got any URLs with VBScript code?

I got the source for this somewhere in Usenet, although I've forgotten
where. I have the full message, but it's on a Backup disk somewhere.
(It's not exactly new!)

Some who *really* knows VBScript could probably do a better job, but
this works.

This creates a Zip file and copies the contents of a whole folder into
it. As always, watch out for word wrap....

---------------------- Cut Here ------------------------------------
Option Explicit
Dim ZipFileName, FolderToZip
Dim oApp, MyHex, MyBinary, i
Dim oFSO, oTF

MyHex = Array(80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0,0, 0)
For i = 0 To UBound(MyHex)
MyBinary = MyBinary & Chr(MyHex(i))
Next

FolderToZip = "C:\Data Files\My Data\"
' in case someone forgets the last slash:
If Right(FolderToZip, 1) <> "\" Then
FolderToZip = FolderToZip & "\"
End If

ZipFileName = "G:\Backups\" & _
FormatNowISO & _
"MyDataBackup.zip"

'Create empty Zip File
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oTF = oFSO.CreateTextFile(ZipFileName, True)
oTF.Write MyBinary
oTF.Close
Set oTF = Nothing
Set oFSO = Nothing

'Copy the files to the compressed folder
Set oApp = CreateObject("Shell.Application")
oApp.NameSpace(ZipFileName).CopyHere _
oApp.NameSpace(FolderToZip).items

'Keep script waiting until Compressing is done
On Error Resume Next
Do Until oApp.NameSpace(ZipFileName).items.Count =
oApp.NameSpace(FolderToZip).items.Count
Application.Wait (Now + TimeValue("0:00:01"))
Loop
Set oApp = Nothing
On Error GoTo 0

'MsgBox "Done!" & vbnewline & _
"You'll find the zipfile here: " & vbnewline & _
ZipFileName

WScript.Quit

Function FormatNowISO
FormatNowISO = DatePart("yyyy", Now())
FormatNowISO = FormatNowISO & Right("00" & DatePart("m", Now()), 2)
FormatNowISO = FormatNowISO & Right("00" & DatePart("d", Now()), 2)
' if the time is needed:
'FormatNowISO = FormatNowISO & _
Right("00" & DatePart("h", Now()), 2)
'FormatNowISO = FormatNowISO & _
Right("00" & DatePart("n", Now()), 2)
'FormatNowISO = FormatNowISO & _
Right("00" & DatePart("s", Now()), 2)
End Function
---------------------- Cut Here ------------------------------------

I'll have to dig out the backup to get at a un-zip script. As I
remember, it's pretty much the same thing, just copying the files out
of the (zipped) folder. I'll see if I can dig it out over the
Thanksgiving holiday.

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 21.11.2007 08:00:45 von Tony Toews

"Stephen Lebans" wrote:

>A Google search for "Zip Visual Basic class" should get
>you started.

Nope. way too many hits without the quotes and way too few hits with the quotes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 21.11.2007 08:03:05 von Tony Toews

Chuck Grimsby wrote:

>>Chuck Grimsby wrote:
>>>Create, extract, or both?
>>>If the target machine is XP SP2, then all the DLLs you need are
>>>already installed.
>>>(Although to be honest, I've only does this with a VBScript file, not
>>>in VBA.)
>
>>Interesting. Got any URLs with VBScript code?
>
>I got the source for this somewhere in Usenet, although I've forgotten
>where.

Thanks but I suspect that could be quite difficult to convert to VB/VBA. I suspect
that VBScripts opening of a .zip file is a lot more intelligent than would be
VB6/VBA.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 21.11.2007 11:01:25 von Stuart McCall

"Tony Toews [MVP]" wrote in message
news:vul7k35ggka0h1vfjeaag88lfb0lhmdg0t@4ax.com...
> Thanks but I suspect that could be quite difficult to convert to VB/VBA.
> I suspect
> that VBScripts opening of a .zip file is a lot more intelligent than would
> be
> VB6/VBA.

Actually it wasn't too bad:

Sub CreateZip()
ZipFileName = "c:\temp\test1.zip"
FolderToZip = "c:\temp\testzip\"

HexArray = Array(80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0)
For i = LBound(HexArray) To UBound(HexArray)
BinStr = BinStr & Chr(HexArray(i))
Next
Open ZipFileName For Output As 1
Print #1, BinStr
Close 1

Set oApp = CreateObject("Shell.Application")
oApp.NameSpace(ZipFileName).CopyHere oApp.NameSpace(FolderToZip).items
Do Until oApp.NameSpace(ZipFileName).items.Count =
oApp.NameSpace(FolderToZip).items.Count
DoEvents
Loop
Set oApp = Nothing
End Sub

Although I've yet to find a way to copy individual files into the zip, other
than creating a folder, copying the files into it, then specifying this as
the source folder for the copy (which could be done transparently, but it's
a bit kludgy).

Re: ZIP code module without DLL dependencies???

am 22.11.2007 00:24:45 von Tony Toews

"Stuart McCall" wrote:

>> Thanks but I suspect that could be quite difficult to convert to VB/VBA.
>> I suspect
>> that VBScripts opening of a .zip file is a lot more intelligent than would
>> be
>> VB6/VBA.
>
>Actually it wasn't too bad:

No, that wouldn't have been bad at all. However I'm slightly skeptical that the
VBScript object would work in all systems. While I doubt I have any Win 2000 clients
left there could be some. And I'm just a skeptic.

So I think I'll use the infozip dlls so long as they will work if copied into the
same folder as the FE MDE. I do not want to worry about them having to be installed
in the system32 folder.

>Although I've yet to find a way to copy individual files into the zip, other
>than creating a folder, copying the files into it, then specifying this as
>the source folder for the copy (which could be done transparently, but it's
>a bit kludgy).

Interesting that.

Thanks, Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 22.11.2007 01:26:52 von Stuart McCall

"Tony Toews [MVP]" wrote in message
news:ndf9k31m4bga6c74ttnthr6is4oqhpb95l@4ax.com...
> "Stuart McCall" wrote:
>
> So I think I'll use the infozip dlls so long as they will work if copied
> into the
> same folder as the FE MDE. I do not want to worry about them having to be
> installed
> in the system32 folder.

Yes, I have a developer's licence for BsZip (Big Speed Zip) which I've had
for years. I'll not be giving that up in a hurry. I'm just intrigued with
the way this method works.

Here are a couple of quirks I've found. The first two bytes, when viewed as
ascii codes, are PK. Phil Katz (R.I.P.). No idea of the significance of 5
and 6 though. Also, a CrLf must follow the binary header in order for
windows to consider it a "legal" empty zip file. Go figure.

>
>>Although I've yet to find a way to copy individual files into the zip,
>>other
>>than creating a folder, copying the files into it, then specifying this as
>>the source folder for the copy (which could be done transparently, but
>>it's
>>a bit kludgy).
>
> Interesting that.

Yep, so far I've tried FileCopy - folder not found, and SHFileOperation -
again folder not found. A Flying paper dialog appears before the error, with
the caption "Compressing...". As I'm sure you're aware, this dialog is
produced when using the SHFileOperation API. Maybe I've just not got the
syntax right (or there could be a new flag value or two).

I have altogether too much free time ;-)

Re: ZIP code module without DLL dependencies???

am 22.11.2007 04:18:13 von Tony Toews

"Stuart McCall" wrote:

>Here are a couple of quirks I've found. The first two bytes, when viewed as
>ascii codes, are PK. Phil Katz (R.I.P.).

Oh yes, I've seen that before when perusing those files using a DOS editor.

>No idea of the significance of 5
>and 6 though. Also, a CrLf must follow the binary header in order for
>windows to consider it a "legal" empty zip file. Go figure.

Hey, anything makes sense.

>I have altogether too much free time ;-)

I don't!

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 22.11.2007 04:21:30 von Tony Toews

"Stuart McCall" wrote:


BTW that might not even work on my system. I did the following to disable the
Windows zipping and am using (a legally purchased) Winzip.

Irritating searching within zip files
regsvr32 /u zipfldr.dll

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 22.11.2007 09:59:56 von The Frog

Hi Everyone,

My goodness, we seem to have stirred up a lot of interest here. I am
not sure about the exact meaning of osme of the bits in the file
header, but I have located the application notes (specification) for
the actual zip format and the compression algorithms. It can be found
here: http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Perhaps the information you seek may be in there. After reading enough
of the specification to get the feel for how complex it owuld be to
program this up in pure VB(A), I have decided that it is going to take
too much time for me to accomplish my goals by the due date.

With regards to using external dll's such as the infofzip ones, has
anyone got an opinion to offer about their use? I was thinking that I
would make a hidden table and store the dll as a blob, pop the dll
into a temporary location when needed, then destroy it again at the
end of the process. Has anyone done this before or have any other
recommendations? (Installing stuff is actually quite hard in this
corporate environment, so minimising dependencies is crucial -
effectively I need to be able to ship just an MDB / MDE file and let
it do its job without concern for what is / isnt on the system in
question).

Thankyou all for the valuable input on this too. The scripting stuff
is actually quite intriguing. I would be interested to see the single
file version if anyone has an idea on that one.

Thankyou all for your time and input, I really appreciate it.

The Frog

Re: ZIP code module without DLL dependencies???

am 22.11.2007 10:11:57 von Tony Toews

The Frog wrote:

>My goodness, we seem to have stirred up a lot of interest here.

Sure, we were getting bored.

>With regards to using external dll's such as the infofzip ones, has
>anyone got an opinion to offer about their use? I was thinking that I
>would make a hidden table and store the dll as a blob, pop the dll
>into a temporary location when needed, then destroy it again at the
>end of the process. Has anyone done this before or have any other
>recommendations? (Installing stuff is actually quite hard in this
>corporate environment, so minimising dependencies is crucial -
>effectively I need to be able to ship just an MDB / MDE file and let
>it do its job without concern for what is / isnt on the system in
>question).

Hmm, yes, that's possible I do beleive. Check Stephen Lebans website. Hmm, here's
one but it doesn't explicitly state dlls. http://www.lebans.com/oletodisk.htm That
said it does mention PDF files and such so it's quite possible. Worth spending a
half hour playing with it.

That's something I'm not too worried about as I don't mind packing up a few extra
DLLs for use. But I can see where you are coming from when dealing with IT Nazi
admins.

Tony


--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 22.11.2007 12:28:22 von The Frog

Hi Tony,

The admins here largely are the root cause of my programming problems.
They make unpredictable changes to the OS's on every machine, dont
tell anyone anything, and refuse to take any accountability for their
actions - in short they dont manage all that well and arent made to.

The result is that I have lost many months worth of work due to their
actions (I think something like ~60k lines of code this year so far)
because I cannot guarantee that the application will actually be able
to run on any given day. Some days they work fine and others they
simply wont at all. No way to predict it unfortunately.

Because of this I have set about collecting / creating modules for MS
Access (97) that remove the dependencies from the system itself and
therefore minimise the risk of the application not running. I still
have to keep a copy of MDAC installers on standby, but thats about it.
Right now I am grappling with ZIP so that I can get some output into a
small enough filesize to email to a large group. The alternative would
be to use online drop-boxes such as rapidshare - but as I see it these
represent a risk that potentially sensitive data can end up easily in
the wrong hands (and besides, it probably breaches the rules I have to
stick to).

I will have a play with the DLL option and storing it in the app
itself, and dragging it out when necessary. I will keep you posted
with the progress. Probably wont have the time till next week though
to post any code on this one.

Cheers and thanks for your help

The Frog

Re: ZIP code module without DLL dependencies???

am 22.11.2007 14:35:44 von Stuart McCall

"The Frog" wrote in message
news:0c3274c2-8a2a-4c33-a719-bd9551ec9a35@g21g2000hsh.google groups.com...
> Hi Tony,

> I will have a play with the DLL option and storing it in the app
> itself, and dragging it out when necessary. I will keep you posted
> with the progress. Probably wont have the time till next week though
> to post any code on this one.
>
> Cheers and thanks for your help
>
> The Frog

You can try this module if you like. I've been using it successfully for
years, to "create" DLL's, icons, pictures and gen. purpose binary data. The
two main routines are FileToBinaryData and BinaryDataToFile. The module as
it stands is intended to live in a library mdb. If you wish to use it in a
FE, simply change all CodeDB references to CurrentDb.

It requires a table tblBinaryData, with the structure:

Item Text 50
Value OLE Object

Item is the primary key.

''' CODE START '''
Option Compare Database
'
Private Const TPL_SELECT = "Select Value From tblBinaryData Where Item='?'"

Public Function GetBinaryData(ByVal Item$) As String
'Returns a binary item from tblBinaryData as a string

On Error GoTo GetBinaryData_Err
'
With CodeDb.OpenRecordset(Replace(TPL_SELECT, "?", Item),
dbOpenSnapshot)
GetBinaryData = !Value
.Close
End With

GetBinaryData_Exit:
Exit Function

GetBinaryData_Err:
Resume GetBinaryData_Exit

End Function

Public Function PutBinaryData(ByVal Item$, ByVal Value$) As Boolean
'Stores a binary item in tblBinaryData
'Returns True for success

On Error GoTo PutBinaryData_Err
'
With CodeDb.OpenRecordset("tblBinaryData", dbOpenDynaset)
.FindFirst "Item=" & Quoted(Item)
If .NoMatch Then
.AddNew
!Item = Item
Else
.Edit
End If
!Value = Value
.Update
.Close
End With
'
PutBinaryData = True

PutBinaryData_Exit:
Exit Function

PutBinaryData_Err:
Resume PutBinaryData_Exit

End Function

Public Function DelBinaryData(ByVal Item$) As Boolean
'Deletes a binary item from tblBinaryData
'Returns True for success

On Error GoTo DelBinaryData_Err
'
With CodeDb.OpenRecordset(Replace(TPL_SELECT, "?", Item), dbOpenDynaset)
If .BOF Then Exit Function
.Delete
.Close
End With
'
DelBinaryData = True

DelBinaryData_Exit:
Exit Function

DelBinaryData_Err:
Resume DelBinaryData_Exit

End Function

Public Function FileToBinaryData(ByVal File$, ByVal Item$) As Boolean
'Retrieves a binary item from a file and stores it in tblBinaryData
'Returns True for success

On Error GoTo FileToBinaryData_Err
'
b$ = BinFileToString(File)
If b = "" Then Exit Function
FileToBinaryData = PutBinaryData(Item, b)

FileToBinaryData_Exit:
Exit Function

FileToBinaryData_Err:
Resume FileToBinaryData_Exit

End Function

Public Function BinaryDataToFile(ByVal File$, ByVal Item$) As Boolean
'Retrieves a binary item from tblBinaryData and creates a file from it
'Returns True for success

On Error GoTo BinaryDataToFile_Err
'
b$ = GetBinaryData(Item)
If b = "" Then Exit Function
StringToBinFile b, File
'
BinaryDataToFile = True

BinaryDataToFile_Exit:
Exit Function

BinaryDataToFile_Err:
Resume BinaryDataToFile_Exit

End Function

Public Function BinFileToString(ByVal File) As String
'Returns a binary item retrieved from a file

On Error GoTo BinFileToString_Err
'
f% = FreeFile
Open File For Binary Access Read Lock Write As f%
b$ = Space$(LOF(f))
Get #f%, , b
Close f
'
BinFileToString = b

BinFileToString_Exit:
Exit Function

BinFileToString_Err:
MsgBox Err.Description, vbCritical, "modBinaryData.BinFileToString"
Resume BinFileToString_Exit

End Function

Public Function StringToBinFile(ByVal bin$, ByVal File$) As Boolean
'Creates a file from the passed string
'Returns True for success

On Error GoTo StringToBinFile_Err
'
If Dir(File) <> "" Then Kill File
f% = FreeFile
Open File For Binary Access Write Lock Read As f
Put #f, , bin
Close f
'
StringToBinFile = True

StringToBinFile_Exit:
Exit Function

StringToBinFile_Err:
MsgBox Err.Description, vbCritical, "modBinaryData.StringToBinFile"
Resume StringToBinFile_Exit

End Function
''' CODE END '''

Re: ZIP code module without DLL dependencies???

am 22.11.2007 23:14:46 von Stuart McCall

"The Frog" wrote in message
news:49cdee52-13c2-4450-b5bd-a8729f4dc9f8@j20g2000hsi.google groups.com...
> Hi Everyone,

> Thankyou all for the valuable input on this too. The scripting stuff
> is actually quite intriguing. I would be interested to see the single
> file version if anyone has an idea on that one.

Take a look here:

http://www.rondebruin.nl/windowsxpzip.htm#Code

Examples for just about everything.

Re: ZIP code module without DLL dependencies???

am 23.11.2007 04:11:10 von Stephen Lebans

Hi Stuart,
personally, I would get rid of the string functions in your code. You are
working with binary data, not strings per se. Simply redim an array of Bytes
and use the VBA Get and Put methods to read/write the data. No string
conversions required, uses less resources and you will find the read/write
operations much faster.

Just my $.02

--

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


"Stuart McCall" wrote in message
news:fi40u5$iq8$1$8302bc10@news.demon.co.uk...
> "The Frog" wrote in message
> news:0c3274c2-8a2a-4c33-a719-bd9551ec9a35@g21g2000hsh.google groups.com...
>> Hi Tony,
>
>> I will have a play with the DLL option and storing it in the app
>> itself, and dragging it out when necessary. I will keep you posted
>> with the progress. Probably wont have the time till next week though
>> to post any code on this one.
>>
>> Cheers and thanks for your help
>>
>> The Frog
>
> You can try this module if you like. I've been using it successfully for
> years, to "create" DLL's, icons, pictures and gen. purpose binary data.
> The two main routines are FileToBinaryData and BinaryDataToFile. The
> module as it stands is intended to live in a library mdb. If you wish to
> use it in a FE, simply change all CodeDB references to CurrentDb.
>
> It requires a table tblBinaryData, with the structure:
>
> Item Text 50
> Value OLE Object
>
> Item is the primary key.
>
> ''' CODE START '''
> Option Compare Database
> '
> Private Const TPL_SELECT = "Select Value From tblBinaryData Where
> Item='?'"
>
> Public Function GetBinaryData(ByVal Item$) As String
> 'Returns a binary item from tblBinaryData as a string
>
> On Error GoTo GetBinaryData_Err
> '
> With CodeDb.OpenRecordset(Replace(TPL_SELECT, "?", Item),
> dbOpenSnapshot)
> GetBinaryData = !Value
> .Close
> End With
>
> GetBinaryData_Exit:
> Exit Function
>
> GetBinaryData_Err:
> Resume GetBinaryData_Exit
>
> End Function
>
> Public Function PutBinaryData(ByVal Item$, ByVal Value$) As Boolean
> 'Stores a binary item in tblBinaryData
> 'Returns True for success
>
> On Error GoTo PutBinaryData_Err
> '
> With CodeDb.OpenRecordset("tblBinaryData", dbOpenDynaset)
> .FindFirst "Item=" & Quoted(Item)
> If .NoMatch Then
> .AddNew
> !Item = Item
> Else
> .Edit
> End If
> !Value = Value
> .Update
> .Close
> End With
> '
> PutBinaryData = True
>
> PutBinaryData_Exit:
> Exit Function
>
> PutBinaryData_Err:
> Resume PutBinaryData_Exit
>
> End Function
>
> Public Function DelBinaryData(ByVal Item$) As Boolean
> 'Deletes a binary item from tblBinaryData
> 'Returns True for success
>
> On Error GoTo DelBinaryData_Err
> '
> With CodeDb.OpenRecordset(Replace(TPL_SELECT, "?", Item),
> dbOpenDynaset)
> If .BOF Then Exit Function
> .Delete
> .Close
> End With
> '
> DelBinaryData = True
>
> DelBinaryData_Exit:
> Exit Function
>
> DelBinaryData_Err:
> Resume DelBinaryData_Exit
>
> End Function
>
> Public Function FileToBinaryData(ByVal File$, ByVal Item$) As Boolean
> 'Retrieves a binary item from a file and stores it in tblBinaryData
> 'Returns True for success
>
> On Error GoTo FileToBinaryData_Err
> '
> b$ = BinFileToString(File)
> If b = "" Then Exit Function
> FileToBinaryData = PutBinaryData(Item, b)
>
> FileToBinaryData_Exit:
> Exit Function
>
> FileToBinaryData_Err:
> Resume FileToBinaryData_Exit
>
> End Function
>
> Public Function BinaryDataToFile(ByVal File$, ByVal Item$) As Boolean
> 'Retrieves a binary item from tblBinaryData and creates a file from it
> 'Returns True for success
>
> On Error GoTo BinaryDataToFile_Err
> '
> b$ = GetBinaryData(Item)
> If b = "" Then Exit Function
> StringToBinFile b, File
> '
> BinaryDataToFile = True
>
> BinaryDataToFile_Exit:
> Exit Function
>
> BinaryDataToFile_Err:
> Resume BinaryDataToFile_Exit
>
> End Function
>
> Public Function BinFileToString(ByVal File) As String
> 'Returns a binary item retrieved from a file
>
> On Error GoTo BinFileToString_Err
> '
> f% = FreeFile
> Open File For Binary Access Read Lock Write As f%
> b$ = Space$(LOF(f))
> Get #f%, , b
> Close f
> '
> BinFileToString = b
>
> BinFileToString_Exit:
> Exit Function
>
> BinFileToString_Err:
> MsgBox Err.Description, vbCritical, "modBinaryData.BinFileToString"
> Resume BinFileToString_Exit
>
> End Function
>
> Public Function StringToBinFile(ByVal bin$, ByVal File$) As Boolean
> 'Creates a file from the passed string
> 'Returns True for success
>
> On Error GoTo StringToBinFile_Err
> '
> If Dir(File) <> "" Then Kill File
> f% = FreeFile
> Open File For Binary Access Write Lock Read As f
> Put #f, , bin
> Close f
> '
> StringToBinFile = True
>
> StringToBinFile_Exit:
> Exit Function
>
> StringToBinFile_Err:
> MsgBox Err.Description, vbCritical, "modBinaryData.StringToBinFile"
> Resume StringToBinFile_Exit
>
> End Function
> ''' CODE END '''
>
>
>

Re: ZIP code module without DLL dependencies???

am 23.11.2007 08:25:13 von Stuart McCall

"Stephen Lebans"
wrote in message news:474644c3$0$5264$9a566e8b@news.aliant.net...
> Hi Stuart,
> personally, I would get rid of the string functions in your code. You are
> working with binary data, not strings per se. Simply redim an array of
> Bytes and use the VBA Get and Put methods to read/write the data. No
> string conversions required, uses less resources and you will find the
> read/write operations much faster.
>
> Just my $.02


I appreciate the comment, but I think you need to look again. I'm not doing
any conversions, simply using a string as a buffer, and I'm using Get/Put to
read/write. However I take your point re the speed of read/write ops. I'll
run a few tests.

One thing I have been meaning to do is remove the ByVal's from the param
declares (can't remember why I did that, but then I did write this in Access
2.0). Just not got round to it yet.

Thanks, not least for making me look over it again. I just spotted that I'm
using a function from another module in the library (Quoted - surrounds data
with Chr(34)'s). I'll correct this for The Frog's benefit.

Re: ZIP code module without DLL dependencies???

am 23.11.2007 08:39:28 von Stuart McCall

I just realised that there's a small function missing. Just add this to the
module:

Public Function Quoted(StringToQuote As String) As String
If Left(StringToQuote, 1) <> Chr(34) Then
StringToQuote = Chr(34) & StringToQuote & Chr(34)
End If
Quoted = StringToQuote
End Function

Re: ZIP code module without DLL dependencies???

am 23.11.2007 23:29:38 von Chuck Grimsby

On Wed, 21 Nov 2007 10:01:25 -0000, "Stuart McCall"
wrote:
>Although I've yet to find a way to copy individual files into the zip, other
>than creating a folder, copying the files into it, then specifying this as
>the source folder for the copy (which could be done transparently, but it's
>a bit kludgy).

To copy a individual file into the zip file via VBS, you just do:

FileToZip = "C:\Data Files\My Data\MyFile.mdb"
set oApp = CreateObject("shell.application")
oApp.namespace(ZipFileName).CopyHere FileToZip

rather then the

'Copy the files to the compressed folder
Set oApp = CreateObject("Shell.Application")
oApp.NameSpace(ZipFileName).CopyHere _
oApp.NameSpace(FolderToZip).items

Everything else is the same.


To copy files out of the ZipFile do:

---------------------- Cut Here ------------------------------------
CopyTo = "C:\test"
ZipFileName= "G:\Downloads\20071121.zip"

Set oApp = CreateObject("Shell.Application")
oApp.NameSpace(CopyTo).CopyHere(oApp.NameSpace(ZipFileName). items)
---------------------- Cut Here ------------------------------------

It will extract all the files in the zip file.


Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 23.11.2007 23:29:39 von Chuck Grimsby

On Thu, 22 Nov 2007 00:26:52 -0000, "Stuart McCall"
wrote:

>"Tony Toews [MVP]" wrote in message
>news:ndf9k31m4bga6c74ttnthr6is4oqhpb95l@4ax.com...
>> "Stuart McCall" wrote:
>>
>> So I think I'll use the infozip dlls so long as they will work if copied
>> into the
>> same folder as the FE MDE. I do not want to worry about them having to be
>> installed
>> in the system32 folder.

>Yes, I have a developer's licence for BsZip (Big Speed Zip) which I've had
>for years. I'll not be giving that up in a hurry. I'm just intrigued with
>the way this method works.

There's also the (Free and Open Source) 7-Zip: http://www.7-zip.org/

which has a built-in command line interface. It's also "portable",
meaning it can run from a USB key without installing anything.

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 24.11.2007 01:19:01 von Stuart McCall

"Chuck Grimsby" wrote in message
news:8akek3ttvfvov4gabnibs8qkmna5p6fksh@4ax.com...
> On Wed, 21 Nov 2007 10:01:25 -0000, "Stuart McCall"
> wrote:
>>Although I've yet to find a way to copy individual files into the zip,
>>other
>>than creating a folder, copying the files into it, then specifying this as
>>the source folder for the copy (which could be done transparently, but
>>it's
>>a bit kludgy).
>
> To copy a individual file into the zip file via VBS, you just do:


Thanks for that. I found this site:

http://www.rondebruin.nl/windowsxpzip.htm#Code

has examples of all that. The one thing they don't demonstrate, which is
eluding me also (so far), is how to extract one file from a zip. The items
collection, although having a Count property, cannot be addressed either
with a numeric or text index:

oApp.NameSpace(ZipFileName).items(1)
oApp.NameSpace(ZipFileName).items("test.txt")

However, this works:

For Each item In oApp.NameSpace(ZipFileName).items
Debug.Print item
Next

Any idea how to address an individual item of the items collection?

Re: ZIP code module without DLL dependencies???

am 24.11.2007 03:31:00 von Tony Toews

Chuck Grimsby wrote:

>There's also the (Free and Open Source) 7-Zip: http://www.7-zip.org/
>
>which has a built-in command line interface.

I much prefer a dll solution so I'll know if it's executed properly. Command line
doesn't thrill me.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 25.11.2007 01:36:23 von XXXusenet

"Tony Toews [MVP]" wrote in
news:573fk3ppnn29csjdhh5lu6fn92bhdo8stp@4ax.com:

> I much prefer a dll solution so I'll know if it's executed
> properly. Command line doesn't thrill me.

But can't you redirect commandline output to a file and use that to
figure out what happened? Or use a batch file and DOS ErrorLevel?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: ZIP code module without DLL dependencies???

am 25.11.2007 02:44:14 von Tony Toews

"David W. Fenton" wrote:

>> I much prefer a dll solution so I'll know if it's executed
>> properly. Command line doesn't thrill me.
>
>But can't you redirect commandline output to a file and use that to
>figure out what happened? Or use a batch file and DOS ErrorLevel?

Sure, but again that's more work and more things to go wrong compared to a dll
solution which returns an error code.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 25.11.2007 03:01:13 von Stuart McCall

"Stuart McCall" wrote in message
news:fi7qnl$f5v$1$8300dec7@news.demon.co.uk...
> "Chuck Grimsby" wrote in message
> news:8akek3ttvfvov4gabnibs8qkmna5p6fksh@4ax.com...
>> On Wed, 21 Nov 2007 10:01:25 -0000, "Stuart McCall"
>> wrote:
>>>Although I've yet to find a way to copy individual files into the zip,
>>>other
>>>than creating a folder, copying the files into it, then specifying this
>>>as
>>>the source folder for the copy (which could be done transparently, but
>>>it's
>>>a bit kludgy).
>>
>> To copy a individual file into the zip file via VBS, you just do:
>
>
> Thanks for that. I found this site:
>
> http://www.rondebruin.nl/windowsxpzip.htm#Code
>
> has examples of all that. The one thing they don't demonstrate, which is
> eluding me also (so far), is how to extract one file from a zip. The items
> collection, although having a Count property, cannot be addressed either
> with a numeric or text index:
>
> oApp.NameSpace(ZipFileName).items(1)
> oApp.NameSpace(ZipFileName).items("test.txt")
>
> However, this works:
>
> For Each item In oApp.NameSpace(ZipFileName).items
> Debug.Print item
> Next
>
> Any idea how to address an individual item of the items collection?

Please ignore this question. I figured it out:

oApp.NameSpace(ZipFileName).items.Item(1)

or

oApp.NameSpace(ZipFileName).items.Item("test.txt")

Re: ZIP code module without DLL dependencies???

am 26.11.2007 00:34:01 von XXXusenet

"Tony Toews [MVP]" wrote in
news:hqkhk39qon3enhqa6trvmnht83h7sn73kr@4ax.com:

> "David W. Fenton" wrote:
>
>>> I much prefer a dll solution so I'll know if it's executed
>>> properly. Command line doesn't thrill me.
>>
>>But can't you redirect commandline output to a file and use that
>>to figure out what happened? Or use a batch file and DOS
>>ErrorLevel?
>
> Sure, but again that's more work and more things to go wrong
> compared to a dll solution which returns an error code.

But you have to have the DLL properly registered, which may not work
well for certain locked-down scenarios.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: ZIP code module without DLL dependencies???

am 26.11.2007 02:51:28 von Tony Toews

"David W. Fenton" wrote:

>But you have to have the DLL properly registered, which may not work
>well for certain locked-down scenarios.

Not to my knowledge. So long as the DLL works in the same folder as the FE MDE you
should be just fine.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

Re: ZIP code module without DLL dependencies???

am 26.11.2007 15:56:47 von The Frog

It is interesting looking at the scripting options for this. Does
anyone know if there is a way to make use of a library from scripting
without having to register the dll? As David mentioned, it can be a
problem to register such things in heavily controlled environments,
and this is the case with where I work. There is also a problem with
different platforms so the WinXP scripting solution will only work on
a few machines.

As a secondary point, I would like to ask for some advice on the
possible creation of a 'zip' module / class module. The implementation
of such a thing could be quite useful, especially if you could
compress data sufficiently (eg with BLOB's) before stroing directly in
the database, not to mention the standard file handling stuff. If one
were to attempt such a thing, what would your considered opinions be
on the most useful implementation of such a thing? I was leaning
towards a class module with the necessary properties and methods to
handle things, but I considered that there might be an issue with
particularly large hunks of data, whereby it may be more efficient /
effective to simply use a function to return the results of the
desired compress / uncompress operation. Your thoughts would be
appreciated :-)

Cheers

The Frog

Re: ZIP code module without DLL dependencies???

am 27.11.2007 10:07:19 von The Frog



It is interesting looking at the scripting options for this. Does
anyone know if there is a way to make use of a library from scripting
without having to register the dll? As David mentioned, it can be a
problem to register such things in heavily controlled environments,
and this is the case with where I work. There is also a problem with
different platforms so the WinXP scripting solution will only work on
a few machines.

As a secondary point, I would like to ask for some advice on the
possible creation of a 'zip' module / class module. The
implementation
of such a thing could be quite useful, especially if you could
compress data sufficiently (eg with BLOB's) before stroing directly
in
the database, not to mention the standard file handling stuff. If one
were to attempt such a thing, what would your considered opinions be
on the most useful implementation of such a thing? I was leaning
towards a class module with the necessary properties and methods to
handle things, but I considered that there might be an issue with
particularly large hunks of data, whereby it may be more efficient /
effective to simply use a function to return the results of the
desired compress / uncompress operation. Your thoughts would be
appreciated :-)


Cheers


The Frog

Re: ZIP code module without DLL dependencies???

am 28.11.2007 01:28:05 von Chuck Grimsby

Personally, I don't think you will be able to find a way to do this
without installing a dll or using pre-existing installed dlls that
will work on all windows platforms. The Zip functions didn't exist as
a part of the operating system (for example) until XP.

There are a number of pre-existing modules and class modules around to
handle WinZip-ing files. Feel free to use which ever one you want,
but those will require installing at least some version of WinZip.

I can't in all good conscious recommend storing compressed data in a
Access database. That sort of information (encrypted or not) is not
well suited to a database of any sort, though most will allow you to
do so. It just isn't a "good practice". It would not be fast or
efficient to do so.

Why are you trying to accomplish doing this? Knowing that, we might
be able to help you find an acceptable solution.


On Tue, 27 Nov 2007 01:07:19 -0800 (PST), The Frog
wrote:

>
>
>It is interesting looking at the scripting options for this. Does
>anyone know if there is a way to make use of a library from scripting
>without having to register the dll? As David mentioned, it can be a
>problem to register such things in heavily controlled environments,
>and this is the case with where I work. There is also a problem with
>different platforms so the WinXP scripting solution will only work on
>a few machines.
>
>As a secondary point, I would like to ask for some advice on the
>possible creation of a 'zip' module / class module. The
>implementation
>of such a thing could be quite useful, especially if you could
>compress data sufficiently (eg with BLOB's) before stroing directly
>in
>the database, not to mention the standard file handling stuff. If one
>were to attempt such a thing, what would your considered opinions be
>on the most useful implementation of such a thing? I was leaning
>towards a class module with the necessary properties and methods to
>handle things, but I considered that there might be an issue with
>particularly large hunks of data, whereby it may be more efficient /
>effective to simply use a function to return the results of the
>desired compress / uncompress operation. Your thoughts would be
>appreciated :-)

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 28.11.2007 09:30:42 von The Frog

Hi Chuck,

The basis for attempting this is that I must be able to 'push'
sometimes substantial volumes of data out to field personnel who have
limited access to network resources.

The idea is to create a type of update file that carries the data, in
an encrypted form, via email (Lotus Notes), from my 'master' data
store / application out to the field personnel. I cannot guarantee any
form of standardisation on their machines (despite the corporate
standards policies), and so in order to be able to send the data
efficiently and use it at the other end compression would be a good
idea. I thought that perhaps given the age of the Zip format and the
Deflate algorithm that someone might have written a VB / VBA module or
class module to be able to use this functionality directly in
applications.

The encryption is not an issue to achieve, merely the incorporation of
a suitable method of compression. The more I can build into the
application itself the less likely I am to encounter problems with the
setup of the machines in the field (approximately 200). Or at least
that is my thinking and experience so far. The 'field' version of the
application would have a function built in to read and incorporate the
new data (and possibly instructions for modifictaion). In this way all
that the field person has to have is an email address and the
application would do the rest. At least, thats the theory.

Perhaps there are some other ways that compression can be achieved? I
am not sure exactly how large these update files would be, however for
all intents and purposes they would look like a text file and could
probably be compressed as such. Again at least that is my thinking at
this stage.

If you can think of other ways to approach this situation then I would
be most happy to explore them.

Kind Regards

The Frog

Re: ZIP code module without DLL dependencies???

am 29.11.2007 01:49:14 von Chuck Grimsby

I have so many thoughts on this, I scarcely know where to begin!

First off, if this data *really* needs to be secure, if it contains
things like SSNs, credit card number, drivers license information,
health information, etc., then you shouldn't be making that data
transferable at all. Period. The consequences of making such data
"portable" has been well documented in the press, and can put you
(personally!) at legal (and perhaps financial) risk. The courts will
(and have) put the developer in the position of "they should have
known better".

However, if that's not the situation, and making the information
portable won't put you personally at risk, then I'd suggest using a
Secure FTP server to move the data around. You can zip it up if you
like to make the transfer faster (although if you're storing
information in a encrypted mdb file, zipping the file won't make it
smaller).

In addition, corporate policy can require WinZip or some other
compression program be on the computer. There are versions of WinZip
(or RAR) that will work on just about any platform or OS. If
corporate policy says they have to have it, then you're in luck! You
can use those dlls to accomplish your goal. However, I'd still
strongly suggest going the secure FTP server route these days. It's
less problematical for the end user(s) to just transfer a file, and
it's fairly simple to set up a Secure FTP server they can access from
where ever the heck they are. (There used to be companies that
offered those services, but I haven't heard of any for quite some time
now... It's simply too cheap to do "in house" these days.)

If this information is something that shouldn't be made portable, then
you may need to look at using a internal intranet server that can be
accessed via a secure VPN connection.


On Wed, 28 Nov 2007 00:30:42 -0800 (PST), The Frog
wrote:

>Hi Chuck,
>
>The basis for attempting this is that I must be able to 'push'
>sometimes substantial volumes of data out to field personnel who have
>limited access to network resources.
>
>The idea is to create a type of update file that carries the data, in
>an encrypted form, via email (Lotus Notes), from my 'master' data
>store / application out to the field personnel. I cannot guarantee any
>form of standardisation on their machines (despite the corporate
>standards policies), and so in order to be able to send the data
>efficiently and use it at the other end compression would be a good
>idea. I thought that perhaps given the age of the Zip format and the
>Deflate algorithm that someone might have written a VB / VBA module or
>class module to be able to use this functionality directly in
>applications.
>
>The encryption is not an issue to achieve, merely the incorporation of
>a suitable method of compression. The more I can build into the
>application itself the less likely I am to encounter problems with the
>setup of the machines in the field (approximately 200). Or at least
>that is my thinking and experience so far. The 'field' version of the
>application would have a function built in to read and incorporate the
>new data (and possibly instructions for modifictaion). In this way all
>that the field person has to have is an email address and the
>application would do the rest. At least, thats the theory.
>
>Perhaps there are some other ways that compression can be achieved? I
>am not sure exactly how large these update files would be, however for
>all intents and purposes they would look like a text file and could
>probably be compressed as such. Again at least that is my thinking at
>this stage.
>
>If you can think of other ways to approach this situation then I would
>be most happy to explore them.
>
>Kind Regards
>
>The Frog

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 29.11.2007 09:59:26 von The Frog

Hi Chuck,

Thanks for the feedback. Unfortunately none of those possibilities are
options dur to corporate doggedness. To get the IT group to actually
do something of this calibre is actually not possible. They simply
wont do it.

The information does need to remain secure, and I am s security
trained professional - I certainly know how to secure the data from
unwanted eyes and circumstances. It is a complicated process sometimes
that needs to be tested and borne out to make sure that it is reliable
and functional, but it can be done and done safely and securely with
minimal user discomfort. The methodology of course depends on the
environment and the risks involved. In short it needs to be planned,
and I am confident that the security model is ready for the next level
of testing. You dont need to be afraid of security or cryptography if
you understand the application of the technoligies to the risks
involved. For instance I would never bother with the security that is
built in to MS Access, it is for all intents and purposes exploitable
and insufficient for most remote management tasks. The level of
cryptography is also insufficient for the task at hand. The security
model I am using is based on the use of DAO fields that are defined
for the objects in the database as needed. The actual cryptographic
method used is an application of AES for the actual data payloads and
public / private key (and some MD5 hashing) for managing the keys to
the AES. In short it takes a lot to build it into an MDB but it can be
done and done reliably. I am using a combination of MAC and RBAC
security models for the implementation with absolutely no DAC.

The issue I find here is that the transmission of the data can be
secured to sufficient standards, and it must travel via the corporate
email system, but the updates may themselves be large. I intend to
transmit them as text format information (eg/ at .txt file would be
fine) and then compress it. I do not require the encryption mechanisms
of the zip programs, just the compression. I have already secured the
payload. I am really just looking for a way to crush a file to its
smallest possible size before transmission.

Any ideas?

The Frog

Re: ZIP code module without DLL dependencies???

am 01.12.2007 00:43:21 von Chuck Grimsby

On Thu, 29 Nov 2007 00:59:26 -0800 (PST), The Frog
wrote:

>I have already secured the
>payload. I am really just looking for a way to crush a file to its
>smallest possible size before transmission.
>Any ideas?

Sorry for the day's delay in replying. I was searching my archives.
I half-remember playing with some code that duplicated the LZH
compression scheme, but I can't seem to find any in a format I can
still open. The files I have are (I think) in the old Pro basic 7
format, that I didn't save as text. (I don't think I have a computer
that will still run that old programming language, darn it!)

You might want to spend some time at Planet Source Code or some other
site like that to see if they have any thing you can use.

Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 01.12.2007 01:49:09 von Stuart McCall

"Chuck Grimsby" wrote in message
news:sm71l353n1spt05tvbbfa2sab65p5us4pb@4ax.com...
> The files I have are (I think) in the old Pro basic 7
> format, that I didn't save as text. (I don't think I have a computer
> that will still run that old programming language, darn it!)

If you mean Microsoft Basic 7 Pro, I do. If you'd like to mail them over
I'll see if I can send you the text version. Remove 'un' from my addy to get
my real address. Might not be instant - I may have to play with the m/c to
boot it. For one thing the CMOS battery will be dead by now, but I have the
hard drive parameters, so I ought to be good to go.

Re: ZIP code module without DLL dependencies???

am 03.12.2007 13:13:44 von The Frog

Hi Guys,

Thanks for getting back to me. I have managed to locate the source
code claiming to be a powerbasic implementation of the ZIP Deflate
algorithm. I will send you a copy via email.

If I can reverse engineer it into a VBA implementation I will. I just
have to get the time to sit down quietly and do it. I will then post
the resultant code here in this newsgroup so we dont ever lose it :-)

Thankyou both for your help with this. I appreciate the guidance.

Cheers

The Frog

Re: ZIP code module without DLL dependencies???

am 04.12.2007 00:33:46 von CDMAPoster

On Nov 26, 9:56 am, The Frog wrote:
> It is interesting looking at the scripting options for this. Does
> anyone know if there is a way to make use of a library from scripting
> without having to register the dll? As David mentioned, it can be a
> problem to register such things in heavily controlled environments,
> and this is the case with where I work. There is also a problem with
> different platforms so the WinXP scripting solution will only work on
> a few machines.
>
> As a secondary point, I would like to ask for some advice on the
> possible creation of a 'zip' module / class module. The implementation
> of such a thing could be quite useful, especially if you could
> compress data sufficiently (eg with BLOB's) before stroing directly in
> the database, not to mention the standard file handling stuff. If one
> were to attempt such a thing, what would your considered opinions be
> on the most useful implementation of such a thing? I was leaning
> towards a class module with the necessary properties and methods to
> handle things, but I considered that there might be an issue with
> particularly large hunks of data, whereby it may be more efficient /
> effective to simply use a function to return the results of the
> desired compress / uncompress operation. Your thoughts would be
> appreciated :-)
>
> Cheers
>
> The Frog

I considered porting compression/decompression code to VBA, but both
normal image compression needs and encryption functions barely ran
quickly enough at it was using DLL's. As far as being able to
compress a file maximally, maximal compression for one class of files/
documents will not yield maximal compression for another class of
files/documents. With a lot of extra processing up front you can get
nearly optimal to optimal compresson for a single file/document by
using your own Huffman coding to minimize the Shannon Entropy in the
Zip file. BTW, I have a copy of Microsoft Basic 7 Pro also. I'm
finding this thread quite interesting and await hearing what your
final plan is going to be.

James A. Fortune
CDMAPoster@FortuneJames.com

In cryptography, FROG is a block cipher authored by Georgoudis, Leroux
and Chaves. -- http://en.wikipedia.org/wiki/FROG

Re: ZIP code module without DLL dependencies???

am 04.12.2007 09:25:40 von The Frog

I was not aware of the FROG encryption system. Interesting history to
it and potential applications especially considering the need for high
throughput on limited processing power.

It seems that unfortunately for FROG encryption that the reasons for
its being dropped from the 'New Encyption Standard' competition in the
states are quite valid. Weak keys are a deal breaker for an encryption
system. Still, with some work it might prove useful in the future.

Interesting to know, thankyou for the reference.

Any code developed I will post either in this thread or simply make a
new one in this newsgroup with an appropriate title. It probably wont
be until next year though due to time constraints at the moment.

Cheers

The Frog

Re: ZIP code module without DLL dependencies???

am 05.12.2007 01:05:39 von Chuck Grimsby

On Sat, 1 Dec 2007 00:49:09 -0000, "Stuart McCall"
wrote:

>"Chuck Grimsby" wrote in message
>news:sm71l353n1spt05tvbbfa2sab65p5us4pb@4ax.com...
>> The files I have are (I think) in the old Pro basic 7
>> format, that I didn't save as text. (I don't think I have a computer
>> that will still run that old programming language, darn it!)
>
>If you mean Microsoft Basic 7 Pro, I do. If you'd like to mail them over
>I'll see if I can send you the text version. Remove 'un' from my addy to get
>my real address. Might not be instant - I may have to play with the m/c to
>boot it. For one thing the CMOS battery will be dead by now, but I have the
>hard drive parameters, so I ought to be good to go.

Actually, I found a computer in my "collection" that could run BC7 (it
even still had windows 3.11 on it!), but the file isn't a BC7 file.
Nor a GW Basic file. It may be GFA Basic. I think I still have the
disks for that... If it's Pure Basic, or Real Basic, I'll have to dig
a bit deeper into the archives.

'Course it may be some other language... Hmmm... I wonder if it's
VB3? This could get interesting!


Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 05.12.2007 10:41:16 von The Frog

Hi Chuck,

I might just have to go through the whole lot on paper. I might even
try and locate an old dot matrix printer for the 'feel' of the
situation... I think there is an old Star NL-10 alround here
somewhere...

I figure that as long as I can follow the individual steps required to
make the thing work then I can probably reverse engineer it into a VBA
version. My interest is really the compression more than anything
else, so the 'file' stuff is secondary to my purposes but would be
good to have in there. I'll see what I can come out with over the
weekend.

By the way, do you know of any implementations (again DLL-less) in VBA
for doing error correction routines such as Reed Solomon? I started to
have a bit of a dig through and have found some C code to do the job
of encoding, but not for decoding. Adding Forward error correction
(FEC) capabilities would potentially be the last of the hurdles I have
to overcocme. I thought that since it has been around so long someone
might have done it in pure VB / VBA but I cannot locate anything
easily on Google. Do you know of anything?

Cheers

The Frog

Re: ZIP code module without DLL dependencies???

am 06.12.2007 00:55:36 von Chuck Grimsby

On Wed, 5 Dec 2007 01:41:16 -0800 (PST), The Frog
wrote:

>Hi Chuck,
>I might just have to go through the whole lot on paper. I might even
>try and locate an old dot matrix printer for the 'feel' of the
>situation... I think there is an old Star NL-10 alround here
>somewhere...
>I figure that as long as I can follow the individual steps required to
>make the thing work then I can probably reverse engineer it into a VBA
>version. My interest is really the compression more than anything
>else, so the 'file' stuff is secondary to my purposes but would be
>good to have in there. I'll see what I can come out with over the
>weekend.
>By the way, do you know of any implementations (again DLL-less) in VBA
>for doing error correction routines such as Reed Solomon? I started to
>have a bit of a dig through and have found some C code to do the job
>of encoding, but not for decoding. Adding Forward error correction
>(FEC) capabilities would potentially be the last of the hurdles I have
>to overcocme. I thought that since it has been around so long someone
>might have done it in pure VB / VBA but I cannot locate anything
>easily on Google. Do you know of anything?

Believe it or not, my *only* printer is a Star NX-1000. It's in the
top of the garage though... I keep it around "just in case", but I've
never found a need for it, or to even hook it up for that matter!
(It's amazing how little you find a "need" for a printer when there
isn't one available.)

As for error correction and Reed-Solomon, I can't say as I ever played
with Reed-Solomon. Simple CRC checking is all I ever used, and of
late, I've just been passing it through ImageHlp.dll and letting it do
the CRC calculations. It's been quite a while since I've had to do
any *serious* CRC calculations with data streams.

You might want to look for routines for creating pdf417 bar codes. If
memory serves, they use Reed-Solomon. ID automation might have a few
code samples. (Obviously, you shouldn't use their code directly as
I'm sure it's copyrighted.)

A search of Google Groups or planet source code should reveal quite a
few samples of CRC code as well. Just watch out for the ones that are
(supposedly) for credit cards, which also use CRC to catch keystroke
errors. Wait a minute! Here. Try this:


It's VB code for a 32-bit CRC, but it should work.

Oh, hey! Here's a link to some LZH code as well:


Again, VB code, but it should import ok. Wow, 1998. I should of
searched my newsgroup archives earlier....

---
Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!

Re: ZIP code module without DLL dependencies???

am 06.12.2007 10:42:00 von The Frog

Chuck you magnificent creature! That LZH stuff will work wonders. What
a great link. I was in the process of learning all about the different
possibilities for compression with different algorithms and lots of
stuff about information theory and data entropy etc.... but this
simplifies the process considerably. Seeing a practical example in VB
is a real boon. Great stuff.

The reason for the error correction code is due to the need to
transmit the data and give some level of certainty that the data can
be accurately reconstructed if it is received. Reed Solomon will be
perfect for one part of this, and CRC for another. In short I am
developing a transmission process for an app / concept I am working
on.

It basically goes like this:
1/ Dont trust the IT department and assume everything is non reliable
outside the application itself

2/ Code all necessary functions into the application itself.

3/ Application should be capable of adapting the content of itself
(within a certain framework) so that new forms, data, reports,
functions, etc can be reliably imported and / or replaced.

4/ All data in the application should follow (relatively) secure data
handling practices so that information not destined for a certain set
of eyes doesnt get seen.

5/ The application should be capable of operating completely
remotely / stand-alone so that disconnected employees can still be
kept up to date

6/ Transmission of 'updates' needs to be done in discrete 'parcels' so
that the latest versions of things can be sent when needed and not the
entire application.

7/ Transmission needs to be reliable, deliverable and secure. (Error
Correction (FEC), Compressed (eg. Deflate), Encrypted (Combination AES
and Public / Private)

8/ The application has to be able to send a 'request' or 'report' to
the 'master' so that component version control can be done.

9/ The application has to be able to work in an integrated fashion
with the users email application if possible - or else update /
control can be manually done.

10/ The application should be based in standard MS Office components,
in this case Access (97).

Why go to all this effort? Simple: My company works in the
technological stone age and the acquisition of budget to approach any
development in a more serious way simply wont be forthcoming (at least
as far as my boss and I can see). If you let accountants run a
business you no longer have a business, you just have accounting -
investing in infrastructure must therefore have benefits that the
accountants agree with and the ones here, regardless of the financial
and workload (productivity) arguments you put forward, are simply not
interested and are actively seeking to remove budget from all other
departments. So in short I am boned for money, but have the time, so
onward I will go......its better than nothing and I hope will actually
work quite well. Its a hell of a lot of work though.

After I get a chance to play with the code a bit for the LZH and
become familiar with it, I will try and expand it to handle unicode
and also maybe a binary version (or byte array version).

I have found some source code in C for the Reed Solomon coding (I love
the internet way back machine), and will play with that over the
christmas break on the bad weather days and see what I can come up
with.

In the end I am developing a process. I will post the outcome (code)
for that here, and some instructions for its use. It should be a
method of both preparing and receiving data that will be about as good
as it gets - how you transmit it would be up to you.

With all the help others have contributed here I do hope that it will
be found useful. Even if it is just for 'secure' backups of data in a
text type format.

The way I envision the 'method' to work is to first create the error
correction (Reed Solomon) output, then to compress it, then to encrypt
it, then to encrypt it (AES), then to encrypt the key with a public
key, and reverse the process (use the private key of course) to get it
back and know that it is as it should be.

Thankyou all for the help and guidance. Thankyou especially Chuck and
Stuart. I will post the finished code here sometime in the early new
year when I get back from holiday. I will use this thread.

Cheers and many many thanks

The Frog