About CaseySmith

CaseySmith · ‎07-14-2017

@SASKiwi is correct, there is not currently a way to do this. However, we are planning to add more robust column/row auto-sizing options in a future release. We certainly recognize the convenience it would provide.

CaseySmith · ‎07-06-2017

I personally prefer the F8/F3 behavior as well... if code is selected, run selection, otherwise run all code. It would be my preference for the Run button to behave the same way by default. (Accidently running a selection when you intended to run all is usually less painful (and less likely -- though I certainly do it with F8/F3) than accidently running all when you meant to run a selection.) However, I can also see the other side of the argument being made. And as Chris mentioned, I'm afraid changing the default Run button behavior at this point might throw current users off who are used to it. As suggested, perhaps we could prompt the user if code is selected when the Run button is pressed. That would help users learn, a little less painfully. Though prompts can be annoying and often aren't read (and/or forgotten after "do not show again"). Another option (not necessarily independent) would be to make the Run button a sticky drop-down, so we could leave it up to users to decide the behavior of the Run button. For example, the Run dropdown button would have a "Run All" menu item, a "Run Selected" menu item, and a "Do not set default" toggle menu item. When "Do not set default" is unchecked (the default), whichever Run menu item ("Run All" or "Run Selected") was last selected would be the new default behavior when the Run button is clicked. We'd probably also need slightly different icons to distinguish between the two to tell which one was currently active. (I've seen similar sticky dropdown buttons in some other applications.) I'll discuss with our UI/UX designer to see if we should consider changes.

CaseySmith · ‎07-06-2017

I suggest checking to see if the SAS Add-in for Microsoft Office (AMO) is installed and activated in Excel on those other machines. For example, when you open Excel (on the other machines), do you see the SAS ribbon (and able to view its Help->About dialog)? If not, you'll need to install (if not already) and enable it (SAS Add-in for Microsoft Office) in Excel (which you can do with the SwitcherUtility.exe utility in the AMO installation folder... ex. C:\Program Files (x86)\SASHome\x86\SASAddinforMicrosoftOffice\7.1\).

CaseySmith · ‎07-05-2017

We are going to try to handle this a little better in a future EG release by being a little more conservative about opening data -- or least providing one or more options to allow users to choose between the convenience versus the performance of automatically opening data. Casey

CaseySmith · ‎07-05-2017

This paper by @TimBeese might help if you haven't already seen: http://support.sas.com/resources/papers/proceedings11/012-2011.pdf

CaseySmith · ‎06-28-2017

