How to use pkZip/Unzip dynamically ... ?

[DienyduToit]

How does one use PkZip and PkUnzip dynamically at runtime? In
PbDOS it was easy -- shell with command line.

Using the 32 bit pkUnzip requires user response, which is exactly
what I don't want. The code below (using the old 16 bit pkUnzip)
works, but when extraction is complete, it requires one to click
on the X (exit) at the top right of the screen above the DOS
window. Can this be automated? I find, as in the case of tab
controls, no reference to the subject in Petzold Edition 5.

Any advice will be greatly appreciated!

Sub AccessArchive (ByVal Key$)
 Local cpn As Asciiz*100
 Local Opr As Asciiz*10
 Local Fle As Asciiz*30
 Local Pms As Asciiz*30
 Local Dfd As Asciiz*16
 QutStg&=2

 s$ = CurDir$
 ach$=Mid$(mnu$(CurrItem&),79,8)    ' e.g., X0018184 - name of a file contained in the Zip file
 ChDir Left$(lhd$,Len(lhd$)-1)      ' destination directory for                                     ' extracted file
                                    ' kdd$ below contains (e.g.) \QX00                                     ' directory containing the zip                                     ' archive
' Opr="open"
' Fle=s$+"\PKZIPW.EXE"                   'This calls the 32-bit zipware                                          'and seems to require
' Pms="-o "+kdd$+"ARCHIVEA "+ach$        'user response which in this                                          'case is not wanted
' Dfd="\WpDDT"
' n&=ShellExecute(hDlg&, Opr, Fle, Pms, Dfd, %SW_MAXIMIZE)

 shl$=s$+"\pkUnzip.Exe -o "+kdd$+"ARCHIVEA "+ach$      '+Chr$(10)+"Exit"                                                     'This calls the old 16-bit
'MsgBox(Left$(lhd$,Len(lhd$)-1)+Chr$(10)+ach$+Chr$(10)+s$+Chr$(10)+shl$)                                                     'PkUnzip (1993 model).
'Exit Sub                                                                                                           'Extracts the file as
 Shell shl$, 3                                                                                                      'required, but then hangs
 ChDir s$                                                                                                           '(does not return to continue
 frf&=FreeFile                                                                                                      'executing subsequent steps until
                                                                                                                    'one click the EXIT at the
                                                                                                                    'top right above the DOS window)

 Open lhd$+ach$ For Binary As frf& Base=0

 Seek frf&,0
 Get$ frf&,Lof(frf&),f$
 Close frf&
MsgBox(Str$(Len(f$)))                                                                                                 'Correct file size is shown,
Exit Sub                                                                                                            'and the file is in fact
 If Len(f$)=0 Then                                                             (&c)...                              'present and correct.

------------------

[Lance Edmonds]

The easiest solution is to launch COMMAND.COM (or whatever is specified in %COMSPEC%) with the /c switch (which tells COMMAND.COM or CMD.EXE to close the window when the target app ends).

SHELL ENVIRON$("COMSPEC") + "  /c PKUNZIP.EXE <params>"

However, there are better ways, such as using one of the ZIP-compatible DLL's that are available.

There have been many posts on this in the past, so try searching the BBS for "dynazip" or "ZLIB" and you should find some suitable links/info.

I hope this helps.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Following works fine at least on my PC under Win2000.
BTW, I prefer to start Dos exe, using GetShortPathName.

   #Compile Exe
   #Dim All
   #Register None
   #Include "WIN32API.INC"
   
   $CmdLine = "pkzip c:\~test.zip"
   $InputFile = "NUL"
   $OutputFile = "NUL" ' "C:\~Output.Txt"
   $ErrorFile = "NUL"  ' C:\~Error.Txt"
   
   Function PbMain
     
      Dim PI As PROCESS_INFORMATION
      Dim SI As STARTUPINFO
      SI.cb = SizeOf(SI)
      SI.dwFlags = %STARTF_USESTDHANDLES Or %STARTF_USESHOWWINDOW
      SI.wShowWindow = %SW_HIDE
      SI.hStdInput = CreateFile($InputFile, %GENERIC_WRITE, _
         %FILE_SHARE_WRITE, ByVal 0&, %OPEN_ALWAYS, _
         %FILE_ATTRIBUTE_NORMAL, ByVal 0&)
      SI.hStdOutPut = CreateFile($OutputFile, %GENERIC_WRITE, _
         %FILE_SHARE_WRITE, ByVal 0&, %OPEN_ALWAYS, _
         %FILE_ATTRIBUTE_NORMAL, ByVal 0&)
      SI.hStdError = CreateFile($ErrorFile, %GENERIC_WRITE, _
         %FILE_SHARE_WRITE, ByVal 0&, %OPEN_ALWAYS, _
         %FILE_ATTRIBUTE_NORMAL, ByVal 0&)
      CreateProcess ByVal 0&, $CmdLine, ByVal 0&, ByVal 0&, ByVal 1&, _
         %NORMAL_PRIORITY_CLASS, ByVal 0&, ByVal 0&, SI, PI
      If PI.hProcess Then WaitForSingleObject PI.hProcess, %INFINITE: _
         CloseHandle PI.hProcess
      CloseHandle SI.hStdInput
      CloseHandle SI.hStdOutput
      CloseHandle SI.hStdError

      MsgBox "Finished"
   End Function

------------------
E-MAIL: [email protected]

[DienyduToit]

