Hi there guys, I have noticed this odd behaviour in ST8
Inside Draft Environment, when you copy-paste a item (views, textboxes, table, dimensions.. anything which can have an style) from one draft to a new one, all the styles associated with that item are inserted inside the new document (if no styles with the same names existe there, of course), in order to preserve its appearance. Until here, all is fine and quite logicall.
However, when you change the style of the inserted items, so that the copied styles are no longer used, there's no way of deleting those styles. They are no longer used by any element, nor they are parents of other styles and so on, but you can't delete them.
The Delete button is gray, even with no object in the whole draft is using that style anymore and no other style depends on it.
As soon as you remove the inserted item, the "pasted" styles can easily be deleted, even when the removed items were no longer linked to those styles anymore! With all, it seems that the pasted item somehow "retains" the link to the styles attached from the original document, and that attachment remains even after updating the style with new ones.
When we update drafts upon new templates, we simply proceed copying and pasting each sheet content, along with some style adjustment (this has been automated through the API). We don't want all legacy styles stored in the new drafts once all the items have been linked to the new styles of the template.
I guess that copy-paste on new templates (at least manually) is quite a common approach when updating drafts, so I guess I won't be the only one experiencing this!
Any info will be really appreciatted! Thanks in advance!
p.s. after further investigation, I have noticed that this only happens depending on the style of the original object on the original draft. More or less, if the object had the first "base" style from the original draft, deleting atyle after pasting fails, but if the object has some more new style it works as expected... it's really an odd behaviour...
Solved! Go to Solution.
After even more research, I think I got closer to the problem.
1-When managing styles, the first style can never be deleted, no matter if any object has it assigned or so. Solidedge needs at least one style, so the first one of the collection can't be deleted, although you have added a bunch after it. Somehow, that style must have some internal "not-deletable" flag.
2-When you copy-paste objects-with-styles from an old draft to a new template, those assigned styles are also copied and pasted, whenever the names don't match those on the new draft. If the names match, no styles are added and the object adopts the style properties on the new template. This is the logical expected behaviour.
3-However, when styles are added, if they were the first style (non-deletable) in the original draft, they retain that property when included in the new draft, so they are not deletable, even when there's no reason for that (they are not the first in the collection). It seems that copy-pasting the style does not update the non-deletable flag from the original scenario, were that style was the boss!
Knowing this, an ugly solution would be duplicating the non-deletable style on original draft and assign it to all objects before copy-paste. This newly created style will have same properties than the first one and will be "deletable" once any object references it.
I have observed this behaviour in table, view, dimension and text style within draft environment. Not sure if it applies to parts and assemblies styles, since copy-pasting there is not so straightforward.
Hope all this info helps someone. If I'm not wrong, I think this could be regarded as a bug on the software. Maybe copy-paste is ugly, but from my knowledge is the ugliest way of updating draft templates!
If anyone could add a bit more of light I would be really pleased.
Thanks in advance and my apologies for the extensive and boring explanation!
Funny you should mention this, there's someone I know trying to delete the initial style from their template- they want to keep them as clean as possible.
I'm struggling to find a way to delete this initial style, despite having deleted everything (including background), reassigned units, dimension and dimension view styles to the point where nothing's pointing to this initial style created with the templte, and still wont let me delete it.
I agree, there's probably some 'Un-deletable' flag that's set to the style when the template is created, you'd think this would clear when another style is used.
I'm going to raise an incident with Siemens for this to see if I can get an answer as I am intrigued, I'll let you know if I hear anything.
Not being able of deleting the "last" style has sense, since you need at least one style to be present in order to create objects with linked style info. However, that "last" style should be any one, as far as is the last one remaining. As an example:
If you add a second Dimension Style to your templates and, after some time, it's the only one used in the drafts, you won't be able to delete the first one, now obsolete. You must always be careful and try to avoid new style creations if not needed, having in mind that there will always be an undeletable one, be it in use or not.
Moreover, when you copy-paste content from one document to a new one, all new styles are inserted on the new document, maintaining the "undeletable flag". If you have not been careful about renaming styles so names match in both documents (as far as you want so, since objects will adopt morphology from the new document style definition), you'll end having more than one undeletable style in the file.
For growing companies, in which draft templates can evolve in short periods, and where, most of the time, a close engineeering management is lacking, so users have too much freedom, this leads to a great amount of documents with different style appearance and different style names. I have found drafts with 3-4 undeletable styles, all of them "naturally" generated from a normal engineering workflow.
Most of the time, average users are not aware of this issue, since there's nothing on SE which warns you about a style being undeletable, so the problem can unwittingly be feed along stylnig evolution.
Also, styling-related tools are quite poor, and logical features expected from a professional tool are missing from the toolset. As an example, a tool such as "replace Style A for Style B on all selected objects, or in ALL objects" should be mandatory. We have tried to develop our own utilities, mostly on drafts, but, along with the effort needed (not truly a problem, is quite fun!) we had to bite the dust due to these bugs, alongside a slightly weak style implementation in the API.
Styling can be a really powerful toolset, with lots of possibilities related to engineering and documentation management, mostly when you are dealing with hundreds or thousands of files. However, a great amount of polishing should be done on the software's styling duties if we have some solid expectations.
From my perspective, having improved synchronous duties on each release while pulling along these deficiencies (quite straightforward to implement) for years drive to an umbalanced result.
Many thanks for all your interest guys.
For those interested, I have managed to do a logical and ugly trick in order to try to work with styles in a not-too-dirty way.
Since I have to copy and paste objects from one draft to another, in order to latter apply the styles found in the destination draft, the best solution is trying to avoid creating new styles, since maybe they will be undeletable later.
Styles are created after pasting if their name is not found in the destination draft, so the trick is renaming style names from the original draft in order to match names found in the destination drafts. This is possible as far as the destination draft has, at least, the same number of styles than the original.
In an schematic way:
1-Find all styles on original draft whose name is not found on destination
2-Rename those styles in original draft using the remainig names on the destination
3-If not enough names in destination to rename, generate "dummy styles" (they will be removed later) on destination, with arbitrary names, and rename with these same names on original.
4-Copy-Paste. Now we can be sure that no new styles have been generated, although, maybe, we have some dummy styles created. But we can delete these for sure!
5-Apply styling on draft, assigning different styles as desired, and being sure that no object remains with the dummy styles generated
6-Delete dummy styles and be happy.
Maybe, one can think that a far simpler solution would be styling all objects on original draft with just one style (whose name would be found in the destination draft) before copying-pasting, so we'll just keep one style in the process.
However, in my app, I must retain all object styling untouched before copy-paste, since I'm not only applying new styles afterwards, but analyzing all user overrided properties of all the elements over their original style and re-applying them again. This is the powerful side of what we are developing.
As an example (fictional names and properties used, just for dramatization :-P):
Original drafts: dimensions have Style1 applied, with Style1 including Arial, 3mm size and Blue color, among all other properties. But in one particular draft, a user changed the color to Red and the size to 5mm in some dimensions, since they are very important from the user perspective. Those dimensions maintain original base style Style1, but with some "personal touch"
New template: dimensions use Style1Updated, with Font Consolas, 2.5mm size and Green color.
When updated, all dimensions get Style1Updated properties, but those wich were edited by the user, get their 5mm size and Red color. All other properties, which match those on the base Style1, are overrided by the values in Style1Updated.
This behaviour is quite powerful, and is working very well updting thousands of drafts, but in order for it to be possible, all styling override must be done AFTER pasting, analyzing first used-defined properties, applying style and re-applying user-defined characteristics.
The whole stuff is done over all type of objects wich could accept an style in a draft and all their properties, so you can have an idea of the coding effort done to date...
Anyway, hope this is fixed some day and we can get rid of the ugly renaming stuff!
Thanks for your interest and time.