LiveCode Forums.

Richard, it is a wonderful and very thoughtful reply which I really appreciate.

I could only say "yes" to each and every paragraph you have been writing. And yes, of course, in reality, we do not want to have another "Excel". This is just a challenging idea thinking about what one could do using Livecode, or not what would not be appropriate. And there is a serious background idea behind such line of thinking.

Let me make a step aside and not go into the technical and programmatical aspects, but just look at what I see on the side of my clients.

I am coming from REAL WORLD situations, mostly companies with 3-10 employees, and despite all the available database packages and applications, we have 2017 !!!, they are using MS EXCEL - FOR EVERYTHING almost. And in my personal sphere, these companies are mostly supplying products or services in construction. There are lots of calculations. But people DO NOT UNDERSTAND how to organize data in a better way. They are smart people, engineers, architects, etc. But still...

Applications for vertical markets are there in abundance, but somehow, in many cases I saw, they were purchased, but are hardly used. Accounting - ok. That is almost it. And this is not even only true for small companies. And the huge packages such as SAP, ... not for small companies.

And using a spreadsheet in a professional environment might be a good idea, but creates so many problems as well - as Richard described - that I am looking at a solution that could give the flexibility a spreadsheet offers together with the rigidness of a database application.

Or it has to be thought the other way around: What do people really want to do? How do they want to do it? And what user interface are they accustomed to not having to learn from scratch. This sounds pretty trivial, but ... )

---

Well - Livecode to me so far is a like a wonder box. I am a bit in danger to no longer see the wood for all the trees -- having opened the box for some weeks. But I hope to settle in more deeply finding the set of tools needed for my specific needs and sphere of interest.

Richard:

A good spreadsheet implementation will take many programmer-years to develop, and some of those features (such as discrete cell attributes) would probably be best handled in LiveCode Builder rather than LiveCode Script, where you have more granular control over drawing instructions but that freedom will come at the cost of needing to conceptualize your work along algorithmic and structural lines more akin to working in lower-level languages like C.

Yes. But I would at least like to see such granular approach to controls.

In today's world and with today's requirements, we should be able to do everything in Livecode that could be done using HTML5/CSS3. Of course, we can do it to quite an extent, as far as I understand, and even possibly more, but not yet to that granular level you mentioned.

Livecode - or better Livecode Script as I know it for now - is a fantastic tool. In user interface design I should be able to control still a bit more than what is offered today such as left, top, right and bottom borders, the spacing between all elements of visual controls. I do not even think that it is so much more than what is available today.

And the idea to turn all this into actual HTML/CSS and Javascript could possibly open a vast market. I am not sure if the idea to load all the functionality of Livecode using the HTML engine to the user level is the only correct way of doing this. But it is interesting nevertheless.

Livecode Builder - we will see ).

If they're productively using Excel, why write something else?

What does your app do? (Doesn't need to be detailed, just curious about its purpose.)

I am really all for Livecode. Nevertheless, not really happy with Googles spreadsheets, I am using gold old fashioned Microsoft Excel on Windows machines, and all my customers are doing the same. Even though there are issues with Excel, to move columns, or to reference cells is really easy once there is some experience.

For example, for a customer, and for a separate project, it took me about 30 minutes setting up a double entry accounting system allowing any number of accounts. And if I would have spent more time, I would also be able to secure wrong entries or check wrongly entered account codes.
Just throwing some fields, labels and buttons would not do the trick in Livecode. Of course, the same could be done using a data grid as far as iIunderstand. Maybe it takes a bit more time, but it is doable. Then using a database (SQLite for example to have it locally) would still require more work.

With some experience in Microsoft Access and Apples Filemaker, you can still bet setting up a fully functional database with several dependent tables with one or two hours. I would like to see this in Livecode ).

Nevertheless, if considering a database IDE such as Filemaker then possibilities are limited, and removing levels of abstraction, you would soon meet Livecode Script, and then maybe Livecode Builder, and then some Java or C#, and then C++ and C and Assembler and finally machine language. Each step down means more work, but also more possibilities a computer machine will allow you to do.

There is some version of Livecode now for Filemaker as I have seen. Unfortunately, it will not yet work in Windows. But could it be the right step? I would rather like to see it the other way around: Allow Livecode to handle data sources with the same ease as in Filemaker, and then really, I believe such magic is possible which you, Richard, described. (See also our conversation in "Data binding" thread).

To go into my own application development - well - I am still figuring out what it could be. There is no problem sharing such information. But I do not want to write just "something" as many people are reading these conversations.

Again, not to replicate a "real" Excel, but to look at what it can do means thinking about what would theoretically be possible in Livecode studying the user level behavior of Excel. There are several layers of functionality available. And doing the same with Filemaker ... what would be possible in Livecode?

