Topic: Demonstrable Bugs and Deficiencies List ( AutoCAD )

[Kerry]

< .. > I have a few emails twixt myself and an autodesk employee, whom will not admit there is a problem with < ... >

Perhaps it's time to go a little higher up the ladder with the problem.

[Keith™]

I can understand how "demonstrable and reproducable" come into play. Being a developer myself, I have had the occasion to come upon some really strange occurences that are generally referred to as bugs that I would like to *think* were not due to the steps necessary to reproduce them.

In one instance I was given specific instructions about how to reproduce a bug. I followed the steps and voila, the bug indeed was shown to exist ... the problem was that the bug was caused by a user attempting to do something the program was never designed to do. In this particular case, the user was trying to open a filetype with binary null characters where they shouldn't be. In otherwords ... the file they were trying to open would NEVER exist as it must to cause the bug. In the end, I fixed the code so it would not crash when opening a file with binary null characters, but this leads me to the point that users will come up with the most creative and unimaginable methods to break a piece of software. It is those things that the development team never considered a user would try. Those things are impossible to prevent.

[Kerry]

< .. > It is those things that the development team never considered a user would try. Those things are impossible to prevent.

I agree,
Thats why knowing HOW (demonstrably) the user produced the error is important ... so he can be told "that's naughty"

[sinc]

From what I've seen, that phenomenon of Autocad "locking up" isn't really Autocad "locking up".  It's just got itself stuck in some intense calculation loop, and it's ignoring ESC.  Or it's doing something on the network that it shouldn't, and dragging its heels because of that.  If left alone, it usually finishes what it's doing, eventually.  But it can take long enough that the user's patience runs out first, because there's no way of knowing if it really will ever finish what it's doing, or how long it will take.

On better hardware, it's easier to let it run and wait for it to finish.  Having maximum RAM and fast disk drives helps a lot.

[sinc]

In this particular case, the user was trying to open a filetype with binary null characters where they shouldn't be. In otherwords ... the file they were trying to open would NEVER exist as it must to cause the bug. In the end, I fixed the code so it would not crash when opening a file with binary null characters, but this leads me to the point that users will come up with the most creative and unimaginable methods to break a piece of software. It is those things that the development team never considered a user would try. Those things are impossible to prevent.

I wouldn't consider that example something out-of-line, and would count it as a valid bug.

It is very easy for a user to accidentally click on the wrong file.  I would hazard that a program should not crash simply because the user accidentally clicked on the wrong file, but should be able to detect a problem reading the file, and handle it gracefully.

[Keith™]

Except that the files in that particular program were generated automatically ... the program does not write null characters, in fact it explicitly filtered them out prior to writing the file.

The rough steps to recreate were:
Run the program on a set of data, with the program still open, minimize and browse to the temp file in the temp folder, open the temp file in a binary editor, change some values to null "00", save the file. Restore original application window, select the edited file name from a list of files in the listbox, click process and the program generates a runtime error.

Runtime error was due to an invalid data segment ... when importing data as strings, it is generally treated as terminated when null is found (i.e. null terminated string) .. the data segment thus was not filled as it should have been, thus an operation on the data could not be performed, and then you have the cascading effect of a failure. Incidently the temp file is deleted automatically when the program closes. So, the error was not demonstable so far as a programmatic error, it was demonstrable so far as user error.

It is akin to someone changing the header value in a DWG file to reflect an earlier(or later) version, then wondering why AutoCAD crashes when it tries to open it ... DUMMY .. DON'T EDIT THE DWG FILES WITH A BINARY EDITOR (or text for that matter)

Incidently, I think for it to be considered a bug, it must be more than demonstrable and reproducable .. I think it must also happen in the course of using the software in the manner one should reasonably expect it to operate.

[Josh Nieman]

From what I've seen, that phenomenon of Autocad "locking up" isn't really Autocad "locking up".  It's just got itself stuck in some intense calculation loop, and it's ignoring ESC.  Or it's doing something on the network that it shouldn't, and dragging its heels because of that.  If left alone, it usually finishes what it's doing, eventually.

I don't buy it because I've deliberately left a drawing open while "locked up" over the entire weekend, worked on a different computer, and came back monday to find no change in state.

That's a bug, sorry.

[Josh Nieman]

Bug:

Helix Command

Doesn't actually draw a true helix.

Draw a helix and measure the points from mid, end, quadrant... to center point.  Should always be 1/2 what you entered for diameter.  Consistently displays a value less than it should.

In plan view, the helical turns should appear as a circle, but actually display consistently inaccurately place revolutions, usually slightly shifting to the positive X direction, though I haven't checked if that's always the direction, but every helix I've drawn has been slanted, like the Tower of Pisa, for example.

[Josh Nieman]

Bug:  (status as 'bug' may be debatable, but I see it as such)

When editing table cells, when you have a cell selected but not active to content editing... you cannot double-click to activate the cell.  One would have to hit 'esc' to deselect the table in it's entirety, then double click the cell.  This behavior seems to be undesirable given the purpose of the double click's purpose.

[mjfarrell]

Bug:

Helix Command

Doesn't actually draw a true helix.

Draw a helix and measure the points from mid, end, quadrant... to center point.  Should always be 1/2 what you entered for diameter.  Consistently displays a value less than it should.

In plan view, the helical turns should appear as a circle, but actually display consistently inaccurately place revolutions, usually slightly shifting to the positive X direction, though I haven't checked if that's always the direction, but every helix I've drawn has been slanted, like the Tower of Pisa, for example.

Try drawing them slower; you are inducing distortion due to torque spin of the helix. If you draw them any faster they will fly apart on you entirely.

[Josh Nieman]

Bug:

Helix Command

Try drawing them slower; you are inducing distortion due to torque spin of the helix. If you draw them any faster they will fly apart on you entirely.

 

[Kate M]

Bug:  (status as 'bug' may be debatable, but I see it as such)

When editing table cells, when you have a cell selected but not active to content editing... you cannot double-click to activate the cell.  One would have to hit 'esc' to deselect the table in it's entirety, then double click the cell.  This behavior seems to be undesirable given the purpose of the double click's purpose.

I can...what version? You can also just start typing if you want to overwrite the cell's contents.

[Josh Nieman]

Bug:  (status as 'bug' may be debatable, but I see it as such)

When editing table cells, when you have a cell selected but not active to content editing... you cannot double-click to activate the cell.  One would have to hit 'esc' to deselect the table in it's entirety, then double click the cell.  This behavior seems to be undesirable given the purpose of the double click's purpose.

I can...what version? You can also just start typing if you want to overwrite the cell's contents.

It's been happening for me since 2006 at least.

Let me make sure I'm clear:

1) Select table cell so that only one cell is active.  It will have the 4 grips at midpoint of each side, and the highlighted perimeter.
2)  Double click inside the cell.

3?)  It returns the following for me:

Code: [Select]

Command: Specify opposite corner:
Invalid window specification.

Command: Specify opposite corner:

[FengK]

Great idea, Kerry! Hopefully some of the bugs we came up do get fixed in the near future. This is a demonstrable and reproducible bug: http://www.theswamp.org/index.php?topic=22142.msg266998#msg266998. I'm really upset about this because we have a 600+ sheets project that use lots of fields in attributes. Based on the fact this bug hasn't been reported (guessing) / fixed, I'm guessing either not that many people are using SSM, or they don't set attributes' width factor to values other than 1 (Kerry found out this bug only happens when attribute width factor is not set to 1) , or they don't feel like reporting bugs to Autodesk for whatever reasons...

[Kate M]

Let me make sure I'm clear:

1) Select table cell so that only one cell is active.  It will have the 4 grips at midpoint of each side, and the highlighted perimeter.
2)  Double click inside the cell.

3?)  It returns the following for me:

Code: [Select]

Command: Specify opposite corner:
Invalid window specification.

Command: Specify opposite corner:

It puts me into the cell. I'm running 2009, OOTB, and don't have any other versions I can test at the moment. Have you customized any double-click actions?