Grasshopper Excel Interop

Replies to This Discussion

Permalink Reply by Sameer Kumar on August 27, 2009 at 2:28pm

As per my wishlist, reading from and writing to (both, creating a file from scratch and add/replace in an existing file) would be a priority.

This should logically follow that when a file that GH is reading is updated and saved, the GH model will know and update itself if the model is open or when it is next opened. I would like to think that whether the excel file is open or not should not imply any change in GH response. This should be true also for writing the data into excel.

One last word: Excel being a proprietary/paid software, it would be nice if the interface with GH was not limited to Excel but also to other opensource software like OpenOffice. But that is low down on the priority.

Permalink Reply by Damien Alomar on August 27, 2009 at 9:51pm

What I would invest the most time into is parsing Excel files, therefore circumventing having Excel installed. Hopefully that would make writing them out natively easier as well. After that I'd find a way to display SPREADSHEET data (ie, not just excel data, but csv/potentially open office data) in GH with some sort of rich formatting (rich text, background colors, borders, etc). Tapping into a running instance of Excel would be good and isn't that hard at all, however, some indication that a link (live or not) has been made would be good.

I'll send you all the stuff I have linking Excel to GH. Whether its any good or not is up for you to decide :) Except for displaying spreadsheet data in GH and reading/writing the files directly, its all more or less in there.

In addition to what you've put up there I would suggest thinking of this as a "spreadsheet" link rather than and Excel link. This would mean opening up the possibility of linking to OpenOffice Calc, as well as integrating with CSV files (easy) and web/html tables as well.

HTH,
Damien

Permalink Reply by Vicente Soler on August 27, 2009 at 10:22pm

I would disagree in regards to having a spreadsheet display inside grasshopper that reads csv, etc. I've had that experience with Revit. They didn't want a live connection to Excel so you are forced to use their limited spreadsheet interface. Excel has a lot of great features that would be pointless to develop again. Similar to taking advantage of the .NET platform, that already offers a lot of features that would be silly to develop from scratch. I'd rather see Excel tightly integrated as a live link with Grasshopper updating real time.

There's nothing wrong with linking to a proprietary software ...how dare Microsoft try to make a profit out of their software. Open-office should not be desired just because it's open source.
Btw, big businesses like open source because it kills the small startup companies eliminating competition.[citation needed]

Permalink Reply by Damien Alomar on August 27, 2009 at 11:13pm

I'm all for a tight integration with Excel and don't see anything wrong with creating such a link. I don't think the ability to display a spreadsheet in GH is a bad thing. I also see no point in trying to recreate Excel functionality.

However, I think that Rhino's general stance of openness and acceptance of users software/hardware choices would suggest some sort of alternative if you don't have Excel. The reality of connecting to OpenOffice Calc may make it a mute point, but I don't see much of a reson why reading csv files and interpreting it as spreadsheet data can't be done.

I'm pretty sure that big business loves there being legitimate software options that are out there for free...I think big business likes it when they can take advantage of open source themselves and when it doesn't compete in their markets.

Permalink Reply by Greg S on August 27, 2009 at 11:30pm

Is it important that you can read excel files?
Yes, My prefered exchange format between applications

Is it important that you can write excel files from scratch?
Nice feature, but not all that important.

Is it important that you can add/replace data in existing excel files?
Lower down on the list for me

Is it important that you can tap into a running instance of Excel?
Yes, because the next two are important....

Is it important that Grasshopper responds to changes made to an excel sheet?
Yes, very...would like to be able to read data from grasshopper, then pass thru a formula and display formula results in grasshopper...

Is it important that Grasshopper displays Excel data in its own UI?
It would be very useful to be able to specify a series of cells to report in a panel....not certain of other use cases beyond that.

Permalink Reply by Luis Fraguada on August 28, 2009 at 12:18am

David,
In terms of reading an excel file, I've been using Damien's definitions. For my purposes they worked very well, as Damien provided examples of how to read single cell, a single row, or a range of values. Now, the issue I see with that is if you want to read from more than one sheet, workbook, etc because the solution was to tke the data from an open excel instance. Again for my purposes, this worked quite well, but I understand this might not be the case for everyone.

I suppose the important aspect is how we interact with the data file. I am still not a 100% of what I would suggest here. For instance, how to handle replacing parts of the file, and not the whole thing...I think Damien's strategy of start cell, end cell was starting to get to a solution that might not require a graphic ui...for instance, using a sublist component to select a range...multiple sublist parameters could be used to work on multiple ranges.

I do think it is important that Grasshopper responds to changes made in excel.

Permalink Reply by taz on August 28, 2009 at 6:27pm

If a GH spreadsheet component/GUI were created, wouldn't it just a be a matter of creating one-to-one links between GH and each open excel instance/sheet/workbook? (Similar to how geometry is referenced from Rhino as an application). That would be for active updating.

Reading from and writing to CSV files might be the simplest way to avoid the multiple instance problem for non-active data (if it's actually a problem).

If there is a spreadsheet GUI then the cells for updating (as input or output) could be highlighted graphically and the GUI inputs and outputs could be parametric (like the Merge component).

Say you have 3 columns of data (X, Y, Z coordinates). The input could be referenced as single range for all or as individual columns (from the same sheet). An output connection for each column could be created (3 in this case) and then connect to Point XYZ.

If the X, Y, Z data existed on separate sheets (for whatever reason) there would need to be 3 separate GH spreadsheet GUI instances with 1 input and 1 output.

The GUI could have a locked/unlocked feature similar to the enable/disable solver feature.

Not sure if any of these thoughts are helpful as I may have ventured off-topic a bit...

-taz

Permalink Reply by Roland M on August 28, 2009 at 2:04am

Hi David,

Is it important that you can read excel files?
No
Is it important that you can write excel files from scratch?
No
Is it important that you can add/replace data in existing excel files?
Yes
Is it important that you can tap into a running instance of Excel?
Yes
Is it important that Grasshopper responds to changes made to an excel sheet?
Yes
Is it important that Grasshopper displays Excel data in its own UI?
yes and no I think more that we can show or mirror that data in Rhino for printing up boms etc. This was
requested as a text/dimension feature. Merely to show the excel data as text.

Thanks and can't wait to see what you come up with.
RM

Permalink Reply by Suryansh Chandra on August 28, 2009 at 9:16am

David,

Reading/Writing CSVs is pretty good at the moment with the file parser and the 'stream' option in the 'notes' component. CSV is a fairly open platform open to multiple applications, not being locked to one proprietary software either.

I think watching real-time changes between a running instance of excel and GH instantly responding to it (without having to save the file each time) would be one of the most desirable aspects of it. This could greatly help with generative algorithms where 2 softwares (for instance GH & ecotect) talk to each other via the spreadsheet, continually evolving+ analysing until a certain tolerance is met.

Louis's suggestion of dealing with multiple sets of data/multiple instances of a software is something I would vote for as well. I'd like to add (the wishlist never ends, does it?) that if ur dealing with large amounts of data (which usually is the case... say 2000 rows atleast) it might be useful to select a particular cell in excel and see the corresponding geometry get highlighted in the Rhino viewport. I know that excel exposes this information, but I am not sure if it can be followed all the way through into GH and Rhino.

Cheers Mr. Magician :)