User-Defined RowSourceType function, undocumented features?

  • Thread starter Michael Suttkus, II
  • Start date
M

Michael Suttkus, II

While working on a User-defined RowSourceType function, I noticed two points
of interest.

First of all, the documentation for defining the function lists 9 different
constants that may be passed to the function through Code. However,
acLBClose (value 8) is supposedly not used. In testing, it actually is
called, just before acLBEnd (value 9) is. Is there an underlying purpose for
this? Is it for legacy code?

Even more mysteriously, when the constants are examined, they run from 0
(acLBInitialize) to 9 (acLBEnd), except that 2 is not given. However, Code=2
is called for the function, between acLBInitialize (value 0) and acLBOpen
(value 1) and sometimes between successive calls to the supposedly unusued
acLBClose! Is there some undocumented purpose here?

I'm just curious.
 
M

Marshall Barton

Michael Suttkus said:
While working on a User-defined RowSourceType function, I noticed two points
of interest.

First of all, the documentation for defining the function lists 9 different
constants that may be passed to the function through Code. However,
acLBClose (value 8) is supposedly not used. In testing, it actually is
called, just before acLBEnd (value 9) is. Is there an underlying purpose for
this? Is it for legacy code?

Even more mysteriously, when the constants are examined, they run from 0
(acLBInitialize) to 9 (acLBEnd), except that 2 is not given. However, Code=2
is called for the function, between acLBInitialize (value 0) and acLBOpen
(value 1) and sometimes between successive calls to the supposedly unusued
acLBClose! Is there some undocumented purpose here?

I'm just curious.


Well, I might be curious about this too if were of any
importance. As far as I know, those are not useful and I
always ignore them in the Select Case statement.
 
M

Michael Suttkus, II

Marshall Barton said:
Well, I might be curious about this too if were of any
importance. As far as I know, those are not useful and I
always ignore them in the Select Case statement.

Curiosity respects not this "useful" concept! Where would mankind be if
people only looked into obviously useful things? Electrical induction was a
useless curiosity for over a century before anyone used it to invent radio!
Useful comes *after* curiosity has been satiated!
 
M

Marshall Barton

Michael Suttkus said:
Curiosity respects not this "useful" concept! Where would mankind be if
people only looked into obviously useful things? Electrical induction was a
useless curiosity for over a century before anyone used it to invent radio!
Useful comes *after* curiosity has been satiated!


Well, they're not important enough for MS to remember to
include them in the documentation or to keep the
documentation up to date with reality. Remember that MS's
position is that if it's undocumented, they can do whatever
they want with it, including throwing it out or using it for
some entirely different purpose. If they failed to fix
their code to reflect the documentation, that's their
business, whether we agree with it or not. The fact that
neither of us has found a use for them just adds to the
argument's weight.

I suppose that you could think of them as the original
designer's assumption that there should be parallels to a
form's Open/Load and Close/Unload events, but that there is
no need for those callback hooks in real situations.

I guess I should have provided an expanded explanation in my
original response. I went through the same kind of
exploration of this feature several versions ago and came to
the bottom line conclusion that I posted earlier.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top