Unchecking "Open output data automatically" (in SAS Add-in's->Tools->Options->Data) should prevent any output data sets created by your stored process (and any other stored processes, programs, or tasks, since a global option) from automatically being opened in Excel.

CaseySmith · ‎06-28-2017

On a related note, mapped network drives are not automatically available through SAS Workspace Servers on Windows hosts. To make mapped network drives available to SAS clients through your SAS Workspace Server, add a net use command to the workspaceserver_usermods.bat file on your server. For example: net use k: \\YourNetworkShare\SomeFolder

CaseySmith · ‎06-27-2017

Hi @papertrail, We are aware of this issue, where high DPI settings (greater than 100%) over-scale the program editor. We plan to fix it in a future release. For now, to workaround this issue, we suggest going to Program->Editor Options...->Appearance tab, and setting the Size to a smaller, more reasonable size. Note: You'll have to set it separately for both File type: SAS Program File, SAS Log File, etc. to update both code, log, etc. Casey

CaseySmith · ‎06-22-2017

Only other possible solution I can think of is to figure out what process has the clipboard open and avoid it. Perhaps a tool like ProcessMonitor would help accomplish. Although, there is a possibility that it is something in EG resulting in the inability to access the clipboard, rather than another process -- we simply haven't been able to reproduce this. Sorry, I know that's not much help.

CaseySmith · ‎06-22-2017

Hi @ErinKSimmons, This is an issue that some users have encountered, which we've aleviated in newer releases. If you are able to upgrade, you will not see the error in EG 7.13, 7.12 HF1 or later, 7.11 HF5 or later. We suspect (since unable to reproduce without artificially using another test app to open the clipboard) the root cause is that another process has the clipboard temporarily open, which prevents other processes (such as EG) from opening the clipboard. To address, EG is now gracefully handling when unable to open the clipboard. Casey

CaseySmith · ‎06-19-2017

@ChrisBrooks is correct. Using Visual Studio 2017 to create your custom tasks is completely fine *as long as* you target a version of the .NET Framework that is compatible with the version of EG or AMO you intend to run the tasks in. The following table shows the .NET Framework version that was targeted by each EG (and AMO) version: SAS Enterprise Guide .NET Framework 7.1, 7.11, 7.12, 7.13 4.5.1 6.1 4.0 5.1 4.0 4.3 3.5 For a custom task to be compatible with a specific EG/AMO version, it must target the same or earlier .NET Framework version. For example, if your custom task targeted .NET Framework 3.5, it should work in EG 4.3 and later. This also means you can't accept the default .NET Framework version used in Visual Studio 2017, since it is 4.7, which is newer than the current latest version targeted by EG/AMO; you'll have to change it to target an older .NET Framework version, depending on which versions of EG/AMO you wish to support. Casey

CaseySmith · ‎06-16-2017

You are welcome! Glad to help.

CaseySmith · ‎06-16-2017

EG does not currently directly communicate with cloud-based Git repository services, such as Bitbucket, Github, etc. EG directly works with locally cloned Git repositories, regardless of where they are cloned from (Bitbucket, Github, in-house remote origin, or any other repo). The User name and User email settings in Tools>Options>Program History>Git Settings are passed to Git, so that when you commit changes, others see who made the changes.

CaseySmith · ‎06-16-2017

Hi @tnimmo0, So, you are trying to connect to a remote SAS server, not a local SAS server, correct? What version of SAS is your remote server? Still SAS 9.1? The error you shared indicates that EG was unable to connect to a metadata server at host sasuk.company.corp and port 8561. So, here is what I would suggest trying: First, confirm you can ping the host... execute "ping sasuk.company.corp" in a command window on your client machine. (If you can't ping the host, that is most likely the problem. The client has to be able to access the server on the network.) Next, try making a test connection to the SAS metadata server using the SAS Integration Technologies Configuration Wizard... Run ITConfig2.exe (C:\Program Files\SASHome\x86\Integration Technologies) to launch the tool. Click Test SAS Servers->Enter a SAS server definition manually Change Currently Testing to SAS Metadata Server, then specify the same information that is in your EG profile. For example, specify your SAS metadata server host in Machine Name field (sasuk.company.corp), set Port to 8561, specify your credentials, and click Test. If you are not able to connect to your metadata server from ITConfig2.exe either, there is probably an issue with your connection information or metadata server. If you are able to connect to your metadata server from ITConfig2.exe, confirm you are specifying the same information in your EG connection profile (click link in bottom-right corner of EG, on status bar, to bring up Connections dialog to confirm your active connection profile). Casey

CaseySmith · ‎06-15-2017

I suggest starting with the Bitbucket documentation. For example, here is how you would clone a repository to your local machine: https://confluence.atlassian.com/get-started-with-bitbucket/clone-a-repository-861178563.html After making changes to your .sas files in the locally cloned repository using EG, here is how you could commit the changes and push them back to Bitbucket: https://confluence.atlassian.com/get-started-with-bitbucket/push-code-to-bitbucket-861185309.html Or you could commit the changes directly from within EG (as documented in the paper you referenced), then push using Git command-line (as demonstrated in previous link), or using a Git GUI, such as Git Extensions, SourceTree, etc. Again, working with cloud-based Git repositories (such as Bitbucket, Github, etc.) in EG is almost identical to any other remote Git repository. You clone it to the client, work out of your locally cloned repository, commit changes to your locally cloned repository, then push the commits back to your remote origin repository (Bitbucket in this case). Casey

Online Status	Offline
Date Last Visited	‎10-09-2025 07:58 AM