Is it possible using SAS to export an Microsoft Excel formatted file that uses Excel's built in conditional formatting? I know I can use Proc Report computational sets to change formats, and I can use the ExcelXP tagset to control colors, but I need to use Excel's built in Conditional formatting, not just setting the format in SAS.
If you use a pre-formatted excel sheet you can export to it and it will maintain the conditional formatting. Proc export or the macro here is useful http://sascommunity.org/mwiki/images/f/f4/1793-2014.sas
Or if you need some sort of dynamic control could write a VB script that then gets called via DDE but also way too complicated IMO.
Short of Reeza's suggestion (ie. actually using excel to do the conditional formatting) there is no supported way to do this.
We had to do this for our web-based reporting, and we ended up writing our own conditional formatter (in jQuery). It applies excel-like conditional formatting because despite our best efforts we couldn't figure out exactly how the excel conditional formatting algorithm works (it has some quirks). I don't think anyone would ever notice the difference though.
I've entered this as a suggestion in the SAS software ballot. I'll edit this post and share the link if the idea gets 'approved'.
EDIT : You can vote here . Voting will require a login to the SAS website.
Related
Is it possible to create a conditional format or something like that where the format is depending on the value of the cell?
For example when there is "#000000" as cell value, the background color of the cell should be black.
It is possible to have a condition on the cell value but I did not find any example where the format is dynamic. And it is no Option to create a format for each possible hex-color =)
Yes it is possible to add such a conditional formatting dynamically using Aspose.Cells. Please add your desired conditional formatting using the Worksheet.ConditionalFormattings collection. It will be better if you create your conditional formatting using Microsoft Excel and then load your workbook using Aspose.Cells and observe the properties of your conditional formatting object by exploring Worksheet.ConditionalFormattings collection and then create the same conditional formatting object through code. If you find any difficulty, then please feel free to post in Aspose.Cells forum on Aspose Website.
Please also see this article for your help in working with conditional formatting.
http://www.aspose.com/docs/display/cellsnet/Conditional+Formatting
Note: I am working as Developer Evangelist at Aspose
Assume here is the data set.....
Aspect Evaluation Quarter Percentage
HOST/HOSTESS DIVERSIONS /687 Excellent Q1 40%
ROCKIN' BAR D / WAVEBANDS/ EVOLUTION Excellent Q1 50%
KNOWLEDGE OF SERVER TEAM – ROTATION Excellent Q1 60%
Trying to generate below Excel Sheet with same color and Structure, assume the above percentage will be populated in “% Within” column ......
Any way to get the excel in this required format....?I appreciate any help...
Thanks,
Sam
If you're going to do color and such, you have a few options. PROC EXPORT won't do it, of course. So instead, you need to do either Excel Tagsets, DDE, or create an unformatted sheet and use a macro from a template to copy the colors in.
Benefits/Drawbacks:
Excel Tagsets:
Benefits: Make the exact format entirely in SAS code. Have a great deal of control with a fairly simple interface. Uses the powerful PROC TEMPLATE to define styles, which allows highly portable and reusable code.
Drawbacks: Makes an .xml file that is readable by excel, not actually a .xls/.xlsx file. Does have some limitations in what it can do. Can be buggy. Probably the slowest to code of the three options, unless you are very familiar with it.
DDE:
Benefits: Once you make the template (once) in Excel, can make exactly what you want fully in SAS. Can do 100% of what Excel does.
Drawbacks: Uses somewhat outdated method, so fewer SAS programmers are familiar with it. Requires Excel to be installed on the machine, and open (you can open it as part of the DDE program). Somewhat slower to copy data in, and requires more careful checking to verify data went where it should go. Requires knowing DDE commands.
Template/copy:
Benefits: Likely fastest method in terms of set up time. Can do everything exactly like what excel does. Easy for other programmers to understand, as long as they know Excel/VBA and SAS.
Drawbacks: requires outside-of-SAS step to run copy macro (could be called from SAS via DDE or batch file, but more commonly would be done by hand). Does require some knowledge of VBA as well as SAS.
In general, I recommend trying Excel Tagsets first; if they don't work for your needs, try either of the other two options. Some good papers on Excel Tagsets for the beginner:
http://support.sas.com/resources/papers/proceedings11/170-2011.pdf
http://support.sas.com/resources/papers/proceedings12/207-2012.pdf
http://www2.sas.com/proceedings/forum2008/036-2008.pdf
I think you could create the above pretty easily using excel tagsets and proc report; follow the first paper in particular as it seems to be the most similar to what you're doing. If you run into any issues, post them as separate questions and we should be able to help you out.
I was wondering how difficult it would be to make an application like this. Basically, I have some old html files that use tables. I want to put these tables into excel for easier reading and manipulation. I only have text, I have no numbers of formulas or anything.
Are there any tutorials on how to do this sort of thing?
The application would produce .xls
Thanks
You have three options:
Output a CSV file. While not an XLS file, Excel is more than capable of opening such a file, and it's extremely easy to create. You need nothing more than standard C++ to implement this solution. This is by far the easiest and quickest way to output to Excel (or any spreadsheet program, for that matter).
Use OLE automation. Microsoft even has a Knowledge Base article that provides an example of how to invoke Excel from your native C++ application and fill in some values. If you absolutely need to output XLS files, this is the easiest way to go. Note that users must have Excel installed on their computers for this to work.
Create your own XLS writer. Don't even bother with this option unless you really want to generate XLS files without requiring Excel to be installed on end-user computers. Options 1 and 2 are more than good enough for just about any application.
You don't need to reverse-engineer the XLS format; Microsoft documents the excel file format here. Due to the evolution of Excel over the years, it's not exactly a clean specification.
If you don't mind installing a copy of Excel along with your program, using OLE Automation would be much easier.
The simplest thing to do is simply create a CSV file. If you have column headers, put them in the first row. CSV files can be opened natively in Excel as if they were Excel spreadsheets.
There is a trick here: save .html tables with the .xls extension and Excel can read them (ie Excel can read the output of the DataGrid control).
But, if you want to create 'real' Excel files, then you can either use Excel Interop (which could be messy, requires Excel and the PIA's to be installed on the machine, and needs careful memory management (since its COM)). You could also opt for a 3rd-party library like FlexCel - which will avoid many of the InterOp problems but will not give you 'complete' Excel functionality (addins, custom vba macros etc.). For most uses, however, a 3rd party library should do the trick.
Looks like there's another alternative called ExcelFormat. I didn't try it, though.
How can i make user to downlaoad a excel from the django app.i HAVE A MODEL WHICH gives the report.Now i want a option from user can download the file in excel form.ANy Solution
You can output the data as .csv which is easily imported into MS Excel.
http://docs.djangoproject.com/en/dev/howto/outputting-csv/
EDIT
After I wrote that I got curious if there actually was some way to do it directly to excel format and found:
http://www.python-excel.org/
That made me wonder why you didn't google your question before posted it here.....
I'm not sure quite what you're asking. If you're asking how can you generate output that's able to be read into Excel, IMO your best bet is using a CSV (see amoeba's response) as that's pretty generic. There are ways of using true Excel formats as well.
I'm thinking though that perhaps you're asking how you can have a user click a link (or whatever) and have Excel pop up with your data in it? (IOW, you've already generated the output).
I suppose I'd say a few things:
1) It shouldn't be specific to Excel, many users use things like OO.o (thus my CSV suggestion)
2) It's going to vary depending on their browser and how they have it set up. Personally, I don't like pages opening up the "proper application" so I turn all of that off - other people enable it.
In the enhanced editor, the coloring might give you a hint. However, on the mainframe I don't believe there is anything, in the editor, that will help you.
I use
OPTIONS OBS=0 noreplace;
The obs=0 option specifies that 0 observarions are read in from the input
dataset and NOREPLACE tells SAS not to overwite an existing SAS dataset with one of the
same name. If you are creating a new datastet, it will be created with all the attributes,
but with 0 observations. (Be sure to reset the options, if needed, to Options Obs=max replace ; when no more syntax errors are found).
I'd be interested in any other techniques.
Thanks
Explanation about options came from here.
I use the cancel option on the run statement. It will check the syntax of the data step then terminate it without actually executing it. It's the data step analog to the noexec option in proc sql.
data something;
<stuff here>
run cancel;
Lots more details in this SUGI pdf
I write all of my code on my PC with SAS on my PC and the enhanced, color coded editor. I then use SAS/CONNECT to process it on the mainframe. If the datasets are on DASD, I use SAS/CONNECT and Enterprise Guide to directly run the code onthe mainframe (no JCL!) If there is a data tape involved and therefore must be a batch run, I use SAS/CONNECT and the SAS ftp engine to send the code to the mainframe batch queue. I use the SAS email engine to email me back my output and my log. I put and ODS sandwich aound my code to have the mainframe generate a WORD document for output. I use a PROC download to download the output to my server so I can open it in WORD.
This advice is language agnostic.
I would argue that a preferable technique for catching syntax (and logic) errors is to perform a close read (or inspection) of your own code (which should catch the majority of syntax errors), followed by unit tests on small datasets (which will catch any remaining syntax errors, as well as many logic errors if your tests are well-designed).
I agree there's some worth to syntax checking in isolation, but to read and understand your code thoroughly enough before the first compile so that you know it will compile is a good ideal to strive for. Steve McConnell touches on this idea in Code Complete (see page 827 of the 2nd Edition).
P.S. You mentioned syntax highlighting in your original post; there are other editors (such as VIM) that will perform syntax highlighting on SAS files.