It goes back to the yes/no prompt again. Same thing happens if they escape out.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Sent: Tuesday, February 26, 2008 11:18 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: How can make this code better ? That's Good Dennis What happens if they pick I am confused! ? Marc ----- Original Message ----- From: Dennis McGrath<mailto:[EMAIL PROTECTED]> To: RBASE-L Mailing List<mailto:[email protected]> Sent: Tuesday, February 26, 2008 11:04 AM Subject: [RBASE-L] - RE: How can make this code better ? When I want the operator to not be able to blow past a prompt, I pop up a menu instead (I use choose..#list, but any method you choose will work) that has 2 or more choices. The first is one just loops around until they pick one of the other 2. If they exit the menu without choosing it pops up again. The last option is the option to go ahead. Any other options you can add yourself. The beauty of this is that it forces the user to stop and make an intelligent choice. Nothing is foolproof but this is far better that anything else I have come up with. An example of this is an order entry system. At the end of an order we ask whther the user wants to save the order with YES as the default. If they select NO, then a menu with a title "You chose to delete this order" and the selections: I am confused! Please keep the order Really delete the order This avoids a lot of rentry when the user says NO in error. There is absolutely no confusion about the meaning of each of the options! The most destructive option is always at the end. I hope this gives you some ideas. Dennis McGRath ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Sent: Tuesday, February 26, 2008 10:43 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: How can make this code better ? That's a good thought Bill. They just called and said they had a computer hiccup this morning, they didn't say what but they are thinking their hardware is flaking out. I feel like a dog trying to catch my tail. Marc ----- Original Message ----- From: Bill Eyring<mailto:[EMAIL PROTECTED]> To: RBASE-L Mailing List<mailto:[email protected]> Sent: Tuesday, February 26, 2008 9:57 AM Subject: [RBASE-L] - RE: How can make this code better ? Marc, I agree with you that it's probably not the code but probably a data operator error. Of course all code can always be improved. I have had instances where the data operator has blown right by the pause 1 or pause 2 message without having looked at or acknowledged the error message. To counteract that from happening, I would create a small form based on a dummy table that contained the error message ('Some data was not copied to the History file '). The data operator would have to press the [Esc] key not 'any key' to continue. Create the form and under Form Properties, go to the Dynamic Caption tab and check all 4 boxes under Caption Buttons. This will force the data operator to press the [Esc] key to acknowledge the message. Hope that helps. Bill Eyring ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Sent: Tuesday, February 26, 2008 9:38 AM To: RBASE-L Mailing List Subject: [RBASE-L] - How can make this code better ? Hi Out of 100 offices this has happened only about 6 times in a year. I think it is from computer hiccups but I am wanting to make my code as tight as possible. Basically we put charges and payments in a Tran_daily file. At the end of the day if everything is correct we Close the day, do some updates, move the charges and payments to the Tran_Hist table and summaries the totals in a Recap table with the date on it, then delete the Tran_daily rows. About 90% of the rows from the Tran_daily table got copied (inserted) into the Tran_Hist table twice for 2/8/08. This office has used my app for 10 years and this is the first time it has happened to them. I told them if the same code works 99% of the time and one day screws up it is not the code/RBase it is a computer quirk. Below is a summary of the code, is there a better way to do this or trap for errors? Sorry this is so long Marc DELETE DUPLICATES FROM tran_daily --so this should have stopped the dups in the Hist SET VAR vdaycnt INTEGER = NULL SELECT COUNT (*) INTO vdaycnt FROM tran_daily SET VAR vhistcnt INTEGER = NULL SELECT COUNT (*) INTO vhistcnt FROM tran_hist -- copy tran_daily TO tran_hist INSERT + INTO tran_hist (custnum,date ......... + ................,modf4 FROM tran_daily SET VAR vhistcnte INTEGER = NULL SELECT COUNT (*) INTO vhistcnte FROM tran_hist IF vhistcnte <> (.vdaycnt + .vhistcnt) THEN PAUSE 1 USING 'Some data was not copied to the History file ' ENDIF if this poped up they didn't remember it *(insert RECAP FILE WITH TOTALS FOR DAY) INSERT INTO recap (............ , tptpay,+ VALUES (.vdate, ................ '1',.vtvisa) DELETE ROWS FROM tran_daily SET VAR vrecapchar CURRENCY = 0.00 SET VAR vrecappay CURRENCY = 0.00 SET VAR vrecapchar CURRENCY = tcharges IN recap WHERE COUNT = LAST SET VAR vrecappay CURRENCY = tpayment IN recap WHERE COUNT = LAST IF tcharge = .vrecapchar AND totpay = .vrecappay THEN PAUSE 1 USING 'Finished Recap Created' ICON confirm .... ELSE PAUSE 1 USING + 'Recap DID NOT match Check the Recap and use a Backup if necessary' + ICON SERIOUS BUTTON 'OK' OPTION BACK_COLOR 65535 | ...+ if this poped up they didn't remember it ENDIF RECALC VARIABLES RETURN
