Bound vs unbound controls.

[cr113]

Am I the only one who hates bound controls? It seems to me that for a
few extra minutes of initial coding, an unbound control is much easier
to work with. Currently I'm having to write an app in Access 2007 and
it seems that even the supposedly unbound controls are always trying
to "do something" to a database table. It's very frustrating and I'm
just curious if I'm the only one.

 

[Bernie]

I agree with you. Most of the time I'm displaying something in the control I
need more than the built in functions. Bounded is great for simple things,
but most of the code I write goest beyond that simple need.

Bernie

 

[Armin Zingler]

Am I the only one who hates bound controls? It seems to me that for a
few extra minutes of initial coding, an unbound control is much easier
to work with. Currently I'm having to write an app in Access 2007 and
it seems that even the supposedly unbound controls are always trying
to "do something" to a database table. It's very frustrating and I'm
just curious if I'm the only one.

You are not.

 

[Tom Shelton]

Am I the only one who hates bound controls?

Hate'em. Almost never use'm

 

[cr113]

Well at least I'm not the only one. The way Microsoft pushes the bound
controls I sometimes feel like I'm too old school.

At least in Visual Studio you can choose the unbound route. Unless I'm
doing something wrong it appears that even the unbound controls in
Access are still somewhat bound. For example I have supposedly unbound
Treeview and Textbox controls and I'm getting weird errors from the
control trying to execute the data update events. Arghhhhhhh!

 

[Cor Ligthert[MVP]]

I almost don't know anymore how to use database controls without
databinding.
(I use mostly ADONET and Linq by the way, seldom direct SQL commands).

In the beginning of doing that I had the same opinion as you, but that took
a very short while.

I've sometimes to do some maintenance on a VB6 solution and I've to think
than every time that I should take care how data is moved from controls to
the recordset and vice versa.

Cor

 

[cr113]

I almost don't know anymore how to use database controls without
databinding.
(I use mostly ADONET and Linq by the way, seldom direct SQL commands).

In the beginning of doing that I had the same opinion as you, but that took
a very short while.

How would you something simple like this:

Suppose you have 2 listboxes. The second listbox needs to be populated
according to which row is selected in the first listbox. In other
words each row in the first listbox corresponds to a different SQL
statement used to populate the 2nd listbox. How would you do this with
bound listboxes? With unbound listboxes all I need to do is put a case
statement in the ListBox1 click event and populate ListBox 2
accordingly.

 

[Cor Ligthert[MVP]]

I do that simply with relations.

Nothing to populate,

Alternatively you can use the value member of a databinded listbox, with
unbounded you needs casting.

But it is not something I want to proof, it is simply an answer on your
question.

It really does not concern me if you use it or not.

Cor

 

[Herfried K. Wagner [MVP]]

Cor --

Am 30.12.2009 12:46, schrieb Cor Ligthert[MVP]:

I've sometimes to do some maintenance on a VB6 solution and I've to
think than every time that I should take care how data is moved from
controls to the recordset and vice versa.

However, even VB6 supported data binding (members 'DataChanged',
'DataField', 'DataFormat', 'DataMember', 'DataSource').

 

[Cor Ligthert[MVP]]

Herfried,

Glad to know,

The owner of this VB6 application follows your rule, why to change when it
is all I need.

Cor