Okay, I have a multipart key (three elements), I paint a form with 3 databound elements for each part of the key: K1, K2 and K3.

On K1 (first prompt on form) I add a popup call on the OPTIONS event. The popup returns the full record key K1*K2*K3 and I set DEFPROP of .K1 to the return value from the popup.

The full key displays in the K1 editline and controls K2 & K3 are not populated after losing focus on K1.

What I wind up having to do is set the DEFPROP for all three of the key controls which is way too much coding for my lazy a**.

It seems to me that I was able to get away only setting the first part control (as in ARev Windows/Templates) with the full key. Maybe my designer Vodka soaked memory is failing me (no surprise there) or maybe I'm doing something different. Please correct me before I turn to further drink

.. putting down my Grey Goose glass let me just say this ..

This ain't Arev .. no .. really

i have not found any way to effect this except to populate the controls ..

.. sighing and picking up my glass ..

Grey Goose ran out last night so I had to start on the XO…

could always set the QBFLIST property instead ;)

The Sprezzatura Group

World leaders in all things RevSoft

XO .. that isn't a kiss for me is it??? you english guys

True .. you could set the list .. but if you are setting that property why not set the 'real' properties?? always looking for a short cut

hey .. i'm american .. if i can use a hammer (even if a screwdriver is suggested) i use a hammer

Create a hidden "@ID" type field and set its INVALUE to the returned value and send A read event

I had a previous problem with multiple key part before.Dont know if same like yours or not (though i am not drinking but sometimes my memory do fail me) and i ended up writing codes for it.The thing is both the popup and form dont seem to be develop with multiple key part in mind eventhough its a great and important feature in Arev and OI.The popup should know its multiple key parts and populate the neccessary bounded fields in the form and then the form should reconize these fields as multiple keypart since all the info can be obtain from the bounded dictionary.Hope this will be improved, until then we have to bang in the codes for ourself.

] could always set the QBFLIST property instead ;)

Ah-ha! That's what I was doing before. This calls for a drink :)

Warren,

You are looking for a simplistic solution to a more fundamental problem.

In your promoted create, set KEYS@ to contain the list of key controls.

Provide a generic routine to list available keys for a window in a popup, and return the identifier(s).

If multiple keys are returned, set the QBFLIST property (but what about issues with event code and QBF?).

If a single key is returned, set the key controls in KEYS@, set ID, and send a READ event.

If the popup returns nothing or is canceled, do nothing. (If your popup were returning a value to a key control, returning a null would wipe out a key part.)

My routine for choosing records shows only records in the current list, if a list is active, or all available records otherwise. Setting the QBFLIST when a single record is selected violates the user's expectations, as this would restrict the window to a single record. So, my record listing and query functions set ID but not QBFLIST when a single record is selected.

You might consider writing a generic routine that you pass the form and key to, and have the routine use the form's COMMON variable KeyMap@ to update the various controls. All key part controls are stored here, so you need to reference ControlSemantics@,1] (table) and ControlSemantics@,4] (key part) to verify the table and position for a given control. You can then just call it for any form.

Unfortunately, setting the global variable @ID doesn't seem to work any more.

View this thread on the Works forum...