search

arendvw / ScriptParasite

A component that allows editting of C# definitions in external editors
19 stars 5 forks source link

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

Open arendvw opened 3 years ago

arendvw commented 3 years ago

Originally posted by @dilomo in https://github.com/arendvw/ScriptParasite/issues/3#issuecomment-901016425

arendvw commented 3 years ago

@dilomo what do you mean with this?

dilomo commented 3 years ago

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: image 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?

dilomo commented 3 years ago

When I started renaming also that happens :) image

arendvw commented 3 years ago

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:

dilomo commented 2 years ago

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.

dilomo commented 2 years ago

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.

arendvw commented 2 years ago

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

dilomo commented 2 years ago

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.

arendvw commented 2 years ago

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

dilomo commented 2 years ago

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.

arendvw commented 2 years ago

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

dilomo commented 2 years ago

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?