I'm trying, I'm trying!

I have a Customer_ShipTos database which keys are based on the related customer records, i.e., customer XYZ might have shiptos XYZ-S1, XYZ-S2, etc.

In the ShipTos form, I have changed the order of prompts so that Cust_ID is entered before the key so that the key field's default process will calculate the next "-S" number. I can figure out how to write the code properly (I think!) but I'm not clear on how I pass the value back to the window. In the prompt properties dialog box under Default, I have tried BUILD_TO_IDS('@ANS'), BUILD_TO_IDS( 'BRANCH' ), BUILD_TO_IDS and a few other things but when I test the window, nothing happens in the key field to suggest that anything has been passed from the Function. I'm sure I'm probably not holdling my mouth right, but the Default hook in ARev was something I always had trouble with, too.

Could some kind soul please tell me what the proper way to pass info back and forth from a field prompt (sorry for the use of ARev lingo) to a Default process and back to the field with a value to display?

TIA,

Mike

Hi Mike

What happens if you get rid of the default on the key, and hang some code off the lostfocus of the customer id

Ie when the person enters the customer id and presses tab to go to the key, the lostfocus event could execute something that does

cust_Id=GET_PROPERTY(my_win : ".CUSTID", "TEXT")

* work out what the new key is.

new_key=GET_NEW_KEY(cust_id)

* stick your new default key into the key field

void=SET_PROPERTY(my_win : ".KEY", "TEXT")

don't put anything in the default stuff.

code breaker: (it's meant to be obvious but just in case)

my_win is the value of @WINDOW ie the name of the form with the customer id on it.

CUSTID is the name of the field where the customer id goes

KEY is the name of the field where the key goes

GET_NEW_KEY is a function you will have to write that, given a customer id works out what the next available S-key is. You can put the code in directly instead if you want to.

We have some code like this. We have some additional stuff (flags) so we can tell if we need to create a new key or if you want to enter an existing one. Ie we type "NEW" into the key field as default and then if NEW is overwritten with a proper key we retrieve that data, or if we leave NEW as the key value we then use the lost focus on the KEY field to generate a default key, stick it in the key field…

Does this help?

Scott

Mike,

If I got you right what you try to do is very simple. Just let your BUILD_TO_IDS procedure be a function that returns the calculated "-S" number value:

function BUILD_TO_IDS( Dummy ) …code that calculates the value and puts it in variable Value… return Value

Then put BUILD_TO_IDS()[/i] in the Edit Line Properties Default line. (Checking one of my apps I see in a similar situation I have a non-null parameter 'XXXX' instead of just ''. I don't remember why.) I think I would try to get the Default mechanism to work before resorting to GOTFOCUS and LOSTFOCUS. I haven't read Scott's reply properly, but I think she suggested the latter. If the Default mechanism works it's much cleaner, because - you don't have to code for the case where the user arrives at the field more than once. - if you have other handlers for the same field it's much easier to get everything to work if you got the Default handling in its "proper" place. (If you haven't got other handlers now you might want them later. I remember I had a very sticky case once, with a key field where I tried to do what you do while also lots of other things went on. I didn't get it right before I put the default handling where it belonged.) - Oystein - Øystein Reigem, Humanities Information Technologies, Allégt 27, N-5007 Bergen, Norway. Tel: +47 55 58 32 42. Fax: +47 55 58 94 70. oystein.reigem@hit.uib.no Home tel/fax: +47 56 14 06 11. </QUOTE> —- === At 11 APR 2001 01:40PM Mike Parrish wrote: === <QUOTE>Scott, Thanks. I'll give this a try. At the moment, I've taken off all of the processing on this because I just couldn't waste time yesterday. Also noticed that when I had Cust_ID as the first prompt (and a symbolic field that XLATEs the customer name), when the cursor moves to the Key prompt, all hell breaks loose. Apparently the key prompt must still be the first prompt in the Form? Is this correct?? And I though OI handled prompt processing differently. More experimentation. Unfortunately, I'm the only one working on this project and I desperately need to start deploying it soon but I'm reluctant to do so until I can get the forms to work the way I want them to. Perhaps I'm still too accustomed to my old pal, ARev. Mike </QUOTE> —- === At 11 APR 2001 01:53PM Mike Parrish wrote: === <QUOTE>Oystein, Awesome suggestion and one that I think I like a little bit better than Scott's only because I'm supposing OI default works similarly to the ARev default hook. Had a look at some of my old ARev code and recalled that I used commuter modules (thanks to the GODS at Sprezzatura!) and the default hooks had the lovely @S, window.name,DFLT@ action going. So much for codes & commands! Any advice on having datafields before the key field? Thought the results I was getting were rather too ARev like. I was hoping for a little better action in that regard (pls see my response to Scott). I think I'm SLOWLY starting to get the hang of it! I think I'm doing pretty well for a rusty developer with no printed manuals! Mike </QUOTE> —- === At 11 APR 2001 05:26PM Oystein Reigem wrote: === <QUOTE>Mike, I do think the key must come first. Else I believe the key is assumed to be null - until you arrive at the key field and fill in something else. The system believes you changed the key and you get the SAVEWARN message - "Would you like to save changes to the entry?". I guess sometimes when one needs other fields before the key those fields really should be part of the key. If you really need other fields before the key perhaps you can suppress the SAVEWARN message with some clever handlers. You must also suppress the user's ability to save too early - before the real key is set. - Oystein - </QUOTE> View this thread on the forum...