So I'm a bit stymied. I've been trying for a few hours now to set a new record's
key field to an externally generated value. I've got a table in a form that
has AutoAppend on. I figure I can use the record object's CanDepart method
and set the key in there, then doDefault. So I attach a TCursor to self
to set the key field for the record (can't do it through the UIObject, b/c
the key field is not available from the form)-- but the TCursor attaches
to the last record, instead of the new record I'm editing. I've also tried
this in action by catching DataPostRecord and DataUnlockRecord, catching
DataInsertRecord instead and setting the key field then, and doing most of
these in the form prefilter. None seem to work. Everything seems to get
the TCursor attached to the prior record, as if the new record hadn't been
created yet. It hasn't been posted, obviously -- but I can't post it without
the key field. How exactly am I supposed to assign a key value to a new
record? I've considered making the key non-required, then forcing a post
on depart and setting the key there, but that seems sloppy.

I open the tcursor, create a record and set the new key, then open the form on
that new record.


--

Tony McGuire
"It's not about having enough time. It's about priorities."
___________________________

"Tony McGuire" <png.paradoxcommunity@com> wrote:
Gotcha. This is within a table, though, so I imagine that wouldn't work.
Form's opened on the parent record, table UIO is tied to the child table
records.

George,
have you tried to use dmPut(...) to set the not available key-value?

Egbert, 23:30 in Spain

"George Nassar" <george.DELETEMEnassar (AT) gmail (DOT) com> schrieb im Newsbeitrag
news:43b99cb3$1 (AT) pnews (DOT) thedbcommunity.com...

"Egbert Babst" <EgbertBabst (AT) BabstSoft (DOT) com> wrote:
No, I sure haven't. I'm not sure exactly how that would work; could you
explain a little more for me?

George,
if you have a form with your table in the datamodel (if you have an uiobject
bound to the table you'll find this table in the datamodel) you can access
all fields of the table even if they are not show in any uiobject.
From Help (P9)
Syntax
dmPut ( const tableName String, const fieldName String, const datum
AnyType ) Logical
Description
dmPut provides access to table data in the data model. dmPut writes datum to
a field in a specified table. The value of tableName can be a table name or
a table alias. The table specified by tableName must be one of the tables in
the data model. fieldName must be a field in tableName. This method returns
True if successful; otherwise, it returns False.
<<<
In addition:
The uiobject bound to the table must be in edit-mode if you want to write a
value to any field of the table.
I haven't tested a similar situation you have described, but you can easily
test, whether it works.
By the way: to pick up values from the table you can use dmGet(....). Have a
look at the OPAL-Reference.

HTH
Egbert, 02:36 in Spain

"George Nassar" <george.DELETEMEnassar (AT) gmail (DOT) com> schrieb im Newsbeitrag
news:43b9c702$1 (AT) pnews (DOT) thedbcommunity.com...

"Egbert Babst" <EgbertBabst (AT) BabstSoft (DOT) com> wrote:
Thank you. I had already looked at the OPal reference, but as usual, it
didn't give enough detail. I wasn't sure how it determined the record to
act upon, and I wasn't sure how dmGet would act with a blank field. Turns
out it behaves OK, but returns True and a null value. Guess False must be
for when the field does not exist...

Did a little experimenting to figure some of that out, and sure enough, it
seems to work. Acts on the new record instead of the last posted. Do you
have any idea why it would work with this, but not by attaching a TCursor
to the UIObject? It's confusing to me, because both attaching the TCursor
and using the dmPut method are supposed to reference the current record from
the UIObject, but the two methods are coming up with two different records.

A TCursor is independent of the UI. When you tell a tcursor to attach
to a UIObject, it's basically saying "open a tcursor and qLocate the
record this UI is pointing to." Since your new record isn't posted
yet, it doesn't exist in the table itself, so the tcursor can't find
it, so it gets as close as it can - the last record. The dm..()
methods, on the other hand, work on the table in the data model and
are directly linked to what the UI is doing - it knows you've got a
new, unsaved record in the UI and acts on that.

The other thing you can do is put the key field on the form (in the
same record object as the rest of the fields from the table), make it
invisible and operate on it like any other field.

Liz


George Nassar wrote:

Liz McGuire <liz (AT) paradoxcommunity (DOT) com> wrote:

You know, it's funny -- the other thing I tried was placing the key field
in the record and setting it to invisible, and it still didn't work. Of
course, I was still attaching a TCursor to access the key field. :-) D'oh!
I think since I just had the TCursor code in already, I probably just modified
what I had, instead of changing the recordobject.keyfield like I should have.

Thank you mountains for your excellent explanation as to the cause of the
problem -- it's exactly what I was looking for. I find that knowing the
cause of the problem is far more useful than just being able to work around
it -- and far more difficult to figure out, too :-)

"George Nassar" <george.DELETEMEnassar (AT) gmail (DOT) com> wrote

That's one of the many reasons for which we admire Liz so much.

Jean