RE: RTFM (was: CPYF behavior) -- MIDRANGE-L

Jim,

I agree.  Not shipping the correct version of shared dll's does happen a
lot...even to us C++ bigots.

But you really should try to ship them.  One of the options in Install
Shield express is ""General Options" and there it has options for "Windows
Common Control".  You should probably check both of them.  It then grabs the
COMDLG32.OCX controls and dependencys.

And if that isn't getting what you want, you can manually add any object
into the WINSYS directory.

What tends to make your windows pgm croak is when a DLL is downlevel.  What
happens is you pass stuff to it that it is not expecting.  Most of the time,
an uplevel DLL is ok.  Please notice that I said "tends" and "most of the
time"...NOT always. It is after all, Windows.

Re the AS/400 and Service Programs, I the same thing can happen there.
Windows does check that the export does exist, and if it is C++, the
parmamer count and types.  But it does not check the values.

The AS/400 also checks that the export exists and I think that the parms and
parm types exist.  But it does NOT check the values either!  So it is up to
the service program provider to check these.

And if you change the parms, you must also recompile the requesting
pgm...sort of like a level check.

Is the AS/400 immune?  Nope.  However, more is checked so it is safer...as
we all know anyway.

Bob


-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of Jim Langston
Sent: Friday, January 21, 2000 10:50 AM
To: MIDRANGE-L@midrange.com
Subject: Re: RTFM (was: CPYF behavior)

Actually, Bob, this is a very, very common error, and if memory
serves me right, it is COMDLG32.DLL (Common Dialog 32 bit)
that is causing the problem.

In their infinite wisdom, Microsoft decided to change COMDLG32.DLL
from what it was in 4.0.  They packaged this new DLL in compilers and
IE 5.0, and stuck it on their web site as an upgrade.

Since COMDLG32.DLL is a "standard" DLL that all machines should
have, Install Shield doesn't include it in the install (from my experience
anyway).  What is just so irritating, though, is that when this library is
out of sync with the program, the program bombs with a hard error,
I seem to recall it's Page Fault error?  It seems there is no checking to
make sure the library the program is calling is the right version, and the
program will try to run something with a pointer leading into the library
where it shouldn't..

Which brings up a good point, what will happen on the AS/400 in this
scenario?  If I have a service program that I change, I don't' have to
recompile my programs, right?  So in the AS/400 somewhat immune
to this type of problem?

Regards,

Jim Langston

Bob Crothers wrote:

> Perhaps the step you missed was to TEST those 5 programs?  On a machine
> other than the development system?
>
> The "generic" stuff your programs did was internet stuff if it was MSIE v5
> that was required.  That, or you did not check other dependencies such as
> CommDlg32.dll (common dialogs), mfc42.dll, msvcrt.dll,  and since you are
> probably using VB, a whole slew of OCX's.

<SNIP>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---