currently i do some prototyping and as i was lazy writting all those RhinoGets … i used a script component inside gh.
But there is one aspect that killed my work and is not nice at all. it s impossible to save a buggy script.
it would be really important, that the script is first saved before its compiled / executed.
above is a simple example that shows some early project pseudo code i would like to save, even if it s not finished at all.
the workaround is to disable solver …
attached will crash grasshopper / rhino if solver is enabled !! crashingAndLoosingScript.gh (3.0 KB)
sorry - but i have to say, that coding in scripteditor still is far from feeling as fluent as in visual studio. thanks for the next steps in improving it.
@Tom_P I logged the bug but trying to compile of list of steps to replicate the error, I see your script has an infinite loop in it. What are you expecting to happen when opening the GH file? Rhino is gonna get stuck in the loop forever unless you disable GH solver before opening this definition.
My overall expectation are workflows that allow me to save and not loose unfinished, buggy code and fix it (later).
(if this involves an crash of rhino without loosing code - i am fine)
saving before executing
I would love / expect for the “Save button”
to save the script AND the gh file. - without executing.
I am also fine if this button is a save first and then execute button.
As far as i see - the current behavior is to execute but not saving the gh file:
if i open a new gh-definition add some c# script component, insert some code and press above button - nothing is saved from the script.
fixing
As an experienced user i am fine to have a crash of rhino, open grasshopper, disable the solver, oben my .gh file, fix the script component.
for newbies it would be nice to get a more obvious / supported / guided workflow.
I think it would be great if the script component can have a “successful execution” tag on serialization. / writting the file. And if a gh definition is opened / deserialised this flag can be used to disable the solver if there is an issue.
please do not do this. the save button is on the script, so its understandable and expected that it saves the script. if it saved the gh file, that wouldn’t make much sense at all UX-wise and would surprise me as a user.
The legacy script component did not save the GH definition either when “Test” button was clicked. But it has a “Save and Save Definition” in the File menu. I think I can add the “sand and save definition” behaviour as an optional setting.
what exactly happens if i press “save” (script) ?
is something written to disk ?
without saving the definition ?
and if yes (script saved to disk without the hosting definition saved to disk ) - how can i access the saved data ?
do i miss something ?
… for me suggest that the current state is saved, in terms of written to disk…
how should saving a script, without saving the component that is part of the definition take place ?
is there any scenario where you would like to save the script on it s own without saving the definition ? to an extra file ?
The Spaghetti alle Gamberi e Pomodoro are served mixed - you allways get a full, dish, even if you only eat the Gamberi - you pay the full dish. ;-D
The “Save” button in the new editor, acts like the Ok button in the legacy editor. When it is active (there are changes in the script), clicking it applies the script to the component. “Run” button does the same and also runs the definition (like the legacy editor “Test” button).
I can add an option to add “Save GH Definition” behaviour to the save button as well. So optionally saving the script would save the complete definition. Or I can change the “Save” button to “Ok” with a different icon to avoid the confusion.
Dear @eirannejad
and … the Run button will respect breakpoints - the Save button will ignore them.
adding a breakpoint inside my initial s post infinitve loop - the Run button will stop, the Save button will crash / freeze.
my opinion - Save should always apply to component and save the gh definition.
I do not see any workflow that benefits from editing a script but not wanting to save the file.
not sure what other users think. @martinsiegrist ? @Holo ?
Another option would be to write (backup) the content to some kind of cache / backup folder and preserve the code in case of a crash / freeze - before running it.
I am a big fan of a nice best practices / best settings / well choosen behaviour instead of adding options / preferences for every users wish.
And to me it makes NO sense to have that save icon at all, unless it is to export the python script component to an external file for reuse in other python scripts.
Now it appears to do nothing. IMO the script should be embedded in the gh definition and ONLY be saved when I save the GH definition. And I would not expect to see a save icon in the script editor at all. (But I would expect to se an export icon)
Does that make sense? When I clicked the save icon all it did was to “save” the data over to the gh component, but as @Tom_P said, why the heck would I want to open the python component and edit it if I didn’t want to save it? (Unless to open it to copy something out of it, but that isn’t an edit) so my answer is “No, I do not see the need for the save icon.” It should autosave everyting, all the time IMO… I think…
OK, so I have been thinking some more and I see the need for “save” and “run” as two different commands I guess. I have just updated a python script module I made for grasshopper to work on python 3, and when doing so I add more code to the module. And I don’t want that to run in realtime as I type as the code can be slow to execute. So the save makes sense. But I think the run command should not save… (This is where I am at now though, so this might change again).
In my head it makes sense to test the code with run before I choose to save the change. That way if it doesn’t work the way I planned I can just close the script editor and choose “no” to save and have it reverted to last working state without having to redo my changes.
if we are it, can we have a “Edit while Debugging”? It’s annoying if i find the origin of a bug and cannot directly edit it until i have stopped debugging.