Thank you, Lance and Semen.

I tried the SHELL ENVIRON$("COMSPEC") etc., and it works perfectly.
You say, Lance, that there are better ways, and I did search as you
suggest, and found quite a few postings. Previously (before posting my query) I searched for 'pkzip' and 'pkUnzip', and found a LOT but very little that is relevant.

Now, this SHELL ENVIRON$("COMSPEC") works, and that's all I need.
It requires minimal coding, and does what is required. (Semen, your code may apply in more demanding situations, but I have a zip file containing a number of files, ALL of which are named 'X0nnnnnn' i.e., an X followed by a seven-digit number. No path recursion, nothing. Totally simple). So, for my purpose in this case, the SHELL ENVIRON$ answers my query completely and satisfactorily, and nothing can be better than that, surely! Absolutely the only possible criticism is that when it executes, the screen momentarily blacks out, but returns almost instantly with the next screen already in place -- this on an old 166Mhz Pentium from a previous century. On an up-to-date PC this may be hardly noticable.

Thanks to you both for your time and trouble.


------------------

[Semen Matusovski]

Dieny and Lance --
under 9x console window will not be closed, if there is no a special flag in properties
"close a window after finish"
That's why I wrote a fragment which prevents console window appearance at all.
Otherewise it's necessary to correct PIF-file.



------------------
E-MAIL: [email protected]

[Lance Edmonds]

Semen, the "/C" switch for the command interpreter should always close the DOS window... I guess there could be complications, but that switch is the MS recommended technique to automatically close a DOS window when the commmand interpreter is started via SHELL.

Out of curiousity (I've not had time to test this idea), what happens if the DOS app requires user intervention during the process (when it's console is hidden), maybe because a file already exists in the target folder, a device I/O error occurs, the ZIP is corrupted, etc.

In other words, can a Synchronous SHELL become indefinitely halted in this kind of situation? What has been your experience?




------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Lance --
First of all, best wishes to you (and to all) in new millenium.

> Semen, the "/C" switch for the command interpreter should always close the DOS window

No. Flag /C tells command.com to stop it's work and nothing more.
Make following simple test under 9x.
Start command.com. Click caption (right button). Properties.
Turn off a flag "close window, when finished".
Exit and close this window.

Then run

#Compile Exe
#Dim All
#Include "WIN32API.INC" 'Some include files

Function PbMain
   Shell "Command.com /cdir"
   MsgBox "Ok"   
End Function

You will see opened window with "Job is finished" in caption.

About
> what happens if the DOS app requires user intervention during the process (when it's console is hidden), maybe because a file already exists in the target folder, a device I/O error occurs, the ZIP is corrupted, etc.

Hangs, of course. But Ctrl-Alt-Del is able to solve any problem

------------------
E-MAIL: [email protected]

[Lance Edmonds]

Right. You have to actually unset the "close on exit" checkbox in the Properties dialog, since the default Windows setting is to close the window on termination of the command interpreter (and in which case, the /C switch will ensure the window is closed, since the command-interpreter will have terminated). I realize that this means it is not 100% fool-proof, but do you think many customers' PC's are likely to have had the default settings altered?

Still, IMHO, it would be much easier to have the User click the Close button of a DOS window occasionally, than to have customers ringing/emailing and asking why your program "locks up" when doing a Backup or Restore (with a hidden console)!

Happy new year!!!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Semen Matusovski]

Lance --
In russian releases default is "turn off".
I know this exactly, because after each reinstall of Windows 9x I set this flag "turn on" for DOS apps.
Difficult to imagine that in another local releases the situation is not the same.

I agree that it's necessary to use hidden console very carefully.
But from another side, to mix GUI and consoles is not nice also.
One sample, well-known for VB5/6 users: "Package and Deployment Wizard" uses makecab internally.
Makecab is a console app, but it's window is invisible.

I am not sure that Microsoft uses the same way as I.
May be somebody knows alternative ways to hide a console ?


[This message has been edited by Semen Matusovski (edited January 01, 2001).]

[Edwin Knoppert]

You can use the start.exe /w in windows

Also using a AllocConsole to execute a dos app is really working fine too.

AllocConsole
Shell(...) < synchronious shell required..
FreeConsole



------------------
[email protected]

[Edwin Knoppert]

just placed an example of calling a dos app.
http://www.powerbasic.com/support/pb...ad.php?t=22876



------------------
[email protected]

[Semen Matusovski]

Edwin --
Pre-allocated console solves a problem with closing of window, but doesn't prevent it's appearence

------------------
E-MAIL: [email protected]

[Edwin Knoppert]

Of course not, but you can hide the console (afterwards)
But the console should be used for visible apps only.
If someone is using a DOS zip tool from windows, he's not on the right track i think.
(Sometimes the easiest approach tough)
I suggest for this part. using a DLL like zlib or sort of.
I'm just providing a small way to execute a DOS app from within Windows.
(A dos app meant to interact with)



Happy new year.

------------------
[email protected]

[Semen Matusovski]

Edwin --
First of all, Happy New Year too

My GUI utility, which updates a release from Internet, uses unrar (similar pkunzip).
I have an idea to replace rar-files to cab (here I can use API to extract files).
But I need to crypt some files and have no idea, is it possible for cabinet files.
May be you know ?

------------------
E-MAIL: [email protected]

[Edwin Knoppert]

I have no idea, only to scramble the file of course..


------------------
[email protected]