At this point - don't have luxury of time...need to get this script working to update 1000's of prices this weekend...
What is happening now - it will handle several records (2-6)..then gets stuck on the top of the Loop for next record - pausing for the correct screen - but the log shows still in the last screen... Maybe a DoEvents or Wait?? Once the prior record is done? Mike McGinnis Information Technology John Muir Health 1400 Treat Blvd Walnut Creek, CA 94597 Phone (925) 947-4466 x 32412 Cell (925) 286-5310 [email protected]<mailto:[email protected]> From: [email protected] [mailto:[email protected]] Sent: Friday, December 21, 2012 1:39 PM To: [email protected] Subject: RE:[talkbws] Scripting Star v17 Service Item Price Updates Thanks for all this - somewhat helpful.. At this point - not much choice to switch back to Rules - though I'd love to try it... At("") - not so much to the point about the same condition - question is more to when might it be good to use At("") - seems at end of 1 record - maybe use it to clean bws for next record to pass thru the logic cleanly?? Mike McGinnis Information Technology John Muir Health 1400 Treat Blvd Walnut Creek, CA 94597 Phone (925) 947-4466 x 32412 Cell (925) 286-5310 [email protected]<mailto:[email protected]> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Friday, December 21, 2012 10:29 AM To: [email protected]<mailto:[email protected]> Subject: RE:[talkbws] Scripting Star v17 Service Item Price Updates Oh and a script that jumps around, that is doing conditional checks.... That makes me want to guess that someone put in At "" (or Rule "" if using the Rule command) I hesitate to even explain what At"" / Rule"" does because I have heard misconceptions / misunderstandings about this for years :) But good knowledge is power - so here are the facts. Fact #1: BWS does not let you see the exact same condition twice with At or Rule - and that is always a very good thing, unless for a particular, individual, perfectly understood scripting situation it is not. Fact #2: You will see this behavior when debugging, and it will confound you 75% of the time you run into it regardless of your experience level, because you will execute the command twice in a row and be thinking "dang it, it was true the first time, now it is returning false" Fact #3: At"", Rule "" clears out what BWS last saw, allowing you to indeed see the same thing again. Regardless of what you might think, the vast majority of the time, that is typically not behavior that you want in a running script. An exercise: Explain why the below is dangerous code - it may work perfectly, most of the time - but someday, it will fail with a symptom like it seemed like the screen was "jumping" Do Rule"" If Rule() If Rule() If Rule() Stable Loop I will leave it up to the scripter to provide an explanation. If you don't know off hand, going through the thought exercise to come up with the correct answer will make you a better scripter. So I am not going to tell you the answer! However, I will happily respond to anyone's attempt - confirming your correctness or guiding you down the path to the answer. Thom C. Blackwell VP, Technical Services Boston Software Systems, Inc. Phone: 866.653.5105 x807 Mobile: 508.423.8463 Fax: 508.319.3015 www.bostonsoftwaresystems.com<http://www.bostonsoftwaresystems.com/> Healthcare Automation - Revolutionizing How You Work. The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Friday, December 21, 2012 1:02 PM To: Talk Subject: RE:[talkbws] Scripting Star v17 Service Item Price Updates Mike, Here's some advice - warning this will be a long post! I am assuming you have a reasonably new rev of BWS - so I'll use the more modern commands - PauseRule and Rule vs Pause and At. The difference, they allow checking more than one screen condition at once. For your screen conditions in STAR look for unique text on the screen to ID that page plus the prompt text - Do not use cursor locations! Then you don't have to worry about locations changing. Here is an example: PauseRule "STAR Main Menu@*,*&Enter Option Number" For menu navigation - I'd suggest using the Navigate command vs hard coding in numbers: PauseRule "STAR Main Menu@*,*&Enter Option Number" Navigate "Patient Accounting" In a properly written script Stable (use that since this is a character based screen) is used inside a loop simply to allow the PC to breath while the script is checking things. Avoid like the plague any thought of using Stable/Wait for "timing when to look for something" - that is a recipe for creating unreliable scripts. E.g. Enter "something" Stable 1 If at("Something") That code above is BAD BAD BAD BAD BAD BAD BAD - did I mention it was bad - so bad it made my fingers hurt just typing it :) I like to use the metaphor of a camera pointed at the monitor - that camera could either be video camera or it could be a snapshot camera PauseRule is like a video camera - it is constantly seeing the screen after the Record button is pressed, so when it sees the conditions then you move to the next command Rule is a snapshot camera - it only will see what was on the screen when the shutter was clicked, then it will checks for the conditions against that picture. That's is why Rule ALWAYS MUST BE IN A LOOP unless you have a confirmed beyond a shadow of a doubt that what you are looking for either absolutely will be there or absolutely will not be there when the picture was taken. I've been using For-Next instead of Do-Loop for these checks: Sub CheckforError For i=1 to timeout If Rule(Error condition 1) If Rule(Error condition 2) If Rule(Where I was expecting to go if no errors) Stable .2 Next i Err.raise seTimeout ' if you got here that means it didn't see any of your checks - you missed an error - or heck something weird happened. End sub Why .2 - the default interval is half a second - you really don't need to delay that long between checks. There is a law of diminishing returns however so cranking down Stable to .00001 will just hammer the PC - making performance worse. As you may hear a NASCAR driver say - "sometimes you have to go slow to go fast" Now for STAR, errors are typically ephemeral - you end up being back at the same place you started: Enter Account number: type in something bad Bad account displays on Row 25 for about 1.5 seconds Now you are back at the Enter Account number prompt So to trap for that, you either need a crisp loop like the above - another reason NOT to use an arbitrary delay!!!! - and Rule for the error message text. Or more commonly just check to see if you are back where you started from. Finally, I'd suggest avoiding getting too "fancy" with your code - If I am not using Rules (which btw works very well w/ STAR) . I adhere to the following script structure when I am doing any procedural script and it works very well - this is an example using names that may sort of match what you are doing: Scripts module Sub MainSIMUpdate If not Login then FatalError Do until d.eof MainSIMProcess d.Next_ loop End sub Some other module Sub MainSIMProcess On error goto errh If not SIMLookup () then err.raise seTimeout If not EnterSIM() then err.raise seTimeout D("Status")="Done" Exit sub Errh: Err.clear ScreenResetRoutine 'Basically Enter"." Etc till I get to anchor screen, set D("Status")="Error", perform any notification etc.... End sub Unit of scripting work routines are functions that simply bubble up the error to the main routine by returning false Function Login() as Boolean On error goto errh PauseRule "UserID" Enter "UserID ... Login=True Errh: Status="Login" Err.clear Exit function Hope all this helps! Thom C. Blackwell VP, Technical Services Boston Software Systems, Inc. Phone: 866.653.5105 x807 Mobile: 508.423.8463 Fax: 508.319.3015 www.bostonsoftwaresystems.com<http://www.bostonsoftwaresystems.com/> Healthcare Automation - Revolutionizing How You Work. The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Friday, December 21, 2012 12:18 PM To: Talk Subject: [talkbws] Scripting Star v17 Service Item Price Updates I've been working on STAR Service Item Price Updates I inherited a VB script that "years ago was written by Boston Workstation Consultants" - but that code never really worked (probably due to screen changes or additional questions that come along during the process). I've re-engineered the code - so there is now a response for each possible question/prompt that comes up on the various screens using combination of SUB's and Functions along with CASE statements. I can walk thru my logic in debug mode and works fine - but when RUNNING - the script bounces all over the place and doesn't keep to the logic... Can someone provide advice/confirm - how to leverage PAUSE, At (""), DoEvents, Wait's, Stable's... Seems the best practice is to use Pause for the Upcoming "Major" response questions (enter Dept #, Enter SI #, Enter Variable price)...and use IF for other optional questions that may come up related to that screen ...with some Wait's after any response And use At("") after a major screen has received it's response (like Dept, SI #, price adjustment) THANKS - Happy Holidays Mike McGinnis Information Technology John Muir Health 1400 Treat Blvd Walnut Creek, CA 94597 Phone (925) 947-4466 x 32412 Cell (925) 286-5310 [email protected]<mailto:[email protected]> --- To post a message to this list, send mail to: [email protected]<mailto:[email protected]> You are currently subscribed as: [email protected]<mailto:[email protected]> Unsubscribe in the customer center on our website: http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx --- To post a message to this list, send mail to: [email protected]<mailto:[email protected]> You are currently subscribed as: [email protected]<mailto:[email protected]> Unsubscribe in the customer center on our website: http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx --- To post a message to this list, send mail to: [email protected]<mailto:[email protected]> You are currently subscribed as: [email protected]<mailto:[email protected]> Unsubscribe in the customer center on our website: http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx --- To post a message to this list, send mail to: [email protected]<mailto:[email protected]> You are currently subscribed as: [email protected]<mailto:[email protected]> Unsubscribe in the customer center on our website: http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx --- To post a message to this list, send mail to: [email protected] You are currently subscribed as: [email protected] Unsubscribe in the customer center on our website: http://www.bostonworkstation.com/customer_center/virtual_user_group_talk.aspx
