Can I add a truly hidden object to the document?

Probably not and i don’t know what you want to do with the loose object of the desired class. Have in mind that it this is not the way how its meant to be done but you could look here:

Rule of thumb if something isn’t reachable through API it has a reason why it isn’t - and if you will decide to go this path you are on your own since everything what will break program will be your fault - cause of wrong handling it or just because object will do sth what it has to do and you won’t even know what and why and nobody will help since you are just using it in way it’s not meant to be used.

Are you trying to build Skynet inside Rhino?.. Fess up!

Sth ile that is actually very easy - Write command which draws a like - i guess this is default one as an example on start and instead of adding it to doc store it in variable and pass it to conduit if you want to change it just run again command and assign again new line to your variable and that’s it.

1 Like

Skynet was faulty, it got defeated eventually. Mine is better :wink: (though I haven’t watched all the movies only the old ones)

Hmm, I wonder if conduit can be persistent?
Since sticky is not kept between sessions, if the conduit is. I can add a dictionary to the conduit and use it as a storage :wink:

Does it have to be a document object? I have custom data added to my projects where I store the files reference origin that I call back when I need to export to real life coordinates.
Could that work for you?

It might.

what type of data? Where is it stored?

Here is a very simple example of how to store and retrieve custom data:
(You should obviously check to see if a Key exists with the same name etc, but all that is up to you)
It’s called Document UserText and has it’s own panel too and is stored in the Rhino file.

import rhinoscriptsyntax as rs

POINT=rs.GetPoint("Pick a point")
if POINT:
    ### Convert point to string
    POINT=str(POINT)
    ### Store data in file
    rs.SetDocumentData( "MyData", "Point_A", POINT )
    
    ### Read data back out and convert to point
    POINT_A=rs.GetDocumentData("MyData","Point_A")
    print POINT_A
    rs.AddTextDot(POINT_A, rs.coerce3dpoint(POINT_A))

Hi @ivelin.peychev, how would you drag/move an invisible object ? Conduit objects can be dragged but its pretty much code to handle the picking as they exist only in the display so regular selection mechanisms won’t be usable.

In memory and the display.

There is no limit, apart from what your GPU can handle

It depends on your implementation. Conduit can be active only during the scope of the script or even after the script has ended.

You may store it in an ArchivableDictionary and save that so it survives sessions where Rhino is reopened. It is part of your implementation to store and restore the data.

Sticky survives between sessions if rhino is not re-opened. A conduit as well if it is not turned off when opening a new doc. You can pickle the contents of a sticky dictionary, depending on the data types contained.

My advice would be to start simple with commonly used methods :wink:

_
c.

The line is not invisible its parents, the two points are (in this example)
But dragging isn’t really a problem at all. I “disabled” dragging in Rhino a long time ago, I only use drag for control points. And through the gumball of course.

Yeah, I know kangaroo has such a tool, I’d really like to know how it’s done, even though I do not use kangaroo, this particular thing seems very useful.

I guess I’ll have to dig into that more. I created one point but creating the second one simply took over, and at the end I had only one point. (the second one). This is a new territory for me.

I’ll take a look at this. Thanks for the hint. @clement.

Good idea.

Hi, @Holo,

I see you’re storing the coordinates, and a name. I don’t know what the section string is for. It is a nice approach.
The real problem I have with UserStrings in general is that it can contain only strings, that require a lot of conversions.

A database could be quite useful, but as @clement said I should start small.


Thank you all for these valuable hints, now it's up to me to test and pick the appropriate one. :)