Again, going by your suggestions, Richard, it should be possible for users to "throw" some fields and labels in a very user-friendly way, aligning them automatically, and connecting them using formulas and references, WITHOUT having them script anything.

There are users and users. Some will not touch a computer, others stare at the screen just watching, yet others are able setting up a Word or Excel document, another level of expertise would be being able to enter a formula into Excel !!! (great achievement already) - and so on. My customers are those who do not want to script anything at all (not even a mouseUp handler) but are able to enter a mathematical formula and visually link fields and do all more or less visually.

If the target user is someone who does not want to open any script editor, there could a solution helping him doing what he likes to do (within limits of course).

And I would guess there are 100 x more users willing to work with Livecode without using any scripting. It still scares them even if very easy. Still, you could enable them using Livecode with all the necessary building blocks for a data-driven system, a calculation system, a storage system, and the like. But yes, it would be yet another level of abstraction. And possibly, Livecode Builder would supply those building blocks (if not using the components we already have).

Yes indeed, scripting is for programmers; any user-facing UI must be point-and-click.

With behaviors it would be possible to generalize the scripting you do in such a way that your users can point-and-click their way through setting up formulas and such.

In that one regard I suppose it would be somewhat like a spreadsheet, but without the expense for the programmer to build an entire spreadsheet UI, and without the cumbersome workflows required of the user to lay out labels, input fields, and lists within a fixed grid.

Such an approach would seem to deliver an optimal blend for those tasks for which any of the existing spreadsheets are not already the best choice.

But of course the applicability of my thinking to your project will be dependent on workflow specifics I have no knowledge of. If the nature of the work requires that all layout elements be confined to a fixed grid, then perhaps a fixed grid is the way to go.

Thanks for all the comments. Highly appreciated !!!

Here is a little progress report for those who might be interested. I have spent about 4 hours so far. Not too much for the achievement, I think. Thanks to LC ).
Well, I wanted to say that I made some progress and through this learning in doing I get a crisper understanding what LiveCode could actually do for me and others. And I am still using an Excel-like spreadsheet as something to learn using LiveCode. Now, after some hours additionally spending on the subject, I feel pretty sure that this is not a task for many months or even years. The basics of quite a nice and workable spreadsheet can be done in days !!! And it would not take more than 4 weeks to come up with a nice solution. It is my belief now.

Exploring the world of LiveCode - the problem is that I do not know all the many functions by heart to immediately apply them and understand. And often enough I do not know what to search for. How would I know a certain function name? I would have had to read all the dictionary from A-Z and make notes and keep track. Probably I should do this.

Well, regarding small-scale Excel, I believe I got the basic solution. Each cell is a field. The rows and columns are indicated using buttons (or graphics). Each cell has its name using a combined row and column button name, as everybody intuitively would use. The numbered row fields receive the letter "r" in front of the number since an object should not just have a number as its name. Otherwise, what is button 1 if the name is 1 and its actual number would be 5? Custom properties store different values and different states of the "cell"-field. The same information is also already stored in a corresponding array. (I just believe such array gives advantages to speed up certain selections and executing formlas, even though all objects in this application are already storing all information.)

Just now, I can already select rows, columns, even discontinues cells, rows, and columns. The basic field state is locked. When the user selects a field, either through double-click or starting to type the field is opened for editing and changes the state. Another field state is stored when a formula is applied.

For indicating row and column hilites I am using graphic objects on top or behind the fields to create visual effects, especially lines and rectangles. The background color is also changing according to the state.

When the user enters a formula, I can parse the text string. If the "=" equal sign is used as the first char (not counting spaces before and after), this would be a formula which will be stored in a custom property.

In my LiveCode spreadsheet, I am using a fixed number of cells. They could, of course, be created dynamically when needed. Already all objects are created by a script. Placing them into a group and then using horizontal and vertical scroll bars will allow to also scroll up and down through the spreadsheet.

Of course, there are little small details which keep me thinking.

One detail, and therefore a question, is, how best to parse entered formulas and execute them.

For example, in the simplest form, a user enters =A1+A2 as the formula into cell B1. Expected is that the cell will look up cell "A1" and "A2", which the user clicked, then add the values and place the result into the first selected cell. The problem here is the parsing. The user might use spaces or not, enter wrong formulas, etc. If there is no space then how to know the cell reference or what is an operator. And also wrongly entered data must be accounted for. Well, of course, it can be done and I have done it for the simplest cases already.

