Simple plugin creation for door and options

[Thomas W]

Hi,

 

Thanks to the various messages dealing with the subject I have just made my first door plugin with different possible options in the object info panel.

 

For rights issues I can't share the original, so I made a simplified version with the same reasoning. (but only with 2d)

The objective was to group several symbols and options in a plugin and to retrieve all the data in an array, which by the way works rather well!

There are certain conditions in the script to not be able to check certain options if another is or is not checked.

The text that is inserted is modifiable in terms of size and position. We use UUID for each door to be able to make the link between the options / hardware and the door concerned.

 

1- I have a question about the table in which we retrieve the data: In this table that you will find in the attached file, we retrieve the data to order the material and/or the manufacturing. We sort between Choice 1 and Choice 2, then by door by differentiating those which are Left pushing and Right pushing via IsFlipped, the left pushing not being mirrored.

When we sort with a criterion in a column =IsFlipped it works very well, but when we add in the row the criterion with the formula & (PON=ISFLIPPED) the opposite happens, it is visible in the table of the .vwx file and in the attached captures, if someone has an explanation it will be glad! (even if it's still the case and it works it's acceptable...)

 

You will find attached the test file .vwx (in 2023), the .vso and below the script of the simplified version of the plugin, if you have remarks of improvements of the writing of the script or the parameters of the plugin dont hesitate.

 

(Sorry I still can't send script by pasting it in Code function, still error 403)

 

Have a great day,

 

Thomas

 

 

TW 14_PP 60 Simplifié.vso Test Plugin Menuiseries Extérieures 05 Simplifié.vwx

[Thomas W]

Hi,

 

In order for the plug-in to have a unique UUID when it is duplicated or copied and pasted, it will be necessary to activate the update after displacement and rotation in the editing options of the definition of the plug-in, which is not the case in the .vso of the previous post.

 

Have a great day,

[Pat Stanford]

I don't think I understand the problem very well, but PON=ISFLIPPED does not make sense to me.

 

PON I think is an abbreviation for Plugin Object Name while ISFLIPPED is a criteria by itself.

 

So PON=ISFLIPPED would be looking for a plug-in object named either True or False depending on the value of ISFLIPPED.

 

Also, as soon as you duplicate an object that new object should be assigned a new UUID.  Perhaps the easiest way to determine this is to store the UUID in a parameter and then check if the actually UUID matches the stored UUID. If they don't match then store the new UUID and process whatever code you need to link the objects to the new UUID.

 

HTH

[Pat Stanford]

I just came across this document about the criteria system perhaps it will help.

 

https://developer.vectorworks.net/index.php/Search_Criteria_Format

[Thomas W]

Hi,

 

Thanks for your response Pat.

I replaced my inconsistent PON=IsFlipped and PON<>IsFlipped values with IsFlipped=FALSE and IsFlipped, which makes more sense.

But I can't understand why I get the same results with the search criteria below:

 

=DATABASE(NOTINDLVP & (NOTINREFDLVP) & ((PON='TW 14_PP 60 Simplifié') & (PON=ISFLIPPED) & ('TW 14_PP 60 Simplifié'.'ThisSymDef'='PORTE A1')))

same result as:

=DATABASE(NOTINDLVP & (NOTINREFDLVP) & ((PON='TW 14_PP 60 Simplifié') & (ISFLIPPED=FALSE) & ('TW 14_PP 60 Simplifié'.'ThisSymDef'='PORTE A1')))

 

and :

=DATABASE(NOTINREFDLVP & (NOTINDLVP) & ((PON='TW 14_PP 60 Simplifié') & (PON<>ISFLIPPED) & ('TW 14_PP 60 Simplifié'.'ThisSymDef'='PORTE A1')))

same result as:

=DATABASE(NOTINREFDLVP & (NOTINDLVP) & ((PON='TW 14_PP 60 Simplifié') & (ISFLIPPED) & ('TW 14_PP 60 Simplifié'.'ThisSymDef'='PORTE A1')))

 

In any case I will use IsFlipped and/or IsFlipped=FALSE, but it's surprising to have the same results.

 

- For the UUID, I created a text parameter in the Plug-in definition and when executing kResetEventID I tell it to fetch the value with GetObjectUuid and copy it with SetRField, like below:

 

        kResetEventID:    {Reset Event.  This is where you will put your drawing commands}
            BEGIN
                Symbol(pThisSymDef, 0, 0, 0);
                
    { 1.0 SI objHd<>0 Alors copie la valeur de l'identifiant dans le champ 'UUIDobjHd' }        
    IF objHd<>NIL THEN
        BEGIN
            UuidObjHd := GetObjectUuid(objHd);
            { AlrtDialog(Concat('UUID objHd = ', UuidObjHd)); }
            SetRField(objHd, GetName(recHd), 'UUIDobjHd', UuidObjHd);
            ResetObject(objHd);
        END;

 

using from the beginning of the script : result := GetCustomObjectInfo(objName,objHd,recHd,wallHd);

 

- it seems to work well but when you say "then check if the actually UUID matches the stored UUID" do you think it should be checked at the end of the script if the Uuid is still the correct one?

If in the options of definition of the plug-in one updates according to the events, the displacements and the rotations the Uuid should always be single not?

 

Attached is the .vso version with updated events and a new Uuid when duplicating the plug-in.

 

Thanks and have a great day,

 

Thomas

Test Plugin Menuiseries Extérieures 05 Simplifié.vwx TW 14_PP 60 Simplifié.vso

[Pat Stanford]

Glad the correct criteria make more sense. I don't know why the parser even accepted POS=ISFLIPPED.  

Since ISFLIPPED is a boolean, you could also use NOT ISFLIPPED instead of ISFLIPPED=FALSE.

 

I think the check for UUID would have to be done at the beginning of the next reset of the PIO. I don't think the copied object actually exists until after the regeneration completes.

 

@JBenghiat Can you comment on PIO Regeneration and when the new UUID is generated in a duplicated PIO? 

[Thomas W]

Thanks Pat,

 

I will modify IsFlipped and NOT IsFlipped in my search criteria to have a fairer reasoning compared to a boolean.

 

For the UUID since it is copied in the parameter at the beginning of kResetEventID I cannot understand for the moment in which cases it could be different from the real UUID, except if it is not updated.

 

Thank you for your feedback which has already allowed me to move forward.

 

Have a good day

[Pat Stanford]

I don't know the SDK well enough to say for certain, but I do know that using Vectorscript the objects are not actually created in the drawing until AFTER the script completes and the drawing redraws.  If you create a new object inside of a Vectorscript and then try and operate on that object using the handle created inside the script it can fail.

[Thomas W]

Yes I had seen posts about this behavior inside of a Vectorscript.

 

The objective is to use the UUID to make the link between the base symbol chosen in the plug-in and all the possible options that we will add to know which options concern which symbols.

 

But I found some posts that are not very reassuring about the "use of UUID like this one :

 

 

Although if the UUID changes and the link is the same our quantities will remain the same.... to test!

 

 

[Thomas W]

Hi,

 

I did some tests to see if the UUID values of the plugins changed between my session yesterday and today, from what I see it doesn't.

After removing a few plugins and then recalculating the array containing the UUID values, the values remain the same as yesterday apart from the removed ones.

 

I also tried by opening the file on a colleague's workstation, then recalculating the table the values of the UUIDs were the same, it was already to see if these values changed from one session to another and to one position to another.

 

But even if these UUIDs change, it would not be inconvenient for our use because the link between the main element of the plug-in and the checked options remains the same and the codes which serve us as hardware references are written manually in the table .

 

I will continue my tests and have a great day!

 

[Pat Stanford]

The UUID should not change between sessions. That is the point of the UUID. It is created with the object and remains the same for the life of the object.

 

I have not tested and do not know if the UUID is supposed to unique across all files or just within a given file. So I don't know what happens if you duplicate a file. I would assume that the "same" objects in both files will have the same UUID. But if you copied the object and pasted it into the other file it would get a new UUID so there would never be a duplicate in the same file.

 

And yes, tracking linked objects with UUIDs can be a pain.  You really need to store both the current and the previous UUID. If the current does not match the previous then locate all the items that are linked to the previous UUID and update them to the current.

 

I have something that I am working on that is doing something similar, but I am trying to see if I can come up with a simpler way.

[JBenghiat]

3 hours ago, Pat Stanford said:

I have not tested and do not know if the UUID is supposed to unique across all files or just within a given file. So I don't know what happens if you duplicate a file. I would assume that the "same" objects in both files will have the same UUID. But if you copied the object and pasted it into the other file it would get a new UUID so there would never be a duplicate in the same file.

 

This is correct. The UUID stays with the object. If you are storing the UUID to a parameter, the object's UUID and the parameter will only mismatch if the object has been duplicated, in which case the object should handle the duplication accordingly. (So if you save as, the UUID will be the same, but if you copy and paste or import layers, they will be different). 

[Pat Stanford]

Thanks for the confirmation Joshua.

[Thomas W]

Thank you very much @Pat Stanford and @JBenghiat for your remarks, they made me look elsewhere and I notice that this work of linking with objects and UUIDs is not easy or painful!

 

The UUIDs are therefore not really unique in certain cases, which I have seen:

 

1- If we duplicate a .vwx file, the UUIDs are the same in the 2 files, the UUID stays with the object.

2- If we duplicate a layer in the same file, the UUIDs will be the same on the 2 layers, as long as there is no Reset Event.

3- If we duplicate a plug in on the same layer with Ctrl + D or Edit/ Duplicate the 2 superimposed elements will have the same UUID (as long as the plug in is not recalculated), there may therefore be duplicates of UUID in the same file.

 

I tried other functions like 'vsoStateGetParamChng( objHd, outChangeID, outPrmIndex, outOldValue)' which I was able to get to work but it won't help me in this case since it shows us if the user has changed a parameter of a widget but not if a parameter of the plugin is no longer correct, such as the UUID.

 

@Pat Stanford : Following your message I created 2 fields to store the current UUID and the previous one, but I can't find the right reasoning to make it all work. At the beginning of kResetEventID { 3 } I look for the UUID value to copy it to the plugin parameter field:

 

kResetEventID { 3 }:    {Reset Event.  This is where you will put your drawing commands}
            BEGIN
                Symbol(pThisSymDef, 0, 0, 0);   

    { IF ObjHd<>0 then copy the UUID of the plug-in object into the parameter 'UuidObjHd_00 }            
    IF objHd<>NIL THEN
        BEGIN
            UuidObjHd_00 := GetObjectUuid(objHd);
            AlrtDialog(Concat('IF objHd<>NIL THEN :', CR, 'UUIDobjHd_00 = ', UuidObjHd_00));
            SetRField(objHd, GetName(recHd), 'UuidObjHd_00', UuidObjHd_00);
            ResetObject(objHd);
        END;

 

Then to copy the value in the previous UUID and so that it is not copied every time I tried:

 

{ If the plug-in has just been created then copy the value of UuidObjHd_00 into the parameter UuidObjHd_01}    
            IF vsoStateGet(objHd, kCreatedReset) THEN
                BEGIN
                    AlrtDialog(Concat('IF kCreatedReset THEN :', CR, 'UuidObjHd_01 = ', pUuidObjHd_01));
                    SetRField(objHd, GetName(recHd), 'UuidObjHd_01', UuidObjHd_00);
                    ResetObject(objHd);
                END;

 

It works but I don't see how to keep the values of the 2 current and previous UUIDs up to date, nor when to compare them?

Since we copy the value of the current UUID at the beginning of kResetEventID we can't compare it before?

 

If you have any advice on how to do the uuid comparison or another solution or advice it will be appreciated...

 

Thank you and good day!

[Pat Stanford]

I don't (typically) do Event Enabled scripts, so I can't really help with which events you will need to use.

Here is an outline (from memory, I don't have time to check the code for exactly what I did) of how I used UUIDs to make "linked" objects.

 

In the "primary" object I had a field to store the UUID. The "secondary" objects stored the UUID of the primary object they were linked to.

 

When the PIO ran, it would get its current UUID and compare that to the stored UUID. If they did not match, then I knew the object had been changed (duplicated, copied/pasted, etc.).  I could then search for "secondary" objects that had the old UUID stored and update their records to the new UUID to link those objects to the new UUID. I then stored the new UUID in the UUID field so I could check it against the current UUID the next time the object updated.

 

This relatively simple system was sufficient for my needs. I didn't care if someone deleted the primary and left orphan secondary objects. If you do care about that you should be able to use the Association functions to make an association between your objects that will cause them to delete (or regenerate) when the "primary" object is deleted.

 

HTH.  Ask more if you still need more help.

[JBenghiat]

13 hours ago, Thomas W said:

The UUIDs are therefore not really unique in certain cases, which I have seen:

 

1- If we duplicate a .vwx file, the UUIDs are the same in the 2 files, the UUID stays with the object.

2- If we duplicate a layer in the same file, the UUIDs will be the same on the 2 layers, as long as there is no Reset Event.

3- If we duplicate a plug in on the same layer with Ctrl + D or Edit/ Duplicate the 2 superimposed elements will have the same UUID (as long as the plug in is not recalculated), there may therefore be duplicates of UUID in the same file.

 

Just time for a quick reply at the moment, but...

#1 — correct. I think this is preferred behavior — if you save a new version of the file, or revert to a backup, you do not want all your UUID's resetting. If you copy/paste to another file, then they do indeed reset.

#2 & #3 — this is incorrect. As soon as you duplicate an object, including duplicating it's container, the UUID of the copy regenerates. If you call GetObjectUuid() from an external script, you would see that. You should construct your code to read the UUID's directly, rather than from the parameter. The parameter is only useful for an object to know if it has been duplicated — if the current UUID and stored UUID do not match, then it is a copy, and resend accordingly.

[Pat Stanford]

I think #3 may be an artifact of how you tested.  I believe that when you make a duplicate of an object, it is actually the original object that remains selected (or if you have Offset Duplication turned on the object that is offset) so if you check the selected object that to your mind is the duplicate, it will have the UUID of the original object. If you check both objects (original and duplicate) they will have different UUIDs.

 

#2 may have a similar cause, but I have not checked to see if the original layer is the one renamed or the duplicate layer is renamed and has the new objects.

 

Also, I believe that the last line in Josh's message should be reset, not resend.

[Thomas W]

Thank you for your answers and comments that allowed me to move forward!

 

@Pat Stanford After your explanation I understand that I am not using the same reasoning as in your example, I am not using "primary" object and "secondary" object, I was looking to compare 2 parameters in my plugin, as on the attached screenshot. I will look for the Uuid with an external script, it will be fairer and avoid checks.

 

@JBenghiat

I think my main mistake was reading the Uuid that was stored inside the plugin, so sometimes it showed a value that was not updating.

 

By using GetObjectUuid() with a script from outside the plugin I was able to verify that the points below were wrong:

Quote

2- If we duplicate a layer in the same file, the UUIDs will be the same on the 2 layers, as long as there is no Reset Event.

3- If we duplicate a plug in on the same layer with Ctrl + D or Edit/ Duplicate the 2 superimposed elements will have the same UUID (as long as the plug in is not recalculated), there may therefore be duplicates of UUID in the same file.

In the 2 cases above the Uuids are well regenerated!

 

I will try to retrieve the Uuids we need directly from the table that will be used to retrieve and sort the quantities.

 

A response from @michaelk in the post below should get me there!

 

Quote

 

 

Thank you again for your answers which helped me a lot!

 

Have a great day