Field's Display Contol

[stevenzk]

I use this method to create a new field in a table. This field had
yes/no datatype. The "fieldname" is the name of the new field i want t
add in the table.

AppendDeleteField tdfApp, "APPEND", fieldname, dbBoolean, 1

I want to know is there a code that i can add in to set the displa
control of this newly added field("fieldname") from a default text bo
to checkbox.

*AppendDeleteField is a function i create to Append/delete field.

I wish u guy can help me on this?

Thanks you

 

[Jeff Boyce]

I'm not clear on why you'd want to dynamically alter your table structure
.... usually, in a well-designed, well-normalized Access database, you'd not
need to do that.

Can you describe a bit more about your situation, and what you hope to
accomplish? (instead of "how" you want to...)

 

[TC]

I agree with Jeff. It's very rare that you would need to create a new
field in an existing table, through code.

Having said that, to answer your question: DisplayControl is a
user-defined, numeric property. So you should use CreateProperty to
create it, and allow for the error IF it already exists. Then you set
its value as follows:

dbengine(0)(0).tabledefs![MyTable].fields![TheField].displaycontrol =
acTextbox

Use the ac* constants to set the value. Eg. acTextbox if the required
display control is a textbox.

This is from memory (I don't have Access here to check), so you'll have
to check the details for yourself.

HTH,
TC

 

[Marshall Barton]

I use this method to create a new field in a table. This field had a
yes/no datatype. The "fieldname" is the name of the new field i want to
add in the table.

AppendDeleteField tdfApp, "APPEND", fieldname, dbBoolean, 1

I want to know is there a code that i can add in to set the display
control of this newly added field("fieldname") from a default text box
to checkbox.

*AppendDeleteField is a function i create to Append/delete field.

Not only is it very odd to be adding fields to you tables,
you should not be concerned with how a field is displayed in
sheet view. Since table sheet view is totally inappropriate
as a user interface, you are the only person that should see
the value so it doesn't matter how it looks.

 

[TC]

A table datashet view is appropriate for an adhoc query /output/ in
some cases imho. In those cases, you do want yes/no fields to show as a
checkbox, not as numeric values 0 and -1. Sometimes the only way to
achieve that is to set DisplayControl.

Cheers,
TC

 

[stevenzk]

Thanks for the advise, apperciate it. I think my design is wrong. I wil
be looking into it

 

[Marshall Barton]

A table datashet view is appropriate for an adhoc query /output/ in
some cases imho. In those cases, you do want yes/no fields to show as a
checkbox, not as numeric values 0 and -1. Sometimes the only way to
achieve that is to set DisplayControl.

And you need to add the property programatically?

Besides, you can set the Display Control property in the
adhoc query without messing with the table.

 

[TC]

And you need to add the property programatically?

Yes, you do in some cases.

For example, I've implemented an "ad-hoc program" capability in one of
my systems. A user can contact me with their requirements for a custom
update program, or (more generally), a custom report. I develop & test
the relevant SQL statement, then click a button which exports that
statement & related information (eg. a text description of what it
does) to an XML-like format of my own design. Then I email them that
file. Then they go to Tools : Custom Programs, browse to that file, and
click to import it into their "custom programs" list. Then they can run
that custom program, at any time, by selecting it from their list of
installed custom programs.

When a custom program is a report (ie. a SELECT statement) instead of
an update, the custom programs code sends the output to a simple
datasheet. But often, some of the fields in the SELECT statement are
boolean expressions of greater or lesser complexity. Typically, these
will /not/ display as a checkbox in the scenario described herein. They
will display as a numeric column, which of course does not make any
sense to the user. So the code will recognize these columns (in the
datasheet output), and set their DisplayControl property when required.
Then they show as textboxes, which is what is required.

I'm not saying that it is common to need DisplayControl. But ther are
some cases, like that one.

Cheers!
TC

 

[Marshall Barton]

Yes, you do in some cases.

For example, I've implemented an "ad-hoc program" capability in one of
my systems. A user can contact me with their requirements for a custom
update program, or (more generally), a custom report. I develop & test
the relevant SQL statement, then click a button which exports that
statement & related information (eg. a text description of what it
does) to an XML-like format of my own design. Then I email them that
file. Then they go to Tools : Custom Programs, browse to that file, and
click to import it into their "custom programs" list. Then they can run
that custom program, at any time, by selecting it from their list of
installed custom programs.

When a custom program is a report (ie. a SELECT statement) instead of
an update, the custom programs code sends the output to a simple
datasheet. But often, some of the fields in the SELECT statement are
boolean expressions of greater or lesser complexity. Typically, these
will /not/ display as a checkbox in the scenario described herein. They
will display as a numeric column, which of course does not make any
sense to the user. So the code will recognize these columns (in the
datasheet output), and set their DisplayControl property when required.
Then they show as textboxes, which is what is required.

I'm not saying that it is common to need DisplayControl. But ther are
some cases, like that one.

Wow, that sounds pretty elaborate. You might very well need
it in you case.

I have no idea how your "programs" work, but if your query
ends up as a QueryDef, you might want to consider setting
the query field's DisplayControl property instead of the
table field. Although I can easily imagine where that would
be the long way around, I thought it might be worth a
reminder.

 

[TC]

From memory, fwiw, I actually set the property directly on the
datasheet, using the fact that a datasheet exposes an object model
almost identical to that of a form. I don't set it on any tables. The
situation is where a boolean expression in a query, does not display as
a textbox - so there is no specific table that yo could set it on

Cheers,
TC