Tricks for importing class overrides of viewports from file to file

[schsch]

Hi there,

 

is there a trick or workaround for importing the class-overrides of viewports from file to file?

What I tried without luck:

- eyedropper tool

- converting a viewport into a group in File A and copy that to File B, than I tried to use the eyedropper tool

- make a reference of File A in File B and tried out some class import settings

 

thank you so much for any ideas, scripts or tipps ;9

 

 

ps. im using VW 2017 actually  on Imacs OSX 10.13

[Jim Smith]

@schsch I don't think there is a "cheat". I think this is something that should be added to the programme. Have you Wish listed this?

[Boh]

You could try grouping the viewport, copying & pasting into another file then using the eye dropper. 

 

Edit. Ahh I see you already tried that. 

Edited February 28, 2019 by Boh

[Jim Smith]

@Boh As a work-a-round does this work? I almost never use the clipboard to move stuff from one file to another, I either make a symbol & import, or reference a layer as I know the clipboard from file to file can cause file corruption.

[Boh]

I haven’t done it for a while but pretty sure it works on vw2018. I haven’t come across the clipboard corruption chaos so far...

[PVA - Admin]

Class Overrides can be transferred via the eyedropper tool now, but I think this was added in 2018 or 2019, I can not recall which:

 

And as long as both files are open in the same version of Vectorworks, you should be able to transfer them from one file to another in 2019 SP2 at least. It worked for me here in a quick test.

[Jim Smith]

@Jim Wilson I though I heard this referred to but when I tried it in 2018, I wasn't able to get it to work. Just tried it & it works !

 

Great news!

 

 

Just an FYI do note that the eyedropper doesn't seem to work as well in VW 2019 as it did in 2018, wall heights for example don't get copied from one wall to another.

 

[schsch]

mhh okay, now Im getting closer to it!

- the eydropper option for class overrides exists in VW 2017!

- when you make the windows of both files smaller, you can drop the classoverrides and bring them to the 2. file

- but: There is something with the color-palettes, the colors are wrong in the 2.file

 

I would attach some example files here later and make experiences.

thanks

 

[M5d]

43 minutes ago, schsch said:

- the eydropper option for class overrides exists in VW 2017!

 

And in earlier versions too, but transferring between files never worked. As you've discovered, the class settings would get messed up.

 

I'm pretty sure Viewport Styles, or something akin to that, has been wish-listed a few times.   

Edited March 1, 2019 by M5d

[schsch]

OK the bug is, that VW remembers the color number by the time you selec them. And If you use the eyedropper tool with class overrides, than you get some strange colors in your traget file.

If you use clear files or make an example from scratch, this works.

But if your target file, has some more colors than the source, the colorbumbers are not identical and you get some corruption chaos.

I tried to get a identical color palette in my target file with the "create color chart..." plugin, but the numbers of the colors are different.

I also tried to copy the colors of the target-file back to the source-file and than again to the target, hoping to get identical charts, but this dont work for me.

Does anybody have an idea to replace the colors?

 

I attached some examples: the blue color (Nr 259 still exists in the target-file). I tried to purge and copy the color charts, but at the end, the blue color comes at the end of the color palette and gets number 1383.

 

[Art V]

Are these manually created colours or from an existing standard(ised) colour palette (e.g. Pantone, RAL or in-house created one)?

 

When working across multiple different files (i.e. not multiple copies of the same file containing different options where all colours in the file might be the same) then it would be best to load a base palette with the colours being used in the project when starting a (new) file or to sync it with a master palette in which new colours get added before using the new colour. That should in theory prevent colour number issues as I can imagine that doing this afterwards may not work because the colour definition of the used colour is already in the other file so it may get assigned a different number anyway, but maybe @Jim Wilson can confirm if this is a correct assumption or not.

Edited March 2, 2019 by Art V