An Idea Exchange for SAS software and services

Comments
by Community Manager
on ‎11-26-2016 08:13 PM

@ScottBass - Good News! The Find window is in EG 7.13.  And line numbers are there if you turn on the Show line numbers option in Program->Editor Options.

by Super Contributor
on ‎11-28-2016 05:35 PM

@ChrisHemedinger 

 

Hi Chris, is it the full functionality as the "usual" program editor in EG?  For example, does it have "Line ###, Col ###" in the lower right corner?  I use the col ### when I'm trying to line up the indentation level for, say, lines 5 and 500.

by Community Manager
on ‎11-29-2016 07:29 AM

@ScottBass - alas, no.  It shows line numbers in the margin, if you have Line Numbers on for your Editor Options.  It does support Zoom with Ctl+ and Ctl-, so you can check the layout of your program "from afar".  

 

For deeper manipulation and formatting, the workaround is to copy the code, paste into another EG session in a program window, make your changes, and paste it back.

by Super Contributor
on ‎11-30-2016 04:36 PM

Is it really that hard to make the editor functionality consistent within EG, whether you're editing a program entry or stored process code?  I'm of course not familiar with the coding involved, but I'm struggling to see why this would be hard.

by Community Manager
on ‎12-01-2016 09:04 AM

@ScottBass - I don't think it's a matter of difficulty, just priority.  I think we expect programmers to do most of the hardcore coding in the full program editor (where they can run segments of code, debug, use version control, etc) and use the Stored Process editor for smaller tweaks.  

 

You can use the full editor in your SAS Enterprise Guide project to work on code, then use the Replace with code from option to pull that code into your STP.

 

replace.png

Since there is already a way of working that allows you to leverage the full editor, it's more difficult to justify bringing the Stored Process experience to full parity (adds more complexity, testing, etc.).  But the spirit of this ballot is to allow others to weigh in, and if the current experience isn't "good enough", then I know the developers will want to hear about it.

by PROC Star
on ‎01-10-2017 09:25 AM

Personally, I avoid using the stored process editor to edit code by keeping my stored process code to a minimum (even just a single %include statement or a macro call), and leaving my real code in .sas files.  That way I can edit the .sas files in EG program editor, or any other editor.  Generally any stored process I have is going to involve multiple macro calls anyway, so as long as I'm relying on .sas files stored somewhere on the OS, it seems reasonable to put all of my code there, rather than buried in the stored process definition.

 

This is not an argument against the proposed enhancement, as I have seen many people struggling to edit extensive programs in the stored process editor.

by Regular Contributor
‎01-10-2017 10:45 AM - edited ‎01-10-2017 10:45 AM

To add to @Quentin's comment, editing SAS code directly instead of .egp files is better for version control. As .egp files are binary, versioning doesn't work so well. The code also works across versions (e.g., EG 6.1 can't open EG 7.1+ .egp project files), is more portable, and can be kicked off via shell scripts, etc.

by Community Manager
on ‎03-08-2017 01:50 PM
Status changed to: Implemented

We're marking this Delivered -- as much as it's going to be.  The main cases are covered -- no additional work is planned.

Idea Statuses
Top Liked Authors