spreadsheet module eivindkvedalen C++

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Post Reply
User avatar
yorik
Founder
Posts: 13665
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: spreadsheet module eivindkvedalen C++

Post by yorik »

eivindkvedalen wrote:This isn't implemented, because there's really no such think as a subproperty in C++, compared to Python. I'd really like to have such an implementation, but I'm not sure how to accomplish it in a nice way. One alternative may be to access the values through the Python-counterparts
This has been used here and there throughout freecad already...
eivindkvedalen wrote:This module will most likely break compatibility with Yorik's implementation
I think we can safely do that. My python version was more a proof of concept that anything else... Now we have the opportunity to think things more carefully.
User avatar
saso
Veteran
Posts: 1924
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: spreadsheet module eivindkvedalen C++

Post by saso »

yorik wrote:
eivindkvedalen wrote:This module will most likely break compatibility with Yorik's implementation
I think we can safely do that. My python version was more a proof of concept that anything else... Now we have the opportunity to think things more carefully.
Fully agree with yorik and is also why I think it would be good to get it in the master soon so more people can play with it and share their views and ideas on what and how they would like to have.
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: spreadsheet module eivindkvedalen C++

Post by eivindkvedalen »

yorik wrote:
eivindkvedalen wrote:This isn't implemented, because there's really no such think as a subproperty in C++, compared to Python. I'd really like to have such an implementation, but I'm not sure how to accomplish it in a nice way. One alternative may be to access the values through the Python-counterparts
This has been used here and there throughout freecad already...
Do you know of an example? I'm currently browsing the code tree for such a thing...
yorik wrote: I think we can safely do that. My python version was more a proof of concept that anything else... Now we have the opportunity to think things more carefully.
Good! :)

Eivind
User avatar
yorik
Founder
Posts: 13665
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: spreadsheet module eivindkvedalen C++

Post by yorik »

eivindkvedalen wrote:Do you know of an example? I'm currently browsing the code tree for such a thing...
No unfortunately. I just remember I saw that a couple of times... I'll see if I can find one
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: spreadsheet module eivindkvedalen C++

Post by jmaustpc »

Just a thought....would it make sense to have a start/end symbol of some sort that tells spreadsheet hat all between is a "property reference"? For example something like the current "=" means start formula or "/*" and "*/" start and end comments in C++.
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: spreadsheet module eivindkvedalen C++

Post by jmaustpc »

regarding the property controller, .... I have not been able to think of a tidy way to implement this at all, but I was wondering if we could in some way drive these from the property themselves?

For example some of the ideas I mulled over,
1) have a tick box "from spreadsheet" next to all property value boxes, then if ticked the value would be read only like the current PartDesign placement properties, then we would need some sort of pop down box, or something else, to enter a cell address.
2) do something along the lines of extending the current Units system so that you could just enter a cell reference directly into the input box. But then we would have to display the values some how......

regarding multiple spreadsheets....currently you can create more than on spreadsheets in one FreeCAD project file....I think we need to remember this as we design anything, (e.g. the property controller), and make sure we make allowance for this scenario. For example presumably a property controller would require a "spreadsheet name" value along with each spreadsheet cell reference.


regarding Label/names for shapes
eivindkvedalen wrote: jmaustpc wrote:I see why it would not work for me earlier, it looks at the name not the label, I should have thought of that. I had a default Part Cube, hence "Box" no "Cube". :)



Hmm. I thought I had a check for both name and label...
Just a thought since labels can be anything, checking for both might be potentially problematic,
for example
1) a "label" for one shape could be the same as a "name" for another shape. This might not be obvious to a user if the labels have been edited in the GUI.

2) if "allow duplicate Labels" preference has been enabled in the FreeCAD preferences, then the document could have multiple items with the same label. Hence a reference to a label would not know which item to read. Of course, conversely this could be a part of a method to reference multiple objects, but that would be untidy.


Jim
User avatar
yorik
Founder
Posts: 13665
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: spreadsheet module eivindkvedalen C++

Post by yorik »

Just a thing we need to remember, the whole features tree of freecad is something carefully designed to avoid cross-references and loops. The spreadsheet is a dangerous tool in that regard, we already had that discussion before. So we need to take great care with that stuff, in order to avoid short circuits.

Gathering (reading) object properties is safe. Modifying them, that's another story, I'm not convinced at all that the thing I did in the current python spreadsheet is a very good way.
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: spreadsheet module eivindkvedalen C++

Post by eivindkvedalen »

yorik wrote:
eivindkvedalen wrote:Do you know of an example? I'm currently browsing the code tree for such a thing...
No unfortunately. I just remember I saw that a couple of times... I'll see if I can find one
I think I've found a way to do this now.

Eivind
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: spreadsheet module eivindkvedalen C++

Post by eivindkvedalen »

jmaustpc wrote:Just a thought....would it make sense to have a start/end symbol of some sort that tells spreadsheet hat all between is a "property reference"? For example something like the current "=" means start formula or "/*" and "*/" start and end comments in C++.
I think it should be like it is today, but the parser needs to understand and interpret multilevel properties, where each term either is a single variable ("var"), a list entry ("var[index]") or a map ("var['name']" or maybe var{name}). This must be a very strict syntax, so there's no way to sneak any code into it.

Eivind
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: spreadsheet module eivindkvedalen C++

Post by eivindkvedalen »

yorik wrote:Just a thing we need to remember, the whole features tree of freecad is something carefully designed to avoid cross-references and loops. The spreadsheet is a dangerous tool in that regard, we already had that discussion before. So we need to take great care with that stuff, in order to avoid short circuits.

Gathering (reading) object properties is safe. Modifying them, that's another story, I'm not convinced at all that the thing I did in the current python spreadsheet is a very good way.
This is already handled at least for reading now, which is the only thing the spreadsheet document object can do. My current PropertyController contains a separate field for the target object, so I think that will also eventually be ok.

However, what that means, is that you cannot e.g read Pad.Length in a sheet, and then use a property controller to set Pad.Length2 to a value based on Pad.Length; that will create a circle in the FreeCAD dependecy graph, even if on property level there is no dependency, because the dependency graph is done at the document object level.

Eivind
Post Reply