Groups | Search | Server Info | Login | Register


Groups > comp.databases.pick > #2251

Re: Time for something new for Excel?

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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