Show which script refers to which file by guid number as name?

[Arend van Waart]

• (Optional) Show which script refers to which file by guid number as name?

Originally posted by @dilomo in #3 (comment)

[Arend van Waart]

@dilomo what do you mean with this?

[Anton Kerezov]

I was thinking that if you have a lot of documents open in VS and you start to loose idea which one is which just by looking at the guid and filename so I was thinking that if we show that complex text we can better get an idea what is linked to what like that:

I'm not sure this would fix things looking complicated tho.

Another approach that came to my mind is just to get rid of the guid labling at all but that is more tricky. Just make sure your script has a unique name and save using that only. If there is a file in the target project folder with same name made by another parasite in the same GH file, ScriptParasite can just give a warning or error that the script was not saved and the user should change the name? Or add the guid in that case and give a warning once. In that context if a script is renamed that should trigger delete old file, create new operation with the new script Nickname?

I think more people might have to say what they think is the best approach?

[Anton Kerezov]

When I started renaming also that happens :)

[Arend van Waart]

I generally sort by date, or give the component a name that makes sense to me. Visual studio will create errors if you have the same component under two names, so I suppose most people will delete duplicates.

Changing the name of the component is not a very grasshopper way to solve things.

I think there are two possible solutions:

• Create an output that gives the filename that is written to
• Modify the message of "Watching" to "Watching Permute-922c2.cs"

[Anton Kerezov]

Okey I think that then depends if you want to have the jagged edge or not as a design decision. I would be ok with both as long as I can see somewhere a confirmation which file I have to open. But ultimately, if you have not time to bother just using as is now is also fine.

[Anton Kerezov]

Actually I found how we can filter out if the nickname is changed and confirmed so we save the new file. On the OnChanged even we should check the GH_ObjectChangedEventArgs and their Type (in out case its NickNameAccepted | 2):
https://developer.rhino3d.com/api/grasshopper/html/T_Grasshopper_Kernel_GH_ObjectEventType.htm
That would not create all those files when typing to change the name.

There is also an event type that says Disabled. Maybe could be useful if we decide to remove the Enabled input and trigger the watch action by enabling or disabling the component.

[Arend van Waart]

Is the main goal here to remove the old file if when you rename a script?

[Anton Kerezov]

I think my example in the picture above was too unclear. So for example if there is a C# component and I want to rename it to ABCD then the script file will be written on each keydown event thus making A.cs, AB.cs, ABC.cs and ABCD.cs. The idea is to write the file when the user finished typing ABCD.

[Arend van Waart]

Ah, check. Good find, that's not really nice.

[Anton Kerezov]

I tried to fix that while coding the double click for explorer but at least for me it causes some kind of infinite loop and frozen Rhino if I exclude the e.NickName type. Have no idea what is happening so better wait for your expertise.

[Arend van Waart]

I've solved this issue in code, I'll try to push the code somewhere this week.

[Anton Kerezov]

I think we just can show the filename instead of guid somewhere in tool-tip or in the output parameter.. doesn't need to be in the message title?