Cautionary note re use of MVPS Common File Dialog

  • Thread starter Thread starter jfp
  • Start date Start date
J

jfp

In various posts, the use of the API wrapper supplied by Ken Getz and on
the MVPS website has been recommended. This is a good function, but it
has an intrinsic error in it which can trip you up if you attempt to
build upon it. The following has been submitted to the MVPS web site re
this:

re http://www.mvps.org/access/api/api0001.htm
( Call the standard Windows File Open/Save dialog box)

The code is dangerous in its assignment of the API return value to a VB
Boolean. As written (fResult = ...) the code works since fResult is
used only in the form "If fResult Then ..." If, however, the code is
modified and some other logic using "If Not fResult then ..." is added,
it will fail. fResult actually has a value of either 0 or 1 and is
hence not a real Boolean. Apparently, VB forms the "Not" by first
inverting the value and then subtracting 1. For a genuine VB Boolean,
[0, -1] => [-1, 0] and all is well. For a "C" language style boolean
(which is what the API uses) we have [0, 1] => [-1, -2], both of which
are interpreted by VB as True. Thus, regardless of value of fResult,
the expression (Not fResult) will always be True. (You may verify this
in the immediate pane via "? CInt(fResult)" and "? CInt(Not fResult)"

The API declarations need to be changed to return an integer and that
then needs to be converted into a VB Boolean as in "bGood = (fResult <>
0)"
 
Minor correction:
Since under Win32 an "int" in C is 32 bits, the API declarations really
need to be changed to return a Long.
-=-=
 
In various posts, the use of the API wrapper supplied by Ken Getz and
on the MVPS website has been recommended. This is a good function,
but it has an intrinsic error in it which can trip you up if you
attempt to build upon it.
Click to expand...

I'm not sure I completely understand the problem. Yes, the code is
depending on type-conversion performed by VBA when a Long value is being
coerced into a Boolean, but this should not create any problems with
these 2 conditions, based on how GetOpenFileName API is defined. If you
explicitly need the return value for something, then yes, the code
should be changed in your case to test against a Long.

If fResult then
or
if not fResult Then

According to the SDK specs on the GetOpenFileName function (for
example):

----
If the user specifies a file name and clicks the OK button, the return
value is nonzero. If the user cancels or closes the Open dialog box or
an error occurs, the return value is zero. ----

So, just the test for zero as the coersion does, works in this case.

Note that CInt gives you just the integer part, it doesn't take the
value's sign into account.


-- Dev
 
The exact problem i encountered:
I expanded the processing done after the user closes the dialog. Part
of this involved adding some code:
If (Not fResult) Then ...
Regardless of fResult (True or False), the expression (Not fResult)
always evaluated to True.
-=-=-=
 
Back
Top