Quick question about the VB Installer

[HarryC]

When installing a app created with default VB deployment wizard I get
a message that I'm not sure exactly what it say but it says

"You are trying to copy a file that is older than ....
Do you want to keep this file"

I have been answering Yes to this thinking that the machine that you
are installing on has a newer version and I want to keep the one
on the machine. Am i thinking right on this ?

Thanks
Harry

[Deanna Earley]

That's what the dialog says so yes.

--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[HarryC]

Thanks Deanna,

You would think that Microsoft would have worded that message a little
less confusing than they did.

Harry

[Deanna Earley]

You have the source code :)

Having said that, there are far better options than PDW, like Inno Setup.

(Oh, and please use the reply/follow up button when replying or
following up to a UseNet post.
Creating a new thread just confuses things.

[ralph]

In addition, this message refers to 'shareable' DLLs, and in most
cases you can totally eliminate these messages by NOT including extra*
files in your PWD package.

[* 'extra' defined as anything not an authored component of your
application nor required by Startup.]

PWD comes from a time when it was 'safer' to be safe than sorry, and
likely targets were far more varied with installed versions than
today. The Wizard reads a project's dependancies, consults the VBdep
file then, quite helpfully <g>, includes anything it comes up with.

Without going into a long list of items you can safely remove, just
post the list of components you are currently including and we'll show
you what you can remove.

[Note: If your target is Windows 2000 or greater, it is highly
unlikely a 'newer' non-authored component would ever be replaced even
you insisted. <g>]

-ralph

[HarryC]

On Thu, 07 Mar 2013 11:21:17 -0600, ralph <nt_con...@yahoo.com>
wrote:

Forgot about the reply button :)

Deanna, ralph - I just wanted to make sure I wasn't telling people to
do something that was harming their computer, but since the oldest
computer is an XP it sounds like I couldn't mess it up anyhow.
The machine in question is Windows 8 which when the app was installed
it worked perfectly then all of a sudden our app slowed down to a
crawl and some menu choices quit working. I thought that maybe
I had over wrote some need files. But all the other apps on the
computer still work fine.

Ever hear of this ?

[Mike Williams]

"HarryC" wrote in message news:2pdhj8luv2hvnfc6n...@4ax.com...

I don't use the VB Package and deployment Wizard myself so I could be wrong
on this, but I seem to recall there being a logic problem in the coding of
the Package and deployment Wizard where it gets it the wrong way around
under some circumstances and replaces files only if the existing file is
/newer/ than the one it is about to replace it with, which is of course
completely back to front. If this is the case with your copy then you need
to correct the problem in the PDW code and recompile it. Someone else here
who uses the thing will know for sure.

Mike

[Mayayana]

| The machine in question is Windows 8 which when the app was installed
| it worked perfectly then all of a sudden our app slowed down to a
| crawl and some menu choices quit working. I thought that maybe
| I had over wrote some need files. But all the other apps on the
| computer still work fine.
|
| Ever hear of this ?
|

That's a very general question.

On the PDW, there's no reason to ship any system
files. You can't install them, anyway. If you're shipping
your own DLLs don't mark them as shared. (Assuming
they're not.) Shipping newer system files won't hurt, in
the sense that XP+ won't let you install them. But it
would put the PDW into a reboot loop. It arranges to
install the system files during reboot, then finds they
didn't install and starts all over again. (There was no
System File Protection in '98.)

As Mike said, there is a slight bug in the code as well.
It's not critical. It's just that when the PDW compares
files it checks the versions, which works fine, but if it
can't find versions it will then check dates. The date code
is backward, so that the PDW would try to install the older
file in that case. But none of that should matter because
it shouldn't be trying to install anything -- and you shouldn't
be shipping anything -- that's a system file.

As others have said, there are other free installers
available. On the other hand, the PDW source code is
available so that a PDW install is entirely customizable.
If you're curious I have two updated and cleaned up versions
here:

http://www.jsware.net/jsware/vbcode.php5

One version is just a cleaned-up version of the PDW with
some updated functions added, like Desktop shortcut option,
App Data folder creation, etc. The second version is a further
rewrite that eliminates the need for setup.exe. Setup.exe
is a C++ EXE that was only needed because the VB6 runtime
was not always installed on target PCs. But the VB6 runtime
has been a system file since Windows 2000, and setup.exe
also did some ugly things -- like that weird gray borderless
window at startup that says something like, "Please wait...",
and some odd behavior that involved moving the install files
into \Windows\ before running the install.

The updated versions linked above are more work, but there
are full instructions with them, and if you use your own rewrite
of setup1.exe you get the advatage that you can fully customize
the UI, add your own license clickthrough, and add just about
any other functionality you like. Since all PCs now have the
VB6 runtime there's no reason that an installer has to be other
than VB.

[ralph]

On Thu, 07 Mar 2013 12:46:09 -0500, HarryC wrote:

>On Thu, 07 Mar 2013 11:21:17 -0600, ralph <nt_con...@yahoo.com>
>wrote:
>
>Forgot about the reply button :)
>
>Deanna, ralph - I just wanted to make sure I wasn't telling people to
>do something that was harming their computer, but since the oldest
>computer is an XP it sounds like I couldn't mess it up anyhow.
>The machine in question is Windows 8 which when the app was installed
>it worked perfectly then all of a sudden our app slowed down to a
>crawl and some menu choices quit working. I thought that maybe
>I had over wrote some need files. But all the other apps on the
>computer still work fine.
>
>Ever hear of this ?
>

"slow down"
"menu choices not working"

This means that for whatever reason the App has gotten into an endless
loop, or otherwise wasting cycles unexpectedly.

If the App worked fined on one platform and shows problems only on
another, then the most likely culprit is a difference in data between
the two environments.

[1. A count in one environment that seldom exceeded a few hundred
during tests is suddenly seeded to very large value.
2. A check for a changed value misses the specific value.
3. Magic numbers valid in one environment are different in new
environment.
4. ...

You know your own app so can likely 'think-out' where these things
might be occuring.]

The problem is easily resolved IF you can either install VB6 or WinDbg
on the Windows 8 box. Run in the debugger and periodically peek to see
where the App is spending its time. Otherwise you may need to
instrument a 'debug' version of your App that logs its activity to a
file.

-ralph

[HarryC]

On Thu, 7 Mar 2013 17:11:38 -0500, "Mayayana"
<maya...@invalid.nospam> wrote:

Mayanyana - Thank you, I'm going out and look at your samples.

[HarryC]

On Thu, 07 Mar 2013 17:14:14 -0600, ralph <nt_con...@yahoo.com>
wrote:

ralph

the program was created on an XP machine. It works fine on 98, XP,
Vista, & Windows 7.
I bought a Samsung tablet with Windows 8 (full version) on it and
installed it on that one also. It's working on it.

The program is more of a database (Access) heavy processing type.
could this be a problem ?

[ralph]

On Thu, 07 Mar 2013 18:54:02 -0500, HarryC wrote:

>On Thu, 07 Mar 2013 17:14:14 -0600, ralph <nt_con...@yahoo.com>
>wrote:
>
>ralph
>
>the program was created on an XP machine. It works fine on 98, XP,
>Vista, & Windows 7.
>I bought a Samsung tablet with Windows 8 (full version) on it and
>installed it on that one also. It's working on it.
>
>The program is more of a database (Access) heavy processing type.
>could this be a problem ?
>

Possiblily.

At this point only three things are known for sure ...

1) Once discovered the problem will be blatantly obvious.
2) It will be found entwined in code managing flow control that you
*know for a fact* is absolutely error and problem free.
3) Repairing the problem will be quick, simple, and totally out of
proportion to the length of time it will take to discover its
location.

-ralph
<g>

[R C Nesbit]

Ralph spoke:

> At this point only three things are known for sure ...
>
> 1) Once discovered the problem will be blatantly obvious.
> 2) It will be found entwined in code managing flow control that you
> *know for a fact* is absolutely error and problem free.
> 3) Repairing the problem will be quick, simple, and totally out of
> proportion to the length of time it will take to discover its
> location.

<applause>

--
Rob Pearson

[HarryC]

On Fri, 08 Mar 2013 09:54:02 -0000, R C Nesbit <sp...@ukrm.net> wrote:

After that I can now tackle the problem with a smile.

[Schmidt]

+1 ...yeah, nice one. :-)

Olaf

[R C Nesbit]

Ralph spoke:

> 1) Once discovered the problem will be blatantly obvious.
> 2) It will be found entwined in code managing flow control that you
> *know for a fact* is absolutely error and problem free.
> 3) Repairing the problem will be quick, simple, and totally out of
> proportion to the length of time it will take to discover its
> location.

4) If you are doing this for a customer and try to charge by the hour
they will say *HOW MUCH*?

--
Rob Pearson