Table in dynamic block visibility problem

[mileshotz]

Hey all,

I'm doing a lot of work with dynamic blocks with visibility states (like, A LOT), and I've hit a bump.

I have a block that contains a table in a certain visibility state that gets selected when I click where it would be in other visibility states. This makes windowing impossible. Massively frustrating. Not catastrophic, but nontheless.

I've spent a lot of time googling and searching forums, but to no avail. Anybody have some pearls of wisdom? System variable, lisp routine, incantation, etc.?

[Libbya]

Post the file.

[mileshotz]

Here's a mock up that demonstrates the problem. Open in block editor and try to click the mtext object, you'll see.

[Libbya]

When the 'Typical Header' visibility state is active and I do a window over an empty area where part of the table would be, the table is not selected.  I would suggest you restart your computer and then try again.  If the behavior is the same, then I would imagine a system variable is at fault but I am not sure which one to suggest.  

[mileshotz]

Thanks for trying. 🙂

Upon restart and reopening the above file the problem is dormant until I switch to and back from the "WITH TABLE" visibility, after which the table will be selected when I click around where it would be.

Still open to suggestions.

[Anonymous]

Have you found any solutions for this problem? I'm trying to create a dynamic block to have all of my conduit schedules for each configuration detailed out with a visibility dropdown.

I created multiple tables at the same coordinates with different conductors and ampacities. As you have pointed out, when I swap between visibility states the "invisible" tables interfer with the current tables I'm trying to edit. If I double click, I end up editing whathever table is draw order-->front.

This bug is likely going to prevent me from having this functionality. I can do the same sort of visibility selection with layer freezing (note: freezing, not hiding. If you try to hide tables on different layers this same problem presents itself), but it's not as intuitive to other users and requires objects used in mulitple visibility states to be copied rather than reused. 

ETA:

My workaround atm is to grab all the tables in the current visibility (note you have to window select, ctrl+A grabs the "hidden" tables) and move a set number of units to the side (I always use 40 units so it's easy for me to remember). I can edit the tables without issue and then move it back 40 units. It's clunky and I had to add a note to the defpoints layer to other users that they must follow these steps to edit the tables.

[Anonymous]

I notice there's not a visibility parameter drop down triangle for this block. Is that on purpose or would this work better if it had one so that way you could toggle through visibility states?

[Anonymous]

I'm not sure if you meant to reply this to me or to the top level thread, but he has a visibility selecter shown below. Is this what you are referring to?

[Anonymous]

That is what I was talking about. I can see it in the block editor and when I utilize the block testing, but when it comes to straight up using the block in a dwg, the visability parameter doesn't appear. I get the issue I believe mileshotz is referring to.

[Anonymous]

in the block editor, I clicked on Test Block button. In there, I was able to right click copy the block and paste it in a dwg. The Visibilty parameter is there and now it's working like a regular visibility block.

[Anonymous]

I see. I downloaded the .dwg and used the block insert command to insert it into a blank drawing and the visibility parameter showed up the first time.

Any luck with the table not hiding in block editor? I thought that was what the original issue was. The issue I'm having is if you perform a bedit on his block, change the visibility to the table, change the visibility back to headers, and click on the headers you actually click on the "hidden" table. This issue is present in my blocks as well as his and is a huge hurdle in terms of using blocks to control which tables are visible.

[Anonymous]

So far the only thingthat I can get to work is to copy the table and paste it back into the dynamic block as a block. You'll have an extra step in the process if you want to edit the table, but it won't interfere with the "typical Header" dropdown.

[Libbya]

As I mentioned in my last post, I cannot reproduce the issue on my workstation.  Because of this I must assume that the issue is with a setting on the individual workstations that have the issue and is not an issue with dynamic blocks themselves.  As I mentioned, I would focus on system variables with particular attention on anything relating to tables or selection.

[Anonymous]

Libbya, would you mind watching the gif below and see if you can recreate this with your machine? It may be that we aren't describing the problem well and a video will be more obvious. If you cannot reproduce this problem then I will start searching through all the settings to see if there is some weird table setting on. Unfortunately, this problem exists on all of our machines at my office.

Edited to add:

When you do a window select the table won't be selected. If you do a select all (control + a) or click to select the table is in the way. I can't window select to change a table's entity, and if I have a table on top of a table (different visibility states) this problem will persist. So far, my solution is to do a window select and move the current table (window select doesn't click on hidden tables as you have pointed out). I then edit the table and move it back. This is extremely troublesome and is preventing me from switching our templates to a dynamic block for all conduit options (something that will save engingeering a large number of hours).

[Libbya]

I misunderstood the issue.  I assumed the issue was with the function of the block rather than within block editor.  What is the desired function of the block?  My best suggestion would be to switch to the Table visibility state, move the table to the side, finish work on the other visibility state(s) and move the table back.  

[Anonymous]

That is my current work around.

What I want (and why this question popped up when googling the issue) is to have anywhere from 3-20 tables in the same spot (x+y coordinates). I want to have a drop down menu with the different compressor configuration. When you make a selection the appropriate load tables + conduit tables will display. My first idea was to handle this through layers, but after introducing dynamic blocks our designers had zero questions when it came time to assemble the drawing sheets. If I go the layer route I'll have to have duplicate tables (some of the compressor configurations can reuse tables such as 1xtwin and 2xtwin, the first twin table can be reused) and we have to make sure the correct layers are frozen. More steps and more areas where there can be confusion.

Ultimately I would like to have a visibility drop down that has each configuration named with our configuration numbers and zero thinking has to go in to these sheets. When they come to me for review, I might have to tweak some of the table values (say upsize a dryer). I want to just do a bedit, select the appropriate cell, and update the value. My work around is acceptable, except when the file goes to another engineer he or she is confused as to why he or she is modifying a hidden table rather than the desired (and displayed) table. If this issue gets resolved then we will have a much more elegant template file and no one will fight the transition.

[Libbya]

Another potential workaround is to place each table in its own specific location (not stacked) and use the combination of visibility state and lookup to make the correct table visible and place the correct table in the correct location.  It is a little more work (not much) to set up initially, but it would eliminate the irritation of clicking on the wrong table when editing.  See attached.

[Anonymous]

That is a great workaround, actually. Thanks for the input. I haven't used lookup tables before so I'll do some learning and likely incorporate this.

Offhand, do you know of any downsides to a workaround like this? I don't mind the initial work in setting up the lookup table and 0,0 point if it means that future users won't accidently edit the wrong table.

[Libbya]

There is not any downside other than the time involved in setting it up.  It's actually pretty easy and lookups are, IMO, the most powerful tool within dynamic blocks.  Definitely worth learning.  Let me know if you hit any snags.

[Anonymous]

I'm thinking I need to go back and do lookups for my previous blocks. In cases where dispensers can change I just have them all in the same spot so I can see which lines can be resued and which are changed. It's annoying having to be careful where I click. Being able to have them all laid out next to one another will grealty help with my editing!

Thanks again.