Dieter @ DWorks

Case Item of SetupDialogC: GetTBdialog1Events; 01 : GetTBdialog1Events; Here you state then on the 12255 event and on 1, you execute the GetTBdialog1Events procedure, so this means that on init/setup (12255), you will run it, and on 1. That's why you see it happen twice. The setup isn't there for getting values, but for further setup of your controls. Some controls require you to set the values there instead of while building the dialog, other functions only work here etc.... PS: Can you please use the code tags? It's easier to read.

Umm, I thought that from now on VW would be updated regularly? Or is this still something you guys wish to go to in the future? It defenetely has been talked about.

FUNCTION filler(): should be PROCEDURE filler; , as it doesn't return anything. When an error occurs, you always get a long list of errors, but you have to solve them in the order they are given, because lower errors are mostly because of errors happening before it. So fixing the first could be solving all the others.

You use GetTBdialog1Events for 12255 and 1.

12255 is the SetupDialogC case, and is always done first before the dialog is actually shown. and for 12255 and 1, you have the same function, that's why you see twice the same dialog....

Sorry if I sounded harsh, it wasn't meant that way. I never said that Marionette couldn't be used in it's current version. I just stated what I felt about it, only knowing what I read on these forums.

True, but I hate it when my IDE tells me otherwise... (One of the reasons of my Parameters class, to not have to think about this.)

Do you mean that when you hover over the custom point object, or another object that's not your plugin? Or do you mean one of the objects in your plugin? What exactly do you need to do? I get the impression it's not an custom object you need.

I don't mind that tools aren't finished yet, but the basics need to be there, which means it needs to be fully usable, with just a few options, nothing more. Then you can enhance it. From my experience as a software engineer, I know that adding a versioning system now will be very hard.... Imho, working agile works, but it needs to be done right.

Can you paste the script error you get? I typed this out of my head, probably some syntax error.... I don't use this that often.

When using Python for your plugin, you could use DLibrary to easily create dialogs and work with them very very easily. All you need to do is define a dialog through an xml file: (All data- attributes are automatically binded to the ViewModel properties, so no need anymore to call getters and setters on dialog controls, no need to set controls up, no need to play with placements, .... All is done with this one file, while your values will live in the viewmodel!) MODULES data-items="modules" data-value="excerpt" height="25" width="50" data-selected-items="selected_modules"/> GESELECTEERDE MODULES data-items="selected_modules" data-value="config" data-available-items="available_configs"/> And you can use it like this: class ModuleDialogXmlFile(AbstractActivePlugInDialogXmlFile): def __init__(self): super().__init__('Module', ActivePlugInType.OBJECT) class ModuleViewModel(object): # The ViewModel class for a Module item .... class ModuleDialogViewModel(object): # The ViewModel class for the dialog. .... def on_module_dialog(): # Get the plugin parameters. parameters = Parameters() # Create the dialog viewmodel, which will hold the data. dialog_view_model = ModuleDialogViewModel(parameters.module_config) # Run the dialog (from the file with the viewmodel) if Dialog(ModuleDialogXmlFile(), dialog_view_model).show(): # When the user hits ok, save the modules to the plugin parameters. parameters.module_config = [module.config.value for module in dialog_view_model.modules]

It should work. All the things you draw in your plugin will be drawn in the class of the plugin by default, and will get the attributes of what is on the attributes palette when your plugin object is selected. If it doesn't work, then I think you have set the active class in your plugin, which you should not be doing, or the object isn't drawn for some reason. Is this a rectangle based plugin? Can you post the whole code so we can have a look on what's going wrong?

That's not entirely true....

I guess you want to set the fill for all the objects in your search criteria? Then you could do the following: FUNCTION filler(): FUNCTION fillObj(h: HANDLE): BOOLEAN; BEGIN SetFPat(h, 1); SetFillBack(h, 1236); END; BEGIN ForEachObject(fillObj,'(INSYMBOL & INOBJECT & INVIEWPORT & (FP=3))'); END; RUN(filler); It's better to not play with the selection, as this can confuse users, as after your script, the selection will be changed....

I really wonder why this wasn't seen as one of the basic feature that really needs to be there? We all know that Marionette has been developed untill the end, even changed a lot at the end too.... I guess it had to be rushed in the end? Ow, and this may be personal, but the gradient of the nodes really is looking bad, and sometimes makes the texts not very readable....

If the rectangle is drawn within your pio, then you just apply attributes through the attributes palette when the object is selected.

Well, the example was an example when using DLibrary, which is kind of a wrapper for vs, to make it easier to script plugins.

Hi, this is done in Python by getattr(vs, 'PLineLength') You could use DLibrary to make it easier to work with: DLibrary - Vectorworks. Inherit from the AbstractActivePlugInParameters class to access your parameters, and save them back like this: # Your parameters contained in a class, so you can add extra checks and convertions. class MyParameters(AbstractActivePlugInParameters): P_LENGTH = 'LineLength' @property def length(self) -> float: return self._get_parameter(self.P_LENGTH) @length.setter def length(self, value: float): self._set_parameter(self.P_LENGTH, value) # Your run block, one of the places where you can use your parameters. def run(): # Create an instance of your parameters class for the current execution of the current active plugin. parameters = MyParameters() # Get the length parameter. (LineLength) length = parameters.length # some other stuff you need to do # the length parameter can even change due to a dialog setting etc... # Set the length parameter. parameters.length = length One of the main reasons for the parameters class is that you can put all checks/conversions and other parameter value related stuff in there. Then the code that just works with the values don't have to bother. If you want we can see to add examples to DLibrary to explain more how to work with it and do things in Python. I don't have lots of time, but I'm trying hard to get enough in it so others can build plugins faster, and I know examples are missing, but they are coming. All can contribute! NOTE: Off course I could have chosen to let the base parameters class add the existing parameters as properties, but then the IDE will not pick them up. Also, now you can choose which parameters you want to get/set for the rest of your code. So you could have a read-only parameter for your code because you will never set it through code for example.

So you want to merge two totally different things then. Not possible. - The object is an object with parameters, that's one thing. - The menu command is just there to place those symbols, nothing else. It's better to keep those separate, as they don't have anything to do with each other.

What do you mean convert symbols to custom plug-in objects? They are totally different. Do you have a use case? I think you are looking for a custom object instead of a menu command, one that will use a symbol in it. Please tell us your use case so we can come with good solutions.

It's better not to use vs functions that can be done by Python. Only use vs functions for VW related stuff.

Nothing wrong with the duplicate names if you use prefixes for your resources. I Always use [XX], where XX depends on the kind of resource, like [WS] (wall style) [sB] (symbol), [TT] (texture), .... This also makes it easier to see what each is when you are viewing them as a list of names.

Ciao Tui, I am surprised and glad you liked the List Browser article! You can't imagine what a joy you give me. I never had any feedback but from a handful of dear friends with whom I discussed some parts of the article and I thought of being not only the author, but also the only 'reader'. Yes, deciphering List Browsers in total absence of documentation was for me like archeology and cryptology in one. No worry, I am now updating the wiki, which should be running back soon. I also had a great help from that article! List browsers are difficult at first, so it was really helpfull to have your article to figure them out! Really thanks for it!

Lol, it doesn't do anything.... as paramName isn't used anywhere further in the script. So it can be removed. The example scripts aren't all that great you know. I get the feeling they were made by people that are just starting out with Python.

I also would like it back, as I was just looking for info about the color stuff to implement in DLibrary....