I have been having a problem for quite a while now and I've had no luck in getting it resolved. I'm afraid you are the last resort.

As I said, I've had this problem for a while. I just upgraded to OIS4W 3.6. I ran fixvol and SCAN_REP successfully. My problem still exists.

I've created a form and added 4 DBEditLine's. The first DBEditline is KEY. The second and third are FIRST_NAME and LAST_NAME. They are both set up with XREF columns. The fourth DBEditline is ACCT_GUAR. When the form is opened, the CREATE event in the window starts an IndexLookup. If I press Escape, I clear the IndexLookup window and a Read/Write Error Window opens. It says All key values are empty. I click on the OK button and the window clears. I then press the F8 key and the next SeqKey is entered in the Key DBEditline. The script for the CREATE event is:

Declare Subroutine Send_Event,Set_Property

Declare Function IndexLookup

Key=IndexLookup(CtrlEntID1,'F.','ACCT_GUAR_TEST','FIRST_NAME_XREF':@VM:'LAST_NAME_XREF','FIRST_NAME':@VM:'LAST_NAME','SINGLE',) v=Set_Property(CtrlEntID:'.KEY','TEXT',Key) Send_Event(CtrlEntID1,'.','READ') RETURN 0 I then enter the first name and the last name of the Person1. I tab into Acct Guar and the Account Guarantor window opens. The message is Who is the guarantor for this patient? There are three buttons: Self, Other and Cancel. For Person1 I click on Self. I save Person1 and enter Patient2. When I get to Acct Guar, I click on Other. The IndexLookup window pops up and I enter the first name and last name of Person1. This is where the problem starts. The Selection List pops up and is immediately followed by the Account Guarantor window. The Account Guarantor window should not pop up again and I can't figure out the problem. The following is the script from the Acct Guar GotFocus script: Declare Subroutine Get_Property,Set_Property,Send_Event Declare Function Repository,Send_Event,IndexLookup AG=Get_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT") If AG=" Then RB=Repository("EXECUTE","DENT*MSGACCT_GUAR",@WINDOW,"") Begin Case Case RB=1" ; * Self Selected Set_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT",@ID) AG=@ID Case RB=2" ; * Other Selected Retval=IndexLookup(CtrlEntID1,'F.','ACCT_GUAR_TEST','FIRST_NAME_XREF':@VM:'LAST_NAME_XREF','FIRST_NAME':@VM:'LAST_NAME','SINGLE',) Set_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT",Retval) AG=Retval Case RB=3" ; * Cancel Button Send_Event(CtrlEntID,"GotFocus") End Case End RETURN 0 So the bottom line is how do I stop the second Account Guarantor window from popping up? I am desperate! Thank you, Richard Richter </QUOTE> —- === At 20 APR 1998 04:13AM Andrew P McAuley wrote: === <QUOTE>OK, let's break this into bite sized chunks… Why do you get the all key values empty? Well you've sent a read event with blank key fields, so modify your code as follows Declare Subroutine Send_Event,Set_Property Declare Function IndexLookup Key=IndexLookup(CtrlEntID1,'F.','ACCT_GUAR_TEST','FIRST_NAME_XREF':@VM:'LAST_NAME_XREF','FIRST_NAME':@VM:'LAST_NAME','SINGLE',) If Len(Key) Then v=Set_Property(CtrlEntID:'.KEY','TEXT',Key) Send_Event(CtrlEntID1,'.','READ') End RETURN 0 [/i] Now for the second bit… to be honest I've looked at what you've typed for 15 minutes and whilst I see what you are trying to do, I'd be tempted to do it differently. Using Msg is always a bit dodgy in sensitive areas like gotfocus and lostfocus. I'd be tempted to use popup instead. We strongly advise against UI type logic on a GotFocus. It is intrusive and can be annoying. In fact for some purely gratuitous advice, I'd be tempted to do it differently in toto. What you want to achieve is a way of filling in either @Id or another Id into this edit line depending on user choice. The way we'd do this is probably as follows Have a radio button with "Self/Other". On the click event of the radio button either fill and protect the Guarantor editline (self) or enable and send option event to the Guarantor editline (other). This is more work but will lead to a much nicer product. FWIW [email protected] Sprezzatura Ltd World Leaders in all things RevSoft </QUOTE> —- === At 20 APR 1998 06:34AM Oystein Reigem wrote: === <QUOTE>Sorry for intruding. Andrew - you say that Using Msg is always a bit dodgy in sensitive areas like gotfocus and lostfocus. … I had one problem recently that perhaps had to do with this. I just had to put it aside but still very much need a solution. I need Msg to ask for some confirmation from the user. Is there some alternative to Msg so I don't have to change all the logic? (I need BO or BOC or BNY or BTic,Tac,Toe or similar.) The Msg is in a tangle of READ, GOTFOCUS, LOSTFOCUS and other events that I'd prefer to leave alone until next major revision of the app. - Oystein - </QUOTE> —- === At 20 APR 1998 09:33AM Don Bakke wrote: === <QUOTE>Richard, I wholeheartedly concur with Andrew. No disrespect intended, but it does (based on observation) seem like the flow of UI is not very clean. Therefore my recommendation would be to use another approach. However…[/i] Where there's a will, there's a way (or "Where there's a whip, there's a way" from the animated Return of the King ). I believe the few modifications to your code below might solve your problem, but I'm also assuming I was able to understand the problem. So, try this and tell me if I got anywhere close to helping you (changes are in bold): <code> <code> Declare Subroutine Get_Property,Set_Property,Send_Event Declare Function Repository,Send_Event,IndexLookup AG=Get_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT") Skip=Get_Property(@Window, "@SKIP_EVENT") If Skip else If AG=" Then rv=Set_Property(@Window, "@SKIP_EVENT", 1) RB=Repository("EXECUTE","DENT*MSG**ACCT_GUAR",@WINDOW,"") Begin Case Case RB=1" ; * Self Selected Set_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT",@ID) AG=@ID Case RB=2" ; * Other Selected Retval=IndexLookup(CtrlEntID1,'F.','ACCT_GUAR_TEST','FIRST_NAME_XREF':@VM:'LAST_NAME_XREF','FIRST_NAME':@VM:'LAST_NAME','SINGLE','') Set_Property(CtrlEntID1,'F.':".ACCT_GUAR","TEXT",Retval) AG=Retval Case RB=3" ; * Cancel Button Send_Event(CtrlEntID,"GotFocus") End Case rv=Set_Property(@Window, "@SKIP_EVENT", 0) End End RETURN 0 </code> </code> [email protected] SRP Computer Solutions </QUOTE> —- === At 21 APR 1998 08:25AM Oystein Reigem wrote: === <QUOTE>See parent posting. - Oystein - </QUOTE> —- === At 21 APR 1998 09:15AM John Duquette wrote: === <QUOTE>Oystein, You can use Dialog_Box since it will suspend the calling program until it returns a value. John Revelation </QUOTE> —- === At 21 APR 1998 11:42AM Richard Richter wrote: === <QUOTE>Andrew and Don, you hit it on the head! Thanks. Where can I find out about the @SKIP_EVENT property? I never heard of that one and I have a feeling there are others I haven't heard of. Where do they hide this information? Thanks again, Richard Richter </QUOTE> —- === At 21 APR 1998 12:59PM Andrew P McAuley wrote: === <QUOTE>Any property with an @ at the beginning is a user defined property - so Don just used a meaningful name to describe a flag he wanted to check. [email protected] Sprezzatura Ltd World Leaders in all things RevSoft </QUOTE> —- === At 22 APR 1998 05:01AM Oystein Reigem wrote: === <QUOTE>John, I didn't read Richard's and Andrew's mails properly. I thought it was the Msg function that was problematic. But of course Andrew talks about messages (and other stuff) made with the UI interface. But can you elaborate on why Dialog_Box is better than a UI MSG? And would the Msg function perform just as well as a Dialog_Box? - Oystein - </QUOTE> —- === At 22 APR 1998 07:24AM Cameron Revelation wrote: === <QUOTE>Oystein, But can you elaborate on why Dialog_Box is better than a UI MSG? And would the Msg function perform just as well as a Dialog_Box? Msg uses Dialog_Box with a form called MSG. If you have the Works, you have the source for Msg. Cameron Purdy [email protected] </QUOTE> —- === At 22 APR 1998 08:41AM Don Bakke wrote: === <QUOTE>Oystein, But can you elaborate on why Dialog_Box is better than a UI MSG? And would the Msg function perform just as well as a Dialog_Box? As Cameron mentioned, there is no difference between MSG and Dialog_Box since the former employs the latter. Hence, a MSG is a dialog box. I didn't read Richard's and Andrew's mails properly. The real problem is the method Richard used to trigger his MSG and subsequent code. Since this all happens during the GOTFOCUS event of his editline, once the MSG appears and disappears, this same editline gets focus again and therefore re-executes his GOTFOCUS event - therefore putting him in a semi-infinite loop (semi-infinite because not all of the conditions in his event would display the MSG.) So the best solution would have been to design it differently but the kludge I provided was a flag that could be set and checked to make sure the bulk of the event code would be skipped until everything completed normally. I don't know if this helps you in your particular situation. [email protected] SRP Computer Solutions </QUOTE> —- === At 22 APR 1998 01:31PM Oystein Reigem wrote: === <QUOTE>Cameron, Don, Thanks for the explanations. My problem must be something different. - Oystein - </QUOTE> View this thread on the forum...