Testing a dynamic block gives a different result than instance

[artem.jkl]

Dynamic block.
There are several point options that move my attributes depending on the selection option.
The bases of these parameters and the attributes themselves are clearly located, and their coordinates are correctly entered in the selection table,
which actually confirms by the testing unit.

Now I just insert my block into the drawing - it corresponds to the default state of the block.
However, the selection parameter shows that I have a custom selection (does not match the selection table).
If I change my choice - I will have all the attributes whose point parameters participate in the selection table,
are shifted to the right by a certain distance. The phenomenon does not lend itself to my logic. Is this a bug in AutoCAD? I have AutoCAD 2019.

P.S. the selection parameter shows that I have a custom selection (does not match the selection table)
even in test mode, however everything is displayed there correctly.

[Libbya · Accepted solution]

Yes, that is an excellent example of why I often say that if you are going to use a base point parameter in a dynamic block you should always place it at the origin within block editor and adjust the linework accordingly.

In block editor and in the test block window, the origin within the block is the 0,0 point.  When you insert the block, the base point parameter becomes the 0,0 point and all coordinate points within the block are adjusted accordingly.  As you can see, the bad placement of the base point parameter messes up any lookups that are using coordinate points.  I don't see any reason why you would have the basepoint parameter any place other than the origin except to specifically cause the discrepancy you are seeing.  No it isn't a bug.

[artem.jkl]

In the block there is a size in the scale of linear dimensions equal to 200.
In the block editor and during testing - the size shows the real value times 200.
However, an instance of this block shows the real value times 100.
If at least one size is made anotative — recounting in the instance is now correct — 200. Canceling anotativity does not change anything, all sizes show a value increased by 200. And only if you create a new file and create an instance of the block, the bug repeats.

[Libbya]

I don't know what you did to break the dimensions, but as you say making the block annotative and then turning it back off fixes the values.  I saved the block to a block file and then inserted it and all new insertions display the correct 200 scale value.  I don't know what your process is when you "create a new file and create an instance of the block" but it does not repeat for me.  That tells me that whatever process you are using is what is causing the issue.  

---

---

[Libbya]

In fact, any update to the block definition fixes the issue.  It has nothing to do with the annotative property.  After the new definition is saved it can be inserted and will have the correct dim scale.  Whatever, you did to break the initial block definition... don't do that.  😛

[artem.jkl]

Probably the problem is that if there are a lot of blocks in the drawing with such features, you may not notice this. Especially if you ever hear about it for the first time. And by the way, the dimensions, which will then be printed on paper, can be a lot of problems.

[Libbya]

If you create a block in an inaccurate manner and misplace the base point parameter (as shown in your first block) that can certainly cause problems, but those are problems that you (or whoever made that block) caused and you simply shouldn't do that.  I do not know what caused the dimensions to display incorrectly but I can say with certainty that it is an issue with the block definition.  Again, I have to assume that you caused that issue as well.  I'm not sure what you're looking for other than the advice to do a more precise job when working on your blocks so that you do not cause those issues.  

[artem.jkl]

In general, I suggested that since this is an official forum, then feedback from the developers has be, and you (or not you) as a moderator, make this connection. It is very good that you explained to me the reason for my failures, but the logic suggests that this should not be so, given that the manual gives a very superficial explanation of the key points. Thus, I have to be almost a programmer and pay money for expensive courses in order to learn all the nuances in a short time. In general, it seems to me that the point of the user interface is precisely to remove a bunch of tedious calculations from the user and allow him to concentrate on creativity. Good luck.

[Libbya]

I believe that the information offered on these forums has near zero impact on the development of the software.  Almost all of the forum members here are private individuals who have no connection to Autodesk other than using their programs, myself included.  I am not a moderator, I am not employed in any way by Auotdesk, and I have no input into the development of the program.  The 'issue' you demonstrate in the first block is not a bug.  The issue with the second block might be a bug of some sort, but without a LOT more information from you about how the block definition was broken, the issue could not even be identified.  Even if identified on this forum, I sincerely doubt that the information would find its way to the developers and even if it did, I sincerely doubt it would make it onto even the long list of items to address, much less the short list of things currently being worked on. 

It sounds like you are complaining about the program being complex.  It is complex because it is powerful and has a large number of options.  With those options comes the responsibility of learning how to use them or things go awry.  The added options are a good thing in the long run after you do a decent job of learning the program.  Reducing the options and power of the program in order to assist the unlearned end user from encountering problems is not a step in the right direction.  Good luck to you as well.    

[artem.jkl]

Ok, I agree that the second example was broken in some way. Possibly incorrect version compatibility.

And about complex or not - I do not ask for ready-made solutions, I ask only for working tools. Many manuals, even the official ones, contain two-digit names of tools, and instead of explanations, they simply list the parameters of this tool.

[artem.jkl]

I am already silent about the obvious bugs, which are justified on the forum by the fact that this is a great idea of the developers. Although it seems that this is a clear oversight and mistake. And since it is impossible to contact the developers, this problem has not raised questions for so many years. Everyone says "it has always been this way, this is not a bug."