So, what I am doing here is using the elements of the formula and execute them through a "do" statement. The string that I have build in scripting in this example would look like:
Since I know the id number of each field, either looking up the field object itself or looking up the id number in my array of cells, I can also use another way and tested this as well. I know that the "do" command should usually be avoided. And the solution should be flexible enough to allow to be extended with all those formulas using the commonly known spreadsheet syntax (or, maybe, additionally also LiveCode expressions themselves).
After execution using The Return or Enter key, the formula becomes invisible being stored in a custom property (and/or my array) and the result is shown in the target field the user selected. Actually, so far, all behaves very similar to Excel itself and I am using Excel as the blueprint.

It should be relatively easy to also shift columns or rows around, copy and paste them elsewhere, hide columns or rows, lock fields, and actually created a better user experience partially than Excel creates.

Where I still see more problems is how to have text entered into a field stretch over to other fields, or combining fields to be one field (which I think is not good practice anyway even in Excel itself), and changing text formatting making all other rows and columns shift all the time might be a real challenge.

Or on the visual side, people like to underline cells or groups of cells. Since a field in LC does not allow to address object borders individually, graphic lines would have to be used which would sit on top of the border sides of a cell or more cells. And a user who is reformatting the spreadsheet will then require touching many such objects at once.

When I find the time, I will continue building LiveCode "Excel" and maybe the time may come when I will feel I (or others) could publish. Any suggestions, critical remarks, etc. are welcome. This is beginners section.

Such application - if really made well - would speak for the quality of this LC language. Also, I think it would be used since it could make things much easier for people who are confined within the boundaries of current Microsoft Excel. And as it usually goes, 80% of Excels functions and possibilities are not used by the ordinary user anyway. What would be the effort doing this in the LiveCode Builder (LCB) language?

Scott McDonald of RunRev Planet has already written a spreadsheet for liveCode...

by Dixie:

Scott McDonald of RunRev Planet has already written a spreadsheet for liveCode...

That would be very interesting to see.
I have been looking up http://www.runrevplanet.com/, and then http://www.runrevplanet.com/rrpgrid.html
Unfortunately, there is the following note:

The stack is not yet available for LiveCode 8.0, and may not be compatible with newer versions of LiveCode.

Also, the download-button is disabled so that there is no way to check out the demo.
Does anybody know if this spreadsheet will become available?

Just contact the author and ask how much he wants to upgrade to livecode 8 his plugin. We could rise a crowfounding

Short hint: Here DO is really not required!

HI Hans,

I can testify to the RRPGrid By Scott Mcdonald is a brilliant bit of coding.

Much easier to get into than the DG (although DG is more powerful as it is more generic) with well thought out "orthogonal" functions. Once you get started
you can pretty much guess what the call you need will be named.

Scott added a couple of things on my suggestion which allow better control for things that I used it for, and your "Excel" would use that Scott had no use for when he wrote it.
He wrote it because he needed it and what is in there is brilliant.

You can get the trial version to use for an unlimited period to get things working, the only limitation is it won't compile into a standalone.

If I were you I would get the old version now and test it with version 6.7.11 of livecode and by the time you get upto speed he might have the new one ready.

I would certainly crowdfund the new version. - even though i'm using 6.7.11

Regards Lagi

Hi,

Hans-Helmut wrote:Also, the download-button is disabled so that there is no way to check out the demo.

It's well hidden! The download link is left of the DL button, at the right side of the OS symbols ;-)

And I don't know what shouldn't work in 8 that works in 6 - though I'm coding in 6.7.10 for bread & butter, I often try my results in the "public betas" (8 & 9). I have yet to find something that doesn't run.

Have fun!

Klaus wrote:

put field "A1" + "A2" into fld "B1"

. Yes, of course, I know.
But you have to build such and other functions dynamically using a script, and not type it. So, you would end up with something like 'put "put field A1 + field A2" into tExecute' and then do "tExecute". Or am I missing something? Of course, if you would know that this is the only command then it would be easy since you could refer to the field names passing them as parameters. To allow for any possible variant would mean preparing all possible variants as functions referencing field names which are passed together with a function assignment parameter. ?

I have tried downloading this rrpGrid.rev:

http://www.runrevplanet.com/rrpgriddownload.html

It simply does not open in LC9 dp 6. (and maybe also not in LC8). I will download an earlier LC 6 version.

Yes, I could not first find the download link since the "Download" button does not execute. Thanks for the hint that the link is next to the operating system icons.

Hi,

it doesn't run in 6.7.10 community, too: (Trying to open one of the demo stacks)

Further, the license (licensed per person) makes it close to impossible to use it in commercial applications w/o running the risk of at least aiding & abetting license violations.
No customer in a clear state of mind would accept such - one license for each one for the 2 persons sharing a role & program, and a new license every time one of them is fired & replaced ...

Deleted.

Have fun!