Albert D. Kallal wrote:
[color=blue][color=green][color=darkred]
>>>Is it possible to use the class I've created to fill a continuous form?[/color][/color]
>
>
>
> No, not really. A class object is a "thing" of code.
>
> A form is a "thing" attached to a table, and is for viewing data.[/color]
Actually, a form has a Recorset property, which could be a table or query.
[color=blue]
> However, in code, you can often create sql, and use that for the source of a
> form. So, you perhaps might make some class object that takes some
> parameters, and then spits out some sql that can be use for the continues
> form.[/color]
One thing I've done in the past is write a cheeseball query something
like this:
select * from oneofmytables where 1=0
Then I just push programmatically created/modified SQL into that query
as needed.
A form certainly could then be bound to this doppleganger query. When
it's opened (i.e., OnOpen event handler), it could call a class method
which sets the query to the right SQL, which then generates the
recordset for the form to be bound to.
The class doesn't have to know about the form this way.
[color=blue]
> So, to fill a control, (eg: a combo box), or a form, you don't generally use
> code to "make" the data. So, a class object is really of very little use to
> "fill" a continues form.[/color]
For a combo/list box, you sure can push your own list of values
programmatically into their lists.
[color=blue]
> where class objects tend to shine is when you got a CODING problem, and that
> code starts to get very complex. So, use of your class objects will not
> pertain much to the user interface in terms of providing data, but these
> objects certainly allow you to "group" code and that object can also "hold"
> data that the code needs. So, the "key" concept here is that often you need
> code to work with some "data" and you also got "code" for that data.
> However, this tends to be a coding issue, and not that of providing data for
> a table, or in your case/question a form.[/color]
Well, they can also help to sort of isolate your business logic from
your interface layers, which is one thing that Access completely sucks
at (too bad tables & queries will never get their own VBA event handlers).
[color=blue]
> I talk about the "concept" as to "when" you would use a class object[/color]
here[color=blue]
>
>
http://www.members.shaw.ca/AlbertKal.../WhyClass.html
>
> To be fair, you certainly could write a class object that provides data for
> a combo box. However, that ability would be based on the fact that you
> "generate" the data that the combo box needs (that data would either be sent
> to a table, or returned as a "value list" that combo can use, or the 3
> possible way is to use a call back function. However, in all of these cases,
> you can, and could use standard code in place of that class object.[/color]
The 4th way is to just use a query as an empty SQL shell, and
programmatically push SQL into the query's SQL property, and refresh the
list/combobox...
[color=blue]
> So, the creating of a class object does not have some "extra" special
> ability to fill a combo box,. That class object is simply witten with
> regular VBA code.
>
> The whole idea and use of class objects is that you can DEAL BETTER with
> complexity in your code.[/color]
Another idea is to encapsulate some behaviors that are not possible to
do, but the only real examples I've seen (Access Devloper's Handbooks,
et al) are creating "custom controls" for forms.
So I've decided that they're not very useful in Access.
