CallBack Function

[Gordon Padwick]

Can anyone provide a detailed explanation of how to use Callback functions.
Some books contain a specific example of a Callbook function, but none that
I've found really explain how Callback functions work.

I'm working on an Access 2000 database that needs to provide the user with a
means to navigate through Windows folders in order to find a folder that
contains specific text files. It seems that a Callback function should be
able to provide a list of folders in an Access list box, from which a user
can select. So far, I've not been successful in making this work, primarily
because the literature doesn't adequately explain the Callback function.

I originally looked for an an API that would provide access to a Windows
Explorer screen from which the user could select the required folder, but
didn't find one.

I'll appreciate any suggestions for how I can incorporate a means for the
user of an Access 2000 application to display the tree structure of folders,
select a specific folder, select a text file in that folder, and import that
text file into an Access table.

Gordon

 

[Wayne Morgan]

Actually, the API call is probably going to be your best option for this.
See if these links help, the first one is probably the one you want.

http://www.mvps.org/access/api/api0001.htm
http://www.mvps.org/access/api/api0002.htm

 

[Gordon Padwick]

Thanks for your suggestions, Wayne. However, I don't think what you
suggested lead me in the right direction. The first link you suggested
showed an enormously complicated solution, something I didn't want to
tackle. The second link, much simpler, didn't provide what I needed.

I went back to my Access books and found a simple solution to creating a
list box containing the names of files in a folder in F. Scott Barker's book
"Microsoft Access 2000 Power Programming" (ISBN 0-672-31506-8). Listing
15.3, on pages 532 and 533, showed a simple callback procedure I was able to
adapt to do what I needed.

I thank Scott for providing this information.

From what I can gather, callback procedures provide powerful capabilities,
but are not adequately described. Can anyone refer me to good sources for
information about callback procedures?

Gordon

 

[Douglas J Steele]

No offense, Gordon, but does it matter if you understand how the API
solution works? All you need to do is copy-and-paste what's between Code
Start and Code End into a new module and save that module (making sure that
the name of the module isn't the same as any of the routines within it)

Once you've done that, it takes very little code to use it. As the example
at the top of the page shows, to allow the user to select an Excel file,
you'd use the following 4 lines of code:
Dim strFilter As String
Dim strInputFileName as string

strFilter = ahtAddFilterItem(strFilter, "Excel Files (*.XLS)", "*.XLS")
strInputFileName = ahtCommonFileOpenSave( _
Filter:=strFilter, OpenFile:=True, _
DialogTitle:="Please select an input file...", _
Flags:=ahtOFN_HIDEREADONLY)

 

[Gordon Padwick]

Yes, it does matter to me how the API solution works. It should matter to
every programmer that they understand how every part of their program works.
Otherwise, when things go wrong, as they aften do, how can the programmer
fix them?

While the API-based solution might well solve the problem I had, a callback
function provides a much simpler solution. As I explained previously, I've
been able to develop a callback function that almost completely solves my
problem. There are still a few minor wrinkles I have to resolve. When I've
finished, I'll post the solution so that others can benefit.

Thanks for your help.

Gordon

 

[Douglas J. Steele]

Sorry to be argumentative, but I can't believe that any callback function is
"a much simpler solution".

I'm assuming you're talking about the standard callback function that looks
something like:

Function functionname(fld As Control, id As Variant, row As Variant, col As
Variant, code As Variant) As Variant

and you set the list box's RowSource property to point to that function.

Do you understand how it works? You doubtlessly understand what each value
represents, and what code you need to include to react to each value, but do
you understand how it populates a listbox the way it does?

Using the File Dialog API is a Windows standard. Since it provides a user
interface which is consistent with other applications in Windows, I would
think it should be the preferred approach. To understand more about how it
works, check what Randy Birch has at
http://vbnet.mvps.org/code/comdlg/filedlgsoverview.htm

 

[Douglas J. Steele]

I may have come across too cross. It IS your application, after all, so if
you're happy with the listbox, that's your decision. I just happen to prefer
using APIs.

 

[Larry Linson]

I may have come across too cross.

I don't think you did, Doug.

There was a time when a programmer should have known how everything in
his/her application worked; that was a long time ago, applications were
much simpler and much less user-friendly, and computers were powered by
vaccuum tubes. I lived through that time, perhaps only due to luck and a
strong constitution...

Now I am happy to live in a "more complex" world where I can use vast, huge
amounts of other people's code without _having_ to understand it. Just
imagine how many millions of lines of code make up Windows, and Access, that
we (and Gordon) happily use every day without knowing how those millions of
lines of code accomplish their purpose.

It IS your application, after all, so if you're happy
with the listbox, that's your decision. I just happen
to prefer using APIs.

Question: Is it _really_ Gordon's application, or is it Gordon's employer's
application, or Gordon's customer's application? Most of the applications
that I have done over the years were either an employer's or a customer's
application, because that is who was paying to have it done. If it is the
employer's or the customer's, it is incumbent on the developer to do it the
way that is best for the employer (usually determined by the users in that
employer's company) or the customer.

Only now, after retiring and unretiring twice do I write any significant
number of applications that are _mine_. And, even so, I consider that the
user audience that I am trying to help is more important than my views on
how things should be done.

Larry Linson
Microsoft Access MVP