I'm trying to do the following and getting a problem when I try to clear the sub property field because the object is no longer there but the dataset thinks it has to update the sub property. Any ideas?
I'm trying to set or clear the master account (Account.AssAccount) and display to the user what the master account is using aefAccountsAssAccountName . I want to keep the dataset in edit mode till the user posts.
not sure if there is a way to "fix" this. There are several workarounds, though. You could create the subproperty field as calculated field, and/or set the OnGetText event for it and make it blank in case the Account field is also blank. The key here is not change the field value, if you change it, then Aurelius Dataset will try to update the property, unfortunately.
Yes I know there are ways of working round this but shouldn't there be a way of getting TFields bound to the sub properties of an object to update\refresh when we change the associated property. When I change aefAccountsAssAccount.AsObject := Account; Why do I have to even think about a TField attached to Account.AssAccount.Name? Perhaps I'm being pedantic but it does seem the way it should work.
the problem is you are working with objects behind the scenes. And thus you can have several fields pointing to related properties - which is the case here, you have a field pointing to the object reference, and another field pointing to a property of that same object.
You could have, for example, two fields pointing to two different properties that update each other and you would have the same effect - one field would override the other field value.
Another example is the order which fields are updated. Depending on how your fields are ordered, you must have the Account.Name being updated before Account (and that would update the previous Account object). I'm not sure what kind of feature/behavior you would expect? I'm open to suggestions.
Suppose I have a class TCommodity that has an association with TAccount. When it's instantiated I can change the account associated with a commodity by simply doing Commodity.Account := NewAccount; If I only deal with objects Commodity.Account.Name will give me the name of the correct Account. Brilliant - lovely clean and simple.
However I'm binding TCommodity with an AureliusDataset and creating 2 AureliusEntyFields for Commodity.Account (one for Commodity.Account and another for Commodity.Account.Name) so that I can display the name of the account.
Right clicking on the Account's name gives the user a pick list accounts, when he selects one I change the AureliusEntyFields to be the one he wants. This changes Commodity.Account correctly but now the AureliusEntyFieldsbound to Commodity.Account.Name is out of sync and shows the old value. If I refresh the AureliusDataset it will update to show the correct value but to refresh I have to post and I want the user to post or cancel at the end of his editing.
As we've discussed this can be worked around by not using a AureliusEntrityField for the sub property but to me it would be so much nicer if I could use an AureliusEntrityField for the sub property Commodity.Account.Name. I suppose I want it to work like a lookup field without having to go to all the hassle of creating an other dataset.
In my first post it was probably a little misleading because it might have looked like I wanted to change the sub property's name whereas what I was actually trying to do was just get it to show the right one.
I understand your needs. And actually what you do want is, strictly, a kind of lookup/calculated field - you don't want to edit Account.Name. You just want it to display the name of Account object - it's conceptually different. So if you see it that way, it's not even a workaround - it's the way it should be (especially because we are talking about datasets here - lookups and calculated fields are built for that). And you also have OnGetText event to give you more flexibility, you must admit that what you need is just a visual tweak (not showing the name of account if Account field is nil).
But still, I understand creating a field "Account.Name" is more straightforward than creating a calculated field. But then, what is your suggestion? Take into account that the current behavior (change account.name) must not be changed for the sake of backward compatibility and also because that's the original purpose, which is change account.name. What can be done in this case, what do you expect?
Ah the penny's just dropped. I don't need two AureliusEntityFields at all! I just need to get the name in the GetText of the first one. Talk about over thinking it. Sorry about that. It's so obvious now that you point it out, I don't know why it didn't occur to me.
I'm glad it works well that way for you. Nevertheless, your initial request was valid - I just didn't know how to provide a good solution for the two-field usage. If you need anything else, just let me know!