Comments by dg6yhw11 (Top 18 by date)

Not after the Edit.

Thanks

Thanks. What a wonderful list of useful properties and methods.

But how does one get around this?

"The Array class is the base class for language implementations that support arrays. However, only the system and compilers can derive explicitly from the Array class. Users should employ the array constructs provided by the language"

Thanks for answering. Actually the app was born in TurboBasic in the early '90s and was ported to VB6 when DOS died. The old Option Base let you select the default lower bound but you could always use whatever you wanted.

I looked into using constants and enums but they're too clunky and rigid. The beautiful thing about using years is the program is self-updating - at least in those areas where I can just use the System Year.

The other issue is I always try to use LBound() and UBound() in loops to avoid those Error 9 situations.

It almost seems like MS doesn't want us to use arrays any more but I can't figure out just what they intend us to use instead. A lot of engineering and accounting math works really well using arrays.

The matter is closed.

I really do appreciate all you've done, seriously.

Murray

Sergey - that was an attempt at humor.

In American English the terms DOS Box and Command prompt are identical. You use a command prompt to open a "DOS box". There is no difference. There is a "box" (= window) that is running MS-DOS, therefore it becomes a "DOS box".

There is no "technical" term "DOS Box" in Microsoft Literature that I know of.

Google it - you'll see many old references to the term: example from some university "Open a DOS Box (Command prompt)...".

You can tell I'll never be a diplomat :)

OK. You win.

I'll stop calling it a DOS Box and refer to it as a "little black and white window that runs DOS programs and shows DOS commands" - or is it no longer correct to call it DOS, perhaps we should call it "command line character strings display area that can also run DOS programs"?

Sheesh!

Thanks for all your comments, Sergey.

The issue is not if PKZIP25 can properly unzip the file. It does. The zip file contains many more files than the one .exe and they all extract just fine. I have no reason to believe that PKZIP will consider program bits to be any different from data bits.

I said your solution does not address the issue because the issue is that the file is not written to the disk when it is unzipped, AND this is new! The PKZIP worked perfectly, extracted all files, in early March. Now for some mysterious reason it no longer works for .exe files.

It was my hope that someone would know if, perhaps, M$ had added some new layer of security or whatever that only affected programmatic writing of executable files to the disk... or something similar.

We use VB6 because our software works. There is no advantage to our users to try to go from a stable, compiled environment to something bloated, interpreted and god-awfully slow, that only offers features that benefit our programmers doctors (by requiring much hand surgury due to all the typing!!!) To all you soon to be commenters yes - I know about intellisense.

We sell heads-down keyboard entry software where speed and accuracy is of utmost importance. There is no bling wanted or needed.

It would be much greater torture to rewrite all that code :)
Murray

Kind of stong, Sergey.

I'm guessing that you might not be running US versions of Windows because the DOS box is very much alive in WIN 7 and WIN 8.

Perhaps I should call it by the term cmd prompt?

Doesn't matter, it is clear that you and other don't really understand the problem is NOT the decompression tool itself because it hase worked perfectly on the same machines with same OS before.

No the issue is that something is allowing the decompression utility to write any file EXCEPT an EXE and that this behaviour is new.

I didn't know that there was a conversion tool still around, other than the tools that would cost me $20,000 to use of course.

I had totally forgotten about interop. Thanks for that suggestion.

Murray

Thanks for the Solution Sergey but it doesn't address the root issue.

Even though PKZIP25 is an ancient relic, it still decompresses the file.

The newer versions will still decompress the file.

The issue is that the OS or something is stopping that from being written to the disk.

Murray

The files are off the root on a stand-alone computer, or the root of a mapped network folder.

We call the VB6 Shell function. The command prompt always has admin priviliges when called by hand but I don't know the privilige level when its called programmatically.

Thanks for helping.
Murray

Thanks. I'll look into that.

We have been studiously avoiding .NET - our software has 245,000+ lines of code and moving it would be impossibly expensive.

Thanks for answering.

We write in VB 6.

The DOS box does still exist, albeit in very restricted size.

To execute the PKZIP25 we call the Shell function and it opens the DOS box.