BUG ALERT! problem with fills in AC9

[Anonymous]

Forgive me if this has already been brought up, but I just took a quick look and didn't see anything about it, and neither do I remember reading about it. I guess this must not be happening to too many of you.

An associate of mine and I have both experienced a problem opening AC8.1 projects in AC9. The index number of the "Empty Fill" used for library part masks has been reassigned to a different fill. In my case this resulted in solid fills in the parts' primary pens. In his case it was a hatch pattern of some sort.

Fortunately, if you run into this problem, there is a simple fix:

1. Open Attribute Manager.

2. On the right side open a .pln or .aat with the AC8 defaults (you do
have one of these, of course?).

3. Delete the "Empty Fill" on the left (current project) side.

4. Select the correctly indexed "Empty Fill" on the right and click the overwrite button.

This only fixes this specific problem and may cause another if the overwritten fill is one that you need.

I haven't explored this enough to figure out what is happening, but it seems like a potentially serious bug if it is also affecting other more hidden fill assignments.

Has anyone else had this problem?

[SeaGeoff]

I’ve had some related fill issue come up when migrating to 9 as posted here.

Is there a specific ID the Empty fill should have?

[Aussie John]

Matthew wrote:
The index number of the "Empty Fill" used for library part masks has been reassigned to a different fill.

Thats great
Does that mean I will have to rewrite all my library parts that has an empty fill in it? ( I dont have v9 yet)

[Anonymous]

And this is not the firs tine GS does this.
In fact the Library is the week ling of the program because does not transcends versions and it is constantly tampered with. GS shuld maintain a set of expanded library pars or guarantee that a library part is good forever.

[Anonymous]

Aussie wrote:

Matthew wrote:
The index number of the "Empty Fill" used for library part masks has been reassigned to a different fill.

Thats great
Does that mean I will have to rewrite all my library parts that has an empty fill in it? ( I dont have v9 yet)

I haven't investigated the source of the problem yet. It may be a result of deleting and importing fills repeatedly (which I am wont to do). I will post more as I explore the issue over the next week.

Regarding the library parts: Library parts using index numbers (or users parameters - same thing) for fills regularly have problems.

When I need a mask fill in a library part I call it by name (Empty Fill) to ensure forward compatibility. If you have not been doing this, I recommend revising your parts in any case.

[Aussie John]

Matthew wrote:
When I need a mask fill in a library part I call it by name (Empty Fill) to ensure forward compatibility. If you have not been doing this, I recommend revising your parts in any case.

Thats a great idea Matthew - never occured to me to use the name of the fill rather than the ID number.

Fills changing in library parts has been a bane of mine for years

[Anonymous]

Adalbert wrote:
And this is not the firs tine GS does this.
In fact the Library is the week ling of the program because does not transcends versions and it is constantly tampered with. GS shuld maintain a set of expanded library pars or guarantee that a library part is good forever.

I agree that the libraries, their implementations, and methods of use are getting old and creaky, and are in very serious need of an overhaul.

I was very close (back in 1991-1992) to becoming the first 3rd party library part developer in the US. I decided against it because of the limitations of the environment, the difficulties of maintaining the code, and the limited market to support such an effort. But this is a much larger issue.

Regarding the fills. I have found it very annoying and frustrating that the confusion between names and index numbers has been creating problems for years.

This could be easily fixed if Graphisoft would once and for all just set some number of fixed, standard fill types with reserved index numbers and names. It seems like it would be easy to reserve the numbers from 1 to 100, name a few standard fills (Solid Fill = 1, Empty Fill = 2, etc...) and allow library part developers to assign fills with the confidence that they will always work.