User-Defined Functions in RowSourceType

[Michael Suttkus, II]

I've just discovered this rather useful technique, but I have a few questions
that do not seem to be covered in Microsoft's documentation. I'll be
performing some experiments, but I'll take whatever comments or links people
would like to provide.

1. Is acLBInitialize called once per control, user, application, or what?
Since the ID parameter isn't set until acLBOpen, I'm guessing it's not once
per control.

2. In a multiuser environment, do I have to worry about the same control
being filled by two different sets of calls to the function? Is this what
the ID field is supposed to clear up (as opposed to just basing it on fld)?

3. What can I do with acLBGetFormat? There seems to be no documentation on
this other than setting it to default by returning -1.

 

[Douglas J Steele]

See whether
http://msdn.microsoft.com/library/e...owSourceTypeFunctionParameters_HV05187987.asp
helps

If you're concerned about multiuser use, I suspect you haven't followed the
recommended approach of splitting your database into a front-end (containing
the queries, forms, reports, macros and modules) and a back-end (containing
just the tables). Only the back-end should be on the server: each user
should have his/her own copy of the front-end, preferably on their hard
drive. With that setup, you wouldn't have to worry at all. Having users
share the same database significantly increases the probability of database
corruption. (If you still need the answer after that, it's that it shouldn't
be a problem: each user has his/her own copy of the shared objects working
on their machine)

For the acLBGetFormat value, you can use a valid format. For instance, if
one of your columns is numeric, you could return "0.00" as the format for
that column, and you'll only get 2 decimal points in the display.

 

[Michael Suttkus, II]

Thank you very much for your quick response!

I can't believe I didn't realize how acLBGetFormat worked. It seems rather
obvious in hindsight. However, I don't see the point in it. Experiment
reveals that there is no distinction between the final value of a row and the
value as modified by the format. For instance, if a particular row,col is
returned as acLBGetValue=15 and acLBGetFormat ="$0.00", when the row is
selected by the user, the combobox's value will be "$15.00". Why have two
seperate calls to the function when the programmer can just as easily return
Format(15,"$0.00") to acLBGetValue and never use acLBGetFormat at all?

I'm very new to the multi-user environment and have never looked into
front-end/back-end architecture. I'll take your comments as a hint that I
should read up on them sooner rather than later. I've been following the
pattern set by the database designer who previously built apps for my
department and his are all single-file arrangements. However, since his
level of skill in DB design doesn't seem as advanced as mine (and I don't
claim to be an expert!), I'm reasonably sure that's not a good idea.

It seems a simple enough arrangement, and very in keeping with OOP. The
problem is that I'm not sure I can know who is going to be needing access to
the database or that I will be able to set up a distribution to such users
when I make adjustements to the front-end. I suspect this is a problem for
another thread, however, and I'll do some research into principles and
practicals before bothering you fine people further!

Thanks again!