Groups | Search | Server Info | Login | Register
Groups > comp.databases.pick > #2251
| From | dawn <dawnwolthuis@gmail.com> |
|---|---|
| Newsgroups | comp.databases.pick |
| Subject | Re: Time for something new for Excel? |
| Date | 2011-01-31 09:10 -0800 |
| Organization | http://groups.google.com |
| Message-ID | <4f69ee6e-1812-4fdd-b5ab-5bd8d2a49217@w6g2000vbo.googlegroups.com> (permalink) |
| References | <ffirj65udpvccc8otdii7p5kds2bu6tk2o@4ax.com> <1407ed1a-32fa-4534-9a66-7549b3a75e8c@x41g2000prh.googlegroups.com> <n1g9k6don1b32orb52jtl2h32lsrkoau7e@4ax.com> |
On Jan 29, 7:52 pm, Tony Gravagno <tony_grava...@nospam.invalid> wrote: > I'll preface this by saying that for now I can only respond with > answers to your questions with regard to NebulaXLite. But perhaps you > can articulate what requirements you have for spreadsheets in general > that seem to be unanswered with other tools. I'd like to understand > the divide between what power spreadsheet users expect and what MV > people think they can provide. I'd like this discussion to be broader > than the limited set of tools we are now using. > > dawn wrote: > >I am one of those who exports to csv, which means the spreadsheets are > >not pretty when opened in Excel or anywhere else. What would be very > >helpful to me is to export with more features without losing the cross- > >spreadsheet-tools support. For example, I have not even looked into > >how to make a column the width I want it to be in the exported csv, > >much less put a background color on the header or change the header > >row font. > > Kevin is right, there is no formatting when you use CSV. CSV is just > delimited data intended for any consumer. There are no instructions > in there which are specific to any consumer application. > > NebulaXLite does allow your BASIC code to define column width, row > height, borders, colors, merged cells, fonts, and a lot of other > details. See the documentation PDF on the download page for a > complete list of options. > > >I have no idea what cross-spreadsheet features there are. > > The documents that NebulaXLite exports can be opened by Excel, > OpenOffice, and Google Spreadsheets. This is possible because the > output is an XML document which conforms to standards. Your BASIC > code can post-process this if you wish to inject things into your > document that NebulaXLite does not. This is one of the reasons why > I've kept this a "lite" product. If I coded too heavily for one > application or another I'd alienate others. > > Note that this is also where we can separate the term "Spreadsheets" > from "Excel". (I could have used "spreadsheets" in the subject for > this thread instead of "Excel" but too many people equate the two > inextricably.) Excel is a program that manages spreadsheets, but not > all spreadsheets are Excel spreadsheets. Some nuances of OpenOffice > and Google preclude exchange of some documents, though to some extent > they can be interchanged. While there is a lowest common denominator > amongst these platforms, that LCD is much higher than CSV. I'm trying > to get MV people to raise that LCD to deliver better solutions to > people who expect more. > > Dawn, if you'd like to look at NebulaXLite, for now you'll have to > check it out in QM, D3, U2, or jBase. I didn't finish the Caché port > simply for lack of demand, but that situation can change. I no longer have a functioning UniData, UniVerse, or QM implementations as I once had, but when I get to that point I will at least take a look at the marketing info on NebulaXLite again. I will be evaluating what to do for showing users tables online in a web page along with options for users to turn the same data into an html report, a pdf or download to a spreadsheet. We have only one production implementation of an html report, using Cache' Zen reports. In theory we can turn this into a pdf as well (just a tad bit of setup and also some recoding there). We also have one live spreadsheet download. We are using three different approaches for these and might need to continue to do that, but we are currently generating the data for each separately and with separate specifications, which is not cool for keeping them in synch. At the very least we should use the same query and at best we would not need to regenerate it. Oh the details! --dawn > > Best, > T
Back to comp.databases.pick | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Time for something new for Excel? Tony Gravagno <tony_gravagno@nospam.invalid> - 2011-01-29 17:52 -0800 Re: Time for something new for Excel? dawn <dawnwolthuis@gmail.com> - 2011-01-31 09:10 -0800 Re: Time for something new for Excel? mdsi2000 <mdsi2000@yahoo.com> - 2011-01-31 07:21 -0800
csiph-web