Epic, display resolution, and Eggplant Functional

Hi Everyone,

I’m in the process of deciding upon a “standard” RDP display resolution, to ensure my team captures images, setting coordinates, etc. at the same resolution. I’m leaning towards a “standard” resolution of 1920 x 1080 (this is, in general, the standard resolution at my organization).

Epic’s official recommendation is 1600 x 900. I don’t intend to opt for this resolution since some of our scripters’ devices can’t accommodate it (they’d have to scroll around their RDP window to view the entire SUT display). I do wonder if going with this resolution might “future proof” our images, etc. for longer, however. I’d imagine lower resolutions–for example, 1280 x 720, could improve OCR check performance, but I haven’t verified this yet. I do know that lower resolutions cause display issues within Epic itself (for example, buttons dropping from the Patient Group activity).

I feel confident that 1920 x 1080 is a solid option for my organization, but I’m curious if other organizations have any “lessons learned” or strongly advise for (or against) a particular resolution.

Thanks in advance for any feedback. Hopefully this thread proves useful to others in the future.

Best regards,
Dan

Hi Dan, I am new to Eggplant and Epic. We are building our helper scripts to support our functional scripts and finding it is a daunting task but keep forging on.

I can't give you a clear explanation on which way to deal with the resolution issue. I think one of the things you need to decide is whether you are testing screen resolutions to meet your environment or testing whether certain screens function as expected.

Given that, we have found that the screen resolutions seems to be temperamental at times where one day test scripts work and the next they don't. Still trying to determine what is affecting this, whether it is the IT department with endless windows patches or configuration changes in how we use out test machines(SUTs). We have tried to move away with looking for images where hot keys are better. But recently noticed that some of Epic's hot keys do not work as it should in certain screens.

Also you can somewhat maximize the SUT machine and that seems to add to consistency.

I hope this helpful in some way.

Thanks,


Scott

Hello Dan and Scott,

I have been working with both Eggplant and Epic for quite some time, and here are some recommendations that I would have that might help you with some of what you are seeing.

  1. Stick with 1600x900 and make certain that the VM that you use as your SUT supports that resolution. If you go lower than that, you will miss parts of the UI (sidebars in particular) that could cause false positive errors. If you run at a higher resolution, I have found that performance will be affected.
  2. Create a script that checks to see whether the theme is set to High Contrast (checking the look of the Chart Search magnifying glass is a good way to verify). Per the Epic TS I spoke with, that theme is the least likely to change over time thus reducing the chance that you will need to recapture images.
  3. Upgrade to at least 18.2.3 if you haven’t already. there are known issues with 18.2.2 http://docs.testplant.com/ePF/gettingstarted/epf-v18-release-notes.htm with RDP that caused images captured in that version to be color shifted if you were using RDP.
  4. HotKeys - my journey of love and hatred. HotKeys are great and fast until they don’t work. Here are some reasons for total failure and intermittent failure:
    • Total failure - (confirmed within SUT and in standard Hyperspace session) Epic prior to 2017 did not prevent analysts from from inadvertently building or adding a menu item or toolbar button that shared its HotKey with another element or button on the screen. For example, the Override Query and Collect Enterprise Payment buttons both share ALT+e. There shouldn’t be many contexts in which both buttons are available, but I encountered a registration workflow just the other day that did, and my old standby of ALT+e for Override Query was suddenly failing.
    • Intermittent failure - (suspected within SUT and confirmed within standard Hyperspace session) The “sticky” ALT key. Have you ever been in a Citrix session of Hyperspace and find that somehow nothing you type appears or your screen? I encounter this rarely, but it is most frequently when initially logging into Hyperspace. More rarely, I will sometimes will encounter this within a Hyperspace session. I do not know whether the issue is within Hyperspace or Citrix or only when they are combined, but the system will begin acting as though there is an AltLock key, and you have activated it. Because the login screen has few HotKeys, and because those HotKeys are conditional (e.g. Log In doesn’t activate until both a User ID and at least one character of the Password field is typed), you may be typing away blissfully on a standard keys only to be sending their Alt equivalents to the UI. I typically clear this issue in a standard Hyperspace session by hitting the Alt key repeatedly until it lets me start typing normally. I do not yet have a magic bullet for times when it might happen in the SUT, if at all.
  1. Drawing lots and lost of Search Rectangles - When capturing images is problematic and HotKeys do not work as expected, I use Click (text:“MyText”) quite frequently. Both because text searches can be slow and because a word can appear in multiple places in the UI, I now pass the ScreenRectangle: parameter in my Click

    Click (text:“Accept”, waitFor:10, SearchRectangle:CommandDepot.ScreenPart(“BottomRightQuadrant”))

    To unpack this for you, I have a script called CommandDepot that contains nothing but functions and handlers. Within the CommandDepot, I have a function called ScreenPart. You can read about that function here: http://docs.testplant.com/ePF/using/epf-screenpart.htm I have added lots of portions to reference items such as the Windows TitleBar, the Hyperspace ToolBar, the Chart tabs, etc.
  2. Steal my code and modify for your own uses. I have code posted on this forum that you might find beneficial http://forums.testplant.com/discussion/2961/fun-tools-for-playing-in-epic#latest
Good luck to you both,
Dave

Hi Scott and Dave,

Thank you both very much for your feedback, I really appreciate it. I’ve posted some notes below in case you are interested. Sorry for the delay, too–I updated my notification preferences so I’ll be emailed moving forward.

Also you can somewhat maximize the SUT machine and that seems to add to consistency.
#2. Create a script that checks to see whether the theme is set to High Contrast (checking the look of the Chart Search magnifying glass is a good way to verify). Per the Epic TS I spoke with, that theme is the least likely to change over time thus reducing the chance that you will need to recapture images.

Agreed, I have a function which confirms Hyperspace is maximized upon login, and others (“Windows, UpArrow”, “WindowsKey, LeftArrow”) for ensuring an application is fullscreen or left half of screen respectively; very helpful for consistency given so many user / SUT combinations. We also exclusively use High Contrast in Epic; I love the idea of creating a function to check + apply that theme when necessary. Will put that together today.

For example, the Override Query and Collect Enterprise Payment buttons both share ALT+e.

We are in the midst of integrated testing for our upgrade to 2018 and this exact example cropped up! I was worried that this was going to be a widespread problem, but so far it’s the only instance we’ve encountered (probably due to how limited our EP tests are for Epic so far).

Intermittent failure - (suspected within SUT and confirmed within standard Hyperspace session) The “sticky” ALT key.

Interesting, I don’t believe I’ve seen the symptoms brought about by this issue before but I will keep an eye out for it. Thank you for the heads up–I can imagine this may have proven frustrating to pin down!

I have added lots of portions to reference items such as the Windows TitleBar, the Hyperspace ToolBar, the Chart tabs, etc.

This is SO awesome. I found the ScreenPart a little intimidating back when I was looking for a solution, so I devised an alternate script (posted below, in case anyone wants it for reference). The idea is that if we change resolution sometime in the future, we only have to update two variables (lines 2 and 3) and bam, all of our scripts calling upon the X/Y variables are good to go). The main challenge I suppose is that anyone scripting would need to be familiar with the grid, but we have reference images (examples attached) available in our shared OneNote.

That said, I love the idea of more user-friendly reference items like HyperspaceToolBar, etc. and may switch to your model (or take you up on stealing whatever I can and incorporating it into our version).

If either of you (or anyone else reading this) are interested in our approach to other facets of Epic, I’m happy to share as well!



Log “Initiating: hScreenRes” // See notes at bottom of script
Put 480 into XInterval // Resolution X = 1920
Put 270 into YInterval // Resolution Y = 1080

Put trim(((XInterval0),(YInterval0)),"()") into X0Y0 // (0,0)
Put trim(((XInterval1),(YInterval0)),"()") into X1Y0
Put trim(((XInterval2),(YInterval0)),"()") into X2Y0
Put trim(((XInterval3),(YInterval0)),"()") into X3Y0
Put trim(((XInterval4),(YInterval0)),"()") into X4Y0

Put trim(((XInterval0),(YInterval1)),"()") into X0Y1
Put trim(((XInterval1),(YInterval1)),"()") into X1Y1
Put trim(((XInterval2),(YInterval1)),"()") into X2Y1
Put trim(((XInterval3),(YInterval1)),"()") into X3Y1
Put trim(((XInterval4),(YInterval1)),"()") into X4Y1

Put trim(((XInterval0),(YInterval2)),"()") into X0Y2
Put trim(((XInterval1),(YInterval2)),"()") into X1Y2
Put trim(((XInterval2),(YInterval2)),"()") into X2Y2
Put trim(((XInterval3),(YInterval2)),"()") into X3Y2
Put trim(((XInterval4),(YInterval2)),"()") into X4Y2

Put trim(((XInterval0),(YInterval3)),"()") into X0Y3
Put trim(((XInterval1),(YInterval3)),"()") into X1Y3
Put trim(((XInterval2),(YInterval3)),"()") into X2Y3
Put trim(((XInterval3),(YInterval3)),"()") into X3Y3
Put trim(((XInterval4),(YInterval3)),"()") into X4Y3

Put trim(((XInterval0),(YInterval4)),"()") into X0Y4
Put trim(((XInterval1),(YInterval4)),"()") into X1Y4
Put trim(((XInterval2),(YInterval4)),"()") into X2Y4
Put trim(((XInterval3),(YInterval4)),"()") into X3Y4
Put trim(((XInterval4),(YInterval4)),"()") into X4Y4


Set the suitevariables to (X0Y0:X0Y0,X1Y0:X1Y0,X2Y0:X2Y0,X3Y0:X3Y0,X4Y0:X4Y0,X0Y1:X0Y1,X1Y1:X1Y1,X2Y1:X2Y1,X3Y1:X3Y1,X4Y1:X4Y1,X0Y2:X0Y2,X1Y2:X1Y2,X2Y2:X2Y2,X3Y2:X3Y2,X4Y2:X4Y2,X0Y3:X0Y3,X1Y3:X1Y3,X2Y3:X2Y3,X3Y3:X3Y3,X4Y3:X4Y3,X0Y4:X0Y4,X1Y4:X1Y4,X2Y4:X2Y4,X3Y4:X3Y4,X4Y4:X4Y4) // this allows these variables to be used in parent scripts

// This script divides your screen into a 4 x 4 grid made up of 5 x 5 coordinates. If our standard resolution ever needs to become higher than 1920 x 1080, simply divide the new resolution’s X and Y by 4 and plug those values into th XInterval and YInterval variables.



Wouldn’t let me attach images to my most recent post, please see below:









You could add two lines if you wish to allow it to flex with changing SUT resolutions:
Set XInterval to (.25 * width of RemoteScreenRectangle())
Set YInterval to (.25 * height of RemoteScreenRectangle())

Fantastic! Thank Dave!