Different unbound controls in continuous form view

[NaftoliGug]

Is there a way to have unbound, uncalculated controls (or a calculated control that is based on a function) that retains a different value for each record?

[missinglinq]

No! How could you? How could you expect Access to know what value you've placed in it if it's not stored (bound) to that particular record? All unbound controls hold the latest data that's been entered in any of the instances of the control. In a Continuous View form, you can see this. If it's an unbound control and holds a calculated value and the form is in Single View form, you can cheat and make it appear to hold a different value for each record, by re-calculating it as you move from record to record. But in actuality when the control on RecordA holds 10, all instances of this control hold 10, you just can't see the other instances of the control.

Welcome to Bytes!

Linq ;0)>

[NaftoliGug]

What a quick response!
I don't understand the question, "how could it be otherwise." It would make sense to remember state across different records. Events are always generated from a specific record, so any code modifying a control's state obviously means to modify that state for that record. And if the user directly modifies the control he certainly means to modify the one he interacted with! Checking a checkbox next to a field should be allowed to trigger code that will perform some operation on that record! No one expects to see all the check boxes nearby to suddenly pop on or off!
Anyway, enough philosophising. Maybe you can help me with my specific problem.
An order is priced based on a number of components, aspects of the order. The price by default is calculated from the inventory tables, but the user should be allowed to override it and enter a custom price for the current order. Since the official price must be stored in either case so that it's possible to revert to the official price at the time of selection, the custom price must exist in separate field, set to null to indicate that it's the regular price that's being used. I'd rather not have an extra field just to store whether or not the price has been customized. That should be determined from whether the custom field is null.
Some of the price components are rows selected from a table, so part of the "invoice" column is a subform, displayed in continuous form view obviously, so you can see all the components of the price at once.
The problem is that the user interface should not require two columns of fields. When the price is customized you should not see the real price, and when it's not you certainly don't need to see the empty text box.
The ideal way would be to have a check box which toggles the control source of a single text box. Apparently that's impossible.

[NaftoliGug]

Now I tried having text boxes for each and toggling them visible/invisible (real price is visible, double-click sets it invisible and custom visible, afterupdate with null sets custom invisible and real price visible). Guess what? Again, settings apply for every record! Ideas, anyone??

[missinglinq]

"I don't understand the question, "how could it be otherwise." It would make sense to remember state across different records."

Of course it does! And you do this by using a bound control!

Any control that you want to be specific to a given record has to be bound to a field in your underlying table! An unbound field is just that, unbound to any record! If you want to tick a checkbox on RecordA, and have it always stay ticked on RecordA, RecordA has to have a field, in the underlying table, that the checkbox is bound to! Data cannot be stored for a record otherwise.

Linq ;0)>

[NeoPa]

...
I don't understand the question, "how could it be otherwise." It would make sense to remember state across different records. Events are always generated from a specific record, so any code modifying a control's state obviously means to modify that state for that record. And if the user directly modifies the control he certainly means to modify the one he interacted with! Checking a checkbox next to a field should be allowed to trigger code that will perform some operation on that record! No one expects to see all the check boxes nearby to suddenly pop on or off!
...

The question explicitly stated UNBOUND controls.

Access (and database generally) work depends on attention to detail and logical thinking.

Logically, it could not make sense otherwise for unbound controls. If this isn't clear to you then you will struggle with databases.

[NaftoliGug]

I didn't say I wanted to persist the state! I think I understand databases quite well, thank you. There's no reason that Access can't remember transient state that would help to provide some functionality. Anyone who has programmed databases with a real programming language can understand that! Forms are more than table views with a different shape!
In other words, often it's necessary to remember something about a record temporarily, in order to affect the record in a more complex way than a directly editing a bound control would allow for.
Perhaps a simpler example of this concept would be a button that needs to have a different caption for different records, or controls that have to be hidden for particular records. A table might hold records of the same general category but that differ in various ways, and the form needs to provide a modified interface for some records.
Anyway, enough philosophizing. I need some practical ideas to accomplish my goal. It is extremely inelegant to have to store three columns (fields) when the same thing could be accomplished with two.

[missinglinq]

Since you obviously have all the answers, good luck to you!

[MMcCarthy]

I didn't say I wanted to persist the state! I think I understand databases quite well, thank you.

This is not a database issue. These controls are unbound which means the data is not being stored in the database. Your question is about how Access handles unbound (unstored) values not about databases.

There's no reason that Access can't remember transient state that would help to provide some functionality. Anyone who has programmed databases with a real programming language can understand that! Forms are more than table views with a different shape!

Your understanding of transient state seems faulty. The data in unbound controls are not stored anywhere therefore the forms in question are not representing a table view. An unbound control on a form while it is displayed in each instance of the form in continuous form view only exists once. Therefore, any data entered in an unbound control is shown wherever that control is visible. That is, in each instance of the continuous form.

In other words, often it's necessary to remember something about a record temporarily, in order to affect the record in a more complex way than a directly editing a bound control would allow for.

My understanding of the point you are making here is that you are speaking of what are known as calculated values. These are not stored as a matter good practice in RDBMS for the aforementioned reason.

Perhaps a simpler example of this concept would be a button that needs to have a different caption for different records, or controls that have to be hidden for particular records.

The second point you are making is addressed using conditional formating. The first point regarding label captions cannot be done in the way you are addressing it on continuous forms.

A table might hold records of the same general category but that differ in various ways, and the form needs to provide a modified interface for some records.

This sounds like you have a problem with the structure of your data. A table that holds records of the same general category but differ in various ways require at the very least a look up table.

Anyway, enough philosophizing. I need some practical ideas to accomplish my goal. It is extremely inelegant to have to store three columns (fields) when the same thing could be accomplished with two.

I reiterate that I believe your issue is with the structuring of your data. If you explain the data you are trying to store and what its relationship is with the other data in your table we may be able to help. However, from what I have read you are trying to use unbound controls in a manner for which they were not intended.

[NeoPa]

Or to put it more simply, there seems little evidence of of the understanding you claimed in response to the help you were offered.

From what you've posted, it's clear to me why you're struggling with your current task. There are a number of fundamental ideas that one needs to grasp in order to work effectively within an RDBMS.

Please understand I don't say this to be insulting, but as you've made a claim to understanding these issues I wanted to make sure that anyone reading this thread knows not to take what you say as established fact. We have a number of members who are just starting to learn about these issues. They can make their own minds up of course, but I felt it necessary to make that clear for them.

I think they will be able to make their own minds up as to the wisdom of the attitude you've taken towards people offering their time for free in order to help those who are asking for help. That includes you in case you've forgotten.