topic Re: Issues with Tables - 2015 in AutoCAD Forum

Issues with Tables - 2015

llorden4 — Fri, 20 Mar 2015 21:03:24 GMT

I've got a formatting issue I'm having a bear of a time running down and am reaching out for help, the issue being a total corruption of the Table settings even though the table settings are not changing in the Table Dialog menu. By this I mean that even though the numbers displayed in the TABLE STYLE dialog box are not changing, I am getting completely different and un-correctable results in display. I would typically run into this issue on occassion when copying a table from one drawing and pasting into another. I want to also make it clear that these are Autocad tables and not Excel tables pasted into the Autocad drawings. I've implemented a new LISP routine for some drawing automation that is now causing all tables to become corrupt, but there's not obvious system manipulation that you would think would cause this effect, but it does occur 100% of the time immediatly after running this routine. I know you're focus is going to go to he routine, so let's start there right after I show the visuals on what the affects are...

Example table before the corruption:

and after the corruption all the tables grow by roughly 20 times (the list goes down and down and down beyond the screen capture), though the overall width of the table remains the same. It looks to me as though the text is growing and the table is adapating to the larger text size.

In checking the properties of the tables before and after, text height is 3/32" before the corruption, and 2" after the corruption. Creating a new table causes the same issues, even though the table rules defined do not match. Editing existing tables that were not affected cause the explosion in text size to all fields of that table being edited.

Getting back to the LISP routine, it does utilize a .DCL file to create a dialog box and the routine does read/store some current system variables, alter them, and then return to their original values. The system variables do include: OSMODE, CLAYER, LUNITS, LUPREC, DIMSCALE, TEXTSIZE, TEXTSTYLE, and QAFLAGS. Both the DCL and LISP run clean and exit without errors, and as a reminder, the system variables utilized are restored to pre-run values upon exit. The routines do not edit the tables in any fashion nor are they ever selected, nor are new tables generated. Also as a reminder, this has occassionally occured prior to my even developing this routine, I can now just regularly repeat the issue.

Enough back story, on to the main question I'm searching an answer for... What can cause the change in format to an existing table in the maner I've described? Certainly my first thought is the alteration of TEXTSIZE and/or TEXTSTYLE but after confirming these values are restored, I can't figure the continued incorrect sizes of text after the values have been restored and the routine has exited.

Sorry for the wall of text, but I am hoping to answer most of your questions before you ask them.

(Solutions attempted thus far:)

1) Try on another PC station - Issue is consistent across all stations

2) Close AutoCAD and restart to see if format returns - Failed results, corruption remains.

Re: Issues with Tables - 2015

leothebuilder — Fri, 20 Mar 2015 21:53:01 GMT

If your LISP alters LUNITS, LUPREC, DIMSCALE, TEXTSIZE, TEXTSTYLE varibles and restores them upon exit to previous settings it may be that prior to restoring the values they do have an effect on the autocad table.

This may be a dumb question, but why run this LISP if the values are being restored to previous values.

Would it be better to set these variables in a template and be done?

Re: Issues with Tables - 2015

llorden4 — Sat, 21 Mar 2015 00:32:01 GMT

The LISP routine is doing a boat load of drawing tasks and text creation in a defined drawing area (in model space) that I did not delve into as it's rather extensive. It's a glorified macro of commands being executed based upon values entered by the user. The routine will create text format, layers, etc, that are required and not currently in the drawing, in the event the user didn't start from a prepared template file. At the end of this routine, all the settings are simply restored to what they were before the routine was started regardless of the template file used. The Tables are all located in paper space so they can't even be accidentally grabbed for alterations. The current routine simply creates new objects and text, it does no editing to objects.

You could compare this to (non-associative) Dimstyles, if you created dimensions at different scale factors using the same dimension style, if you were to go back and edit/move/highlight a previously placed dimension that was placed at a scale different from the current value, it would immediately change to match the current active settings.

Some of my thoughts are that there might be a memory leak in the routines that govern the table data and that somehow changing one of those system variables or text height is bleeding into the table font settings. I've had some type of bleeding issues before with table cells giving some very weird results to formulas for unknown reasons, there's still some nested bugs to work out in tables and I fear this may be one of them.

I'm hoping someone else has run across this issue and has figured a solution they might share.

Re: Issues with Tables - 2015

llorden4 — Fri, 12 Jun 2015 15:36:57 GMT

I finally found a solution so I'm back to share.

Somehow the Table Styles are getting modified in the process, even though the values in the tables are showing correctly. To clear the issue I modified the active TABLESTYLE by adjusting the Text Height of the Title, Header, and Data fields to Zero. For some reason, a value of zero allows the table to return to it's normal state and will automatically poplulate the height field with the original values originally defined in the table before this strange alteration. The thumbnail will show a funky mis-sized table while you're updating in this manner, but once you hit OK then everything returns to normal.

Re: Issues with Tables - 2015

scot-65 — Fri, 12 Jun 2015 22:17:27 GMT

For best results, consider these:

The textstyles used in tables shall have fonts with an assigned height of zero (0).

Default data type of a cell shall be "Text" and not "General".

When importing (copy-clip) a table from one file to another, the copy-clip object will inherit the properties of the named table in the destination file. To fix this, all tables in the destination file must be erased and the tablestyle purged (insert block=block method does not exist for tables). Or adjust the destination tablestyle properties.

Avoid additional formatting of the cell's borders after table creation.

Avoid additional formatting of the text inside the cells (exception is height and justification, which seems to stick).

Search the forum for additional hints as I have talked about this a few times now...

Hope this helps.