What I really need is Excel
 

Wenn are working lots and heavily with MSExcel.
It is great gut also the showstopper to migrate over to Linux as there are Macros and Formular based spreadsheets. No way to easily going to libre Office to replace functionality!

Bye, Rob

Utherverse
 

This program. http://www.utherverse.com/

Gnumeric for Excel
 

Gnumeric seems to work perfectly on Excel, make a change with Gnumeric, then go back to Excel and the change is there.

LibreOffice has an excel type of spreadsheet. It is supposed to be compatible with MS Office.

A commerical (donation ware) product titled wps (wps.com) has a linux version of MS Office. It looks like, and feels like MS Office, and it even uses the Ribbon presentation.

I use the latter (wps) for large documents.

I'm with you on the VBA stuff. I've yet to see any other spreadsheet which can use Excel's VBA macros as is. OpenOffice/LibreOffice does include something similar, even using similar language (SBasic), but you can't simply run your VBA macros in it. You'd need to re-write them to use the Calc specific libraries instead of the Excel specific ones linked to in the VBA code.

Unfortunately MS does not license VBA anymore. So chances that you can find any other program able to run VBA code is pretty slim. In fact, MS has discontinued sales of VBA some years ago. The only programs which still have VBA are those which licensed it from MS before they discontinued it. Even MS would advise you to translate all your VBA macros to DotNet instead. For that reason I'd start looking very seriously at either converting or redoing your macros anyway. This is one of the reasons you do not want to be tied to any one supplier like MS tied everyone to their VBA.

You could attempt something like this Excel VBA to OpenOffice Basic Converter to try and convert your VBA code to OpenOffice/LibreOffice's CAlc sBasic. It may do it reasonably for most of the simple macros. But I'd think it's not too great for more complex stuff. You'd most likely need to edit some things manually. It may be a start which could save you lots of time though.

LibreOffice also supports Javascript or Python for macros. Having fewer languages to maintain cuts down on the overhead. So if you have to convert, you might as well convert to something you are already using and save time and money.

Edit:

http://christopher5106.github.io/off...on-macros.html

Agreed. Not just JS and Py, but also a variant of Basic (similar to the Visual Basic used in VBA). Also some others like BeanShell. Not to mention you could even code using C++ or Java if you so wish. It's not that you HAVE to use all of them, you've got options. There's nothing wrong with choosing one and sticking to it, in fact most would do just that. The difference is that if you find you can do something more easily in another, you're not tied down by having to stick with one language only - it's only up to you, not someone else enforcing something onto you.

Though the question was regarding taking existing VBA code into something other than Excel. Closest match to that in Calc (both OpenOffice and LibreOffice) would be sBasic. Not JS/Py/BS/etc. So at least the translation from VBA to sBasic (in LibreOffice it's called LibreOffice Basic, OpenOffice still refers to its original name during the Sun days when it was made for StarOffice) would result in something which wouldn't look entirely foreign to someone only ever using VBA. At least syntax-wise it's not more like C (as JavaScript would be) or something entirely different (like Python would be).

If you mean it's not good practise to keep two variants of the same thing as Excel's VBA as well as Calc's sBasic, then I'm with you. It becomes a maintenance nightmare. You should choose one and stick with it. Personally, I'd choose Calc and sBasic (if wanting to stay with a Basic-like language rather than learning something completely "new") - since it means whatever I make there can run anywhere, since LibreOffice is installable on anything (including Windows), Excel not so much.

This discussion has made me think that what is needed is another way to process data sets which is less display-dependent than Excel.
What I mean by that is that Excel blurs the lines between data, data types and formatting. What I think would be good is something which deals with small data sets then allows formatting (charts, tables and the like) to be applied independently without changing the initial data set. I know databases do that kind of thing but Excel does allow for much easier manipulation of data than most database applications I have seen.
Excel seems dangerously useful -- dangerous in that it almost constantly tries to change the data it is displaying and useful because nothing really comes close to the ease of getting results that it offers. I think that, today, we ought to be post spreadsheet and it worriers me how many people trust spreadsheets with very important data without realising just how fickle spreadsheets are about data fidelity.

You could also try a 3rd party printer company, Turboprint.

With the regular CUPS/Gutenprint driver for my 12 yr. old Canon i960 inkjet, I can only get 600 dpi out of it.

Fine for a letter, but not enough for graphic arts printing, which needs 1200 dpi.

The Turboprint drivers are not FREE. You get a FREE 30-day trial and then it will print a watermark on your copies.

http://turboprint.info/

If you buy ver. 1 of Turboprint, you can buy the upgrade to ver. 2 at a discount.

Also, the Turboprint driver, at least for Canon, includes ink level meters, so you can monitor how much ink you have left.

My i960 is not listed in the list of models on OpenPrinting.org. From prior experience I know that I can select the BJC-8200 but really I should have the full capability of the i960 out of the box, without having to purchase a license for TP.

Off topic: To each their own but the more we learn with the more we'll find useful.
 

Or, CLI is like ditching the clunker and leaning to safely drive the top of the line electric racers... LOL!

[screencast]q_cRqcbXAs4[/screencast] :hattip:

Agreed a spreadsheet tends to gloss over such typing errors as rounding mistakes, overflows, etc. Making the user think everything's fine, while the answers could very easily be garbage.

Not to mention, a spreadsheet allows for inordinate amounts of human error at nearly every single point. E.g. http://www.cio.com/article/2438188/e...-blunders.html Not the most "safe" alternative when your business is at stake. Especially since most using a spreadsheet aren't exactly "programmers", meaning they wouldn't even know about the possible calculation nuances a specific number type may be causing. And since all the formulas a hidden inside individual fields, a quick glance over the formatted document does not help in catching these - only a manual recalculation has a hope of spotting any mistakes.

Unfortunately a spreadsheet is a live document working from programs (i.e. the formulas), usually built by someone not really invested in making "programs". Thus not doing adequate testing of those "programs" they've just written. Not that all programmers do adequate tests either, just they they should know better, while non-programmers don't have a reason to "know better".

Your idea of something as easy to use as a spreadsheet, but providing the power, efficiency, stability, interchangeableness, etc. of a database is very commendable. And I do agree that such is a good aim for some invention, definitely a good idea to split data from formatting, perhaps even split off the calculation formulas as well - which is exactly how databases operate: data in tables, calculations in queries, formatting in reports / data entry forms. I just fear that the inherent issue with spreadsheets is tied to its ease of use, as soon as you provide users so much "simplicity" to do anything in one place, you open the path for errors to creep in.

Yes, I certainly see that, in some ways, what I am suggesting is almost self-contradictory. When I see a lot of spreadsheets I just wish that they were harder to make because the person making them obviously did not write the code carefully.
The reason I would like to separate the data from the formatting is so that if somebody does come along who knows a little better they can then try to correct issues because the real data is there and hasn't been converted into some random Microsoft format for "ease of use".
By the way I'm not suggesting that I am a good data processor, more that I at least have been formally taught to understand what data types are so I at least approach a spreadsheet with a mind to preserving information.

Dragon Dictate
 

All the Linux solutions are not worth the effort and wine only supports ver 12.5 poorly at best. I love playonlinux and I'm well versed in the use of Wine but Dragon ver 13 which finally has good integration with Libre Office Write is not supported.

nothing
 

Linux just great as is.

Thanks Jeremy Nice Post and Good shareing