Multiple Lookup Grips - how?

[Anonymous]

I've been trying to use a variant of the 'multiple visibility' technique
that Thomas Dean provided in the 'Toggle Fill' thread a couple of months
ago, but I've run into a maddening difficulty.

In the example provided in that thread, there were 2 'visiblity lookup
dimensions' - Turn Options and Fill ON/OFF.

But I was wondering if it would be possible to do something similar with 3
'visibility lookup dimensions'.

Basically, I'm trying to create a block with 3 different lookup on/off
toggles, thus making 8 (2^3) combinations.

The attached drawing is a weld baseline symbol w/ Field Weld Flag/All
Around/Tail toggle options.
3
I've already thought about:
- Creating three different blocks to control each toggle option...
but I'd like just ONE Left-Right flip action to suffice for those 3
kinds of weld features.
- Just providing the 8 different visiblity options for the block and be done
with it...
but it's surprising how complicated (cryptic even) those 8 options
appear when written out.

What ends up happening when I use the above mentioned 'Toggle Fill'
technique is that there are indeed 3 different reverse lookup control grips
on the block, but each grip *counterintuitively* controls the OTHER 2 option
sets, rather than its own ON/OFF option set.
i.e. - The Field Weld Flag control grip provides the 4 options for All
Around and Tail toggling, while the All Around grip provides the 4 options
for Field Weld Flag and Tail toggling, and the Tail grip provides the 4
options for Field Weld Flag and All Around toggling.

What I want to do is have the Field Weld Flag grip control just its OWN
on/off options, (not the others), and so on for each of the other lookup
grip controls.

Does this make sense? I thought it would be rather simple, but I'm stumped.
Any ideas on how to accomplish this?

Regards,
David Kozina

[Anonymous]

I don't see the drawing I attached to my previous post, so am trying
again...

[Anonymous]

You did well setting up the visibility list. The next part is where it gets
tricky. Think of the lookup parameters as a toggle of what two options (on
or off) you need for that area while the other items stay the way they are.
But, each time you toggle a lookup, the other two lookups will then need to
display ONOFF's that will allow that initial change to remain. I can't
really explain it well, but take a look at the attached modified block and
see if it makes any sense.

Thomas

[Anonymous]

Thomas,

That was exactly what I was after.
Thanks VERY much for the tips!

Best regards,
David Kozina

"Thomas Dean" wrote in message news:5049149@discussion.autodesk.com...
You did well setting up the visibility list. The next part is where it gets
tricky. Think of the lookup parameters as a toggle of what two options (on
or off) you need for that area while the other items stay the way they are.
But, each time you toggle a lookup, the other two lookups will then need to
display ONOFF's that will allow that initial change to remain. I can't
really explain it well, but take a look at the attached modified block and
see if it makes any
sense.

Thomas

[mugenlude]

You need to basically setup 4 lookup parameters and actions for each toggle you want.

You have 3 variables in your DB
Tail-ON -or- Tail-OFF
AA-ON -or- AA-OFF (All Around)
FF-ON -or- FF-OFF (Field Flag)

I'll explain the Tail Toggle because that is the example I completed in the revised .dwg I provided you. I labeled the parameters/actions just like I described your variables to make it clearer.

Here are the 4 parameters. All of the parameters will be placed on top of each other so when you toggle them they 'seem' to be the same parameter lookup. However, you use your visiblity states to change which parameter is visible.

AA-On, FF-On, Tail Lookup
AA-On, FF-Off, Tail Lookup
AA-Off, FF-On, Tail Lookup
AA-Off, FF-Off, Tail Lookup

The action for each of the above parameters will have 2 visiblity states as lookups, the Tail-On and Tail-Off visiblity state with the corresponding parameters above (ie. Tail-On, AA-On, FF-On and Tail-Off, AA-On, FF-On). Then you name the lookup Tail ON and Tail OFF.

Then you go to your visiblity states and make this lookup action available to the specific states. (ie. you would make the above example visible in the 2 states it matchs).

You need to do the above for each toggle. I did the tail toggle for you, now see if you can complete the other 2 toggles.


I'll get you started... For the Field Flag Toggle you'll have these parameters/actions.

AA-On, Tail-On, FF Lookup:
It will only be visible on the "AA-On, Tail-On, FF-On" and "AA-On, Tail-On, FF-Off" visiblity states. Those visiblity states will be in the lookup actions with the name FF ON and FF OFF.

AA-On, Tail-Off, FF Lookup:
It will only be visible on the "AA-On, Tail-Off, FF-On" and "AA-On, Tail-Off, FF-Off" visiblity states.

AA-Off, Tail-On, FF Lookup:
It will only be visible on the "AA-Off, Tail-On, FF-On" and "AA-Off, Tail-On, FF-Off" visiblity states.

AA-Off, Tail-Off, FF Lookup:
It will only be visible on the "AA-Off, Tail-Off, FF-On" and "AA-Off, Tail-Off, FF-Off" visiblity states.

[mugenlude]

Dean got in before me... 😃 And he completed the entire thing.

[Anonymous]

That Dean... He can really be annoying at times. 🙂

I never took the time to explain it as well as you have, though. That's
awesome. We should refer anyone who has questions about this technique to
this thread from now on.

Thomas

[mugenlude]

Sounds good to me. 😃

[Anonymous]

David,

I've got a dynamic weld symbol that I designed not long
ago that I'd be interested in getting some feedback on, if
you are interested.

The block I designed allows changes to the type of weld
(fillet, plug, square, etc..) via the dynamic block grips, but
the visibility of the flag, all around, and comment tail
components are all handled via code at the command line.

I have yet to use this block in production, but will be soon.
Honestly I can't wait to try it out, as this one block replaces
about 136 weld symbol blocks from our library. Not to
mention the ease of use compared to erase the old methods
of erase the old one, place a new block just to dispose of a
flag, comment, or all around symbol (what a pain).

If you (or anyone else, for that matter) is interested in "beta"
testing this for me, send me an email and I'll put something
together for testing. The code supplied with the dynamic
block will be a compiled VLX. Please send any inquires to
j a s o n a t a t r e n g d o t c o m



wrote in message news:5048707@discussion.autodesk.com...

Does this make sense? I thought it would be rather simple, but I'm stumpe

[Anonymous]

I really appreciate the help on this everyone. I think I understand the
situation much better now, and the examples really helped.

After a bit of calculating, this appears to be the case for multiple lookup
aspects (block dimensions if you will) - anyone care to verify?:

CASE: # Vis States # Look-Up Sets (LUS) that
Definitions will need to be created.
Reqd - Min
-----------------------------------------------------------
2 Aspect Types 4 4 LUS in 2 groups
each w/ 2 Opts (2^2) + 2 LUS & Vis States
per ea addl option
-----------------------------------------------------------
3 Aspect Types 8 12 LUS in 3 groups
each w/ 2 Opts (2^3) + 4 LUS & Vis States
per ea addl option
-----------------------------------------------------------
4 Aspect Types 16 32 LUS in 4 groups
each w/ 2 Opts (2^4) + 8 LUS & Vis States
per ea addl option
-----------------------------------------------------------
5 Aspect Types 32 80 LUS in 5 groups
each w/ 2 Opts (2^5) + 16 LUS & Vis States
per ea addl option
-----------------------------------------------------------
etc...

The '2 Opts' referred to above would be a minimal choice set for each Aspect
Type, like an On/Off toggle, whereas additional options could be likened to
a radio button choice list.

I don't think anything over 5 Aspect Types would be very feasable to create,
and even 5 would likely be borderline 🙂 I don't know if such a complex
block would be be a drain on memory resources, but I'm sure it wouldn't help
much...

This would explain the massive increase in complexity for multiple lookup
aspects (dimensions); it obviously explains why multiple visibility grips
is a wishlist item, but it might also explain why it may not be that simple
to implement - egads! - the number of items that need to be dealt with
increase, what, exponentially? factorially? A lot, that's for sure.

I don't know if this makes much sense to anyone, but it was fun to think
about!

Best regards,
David Kozina


wrote in message news:5050011@discussion.autodesk.com...
Sounds good to me. 😃

[mugenlude]

It makes sense to me. I think mulitple visiblity states would be easier, if they could implement them. If I can do it 'manually' per say, then I would think they should be able to come up with some way to speed up the user-end design process with something similar. Maybe not, maybe I just need to keep having drawings with 20+ visiblity states.

I know I have done 4 'aspect types' a couple of times, but I don't know if I've done 5. I do know that closing/saving the DB does slow down, that could just be my computer though. I haven't noticed any lagging problems with numerous insertions of the block into a drawing. I know I have a drawing I'm working on now with about 200 door DB inserted with 4 'aspect types' and a door schedule worth of attributes each and I haven't noticed anything different.

[philip]

Hi all looks like you have solved this problem , i was going through the same problem here and came up with a different way of doing it, I've attached my block, all i've done is scaled the diffenrent standard componets down to almost nothing which leaves my visablity state free for differnt types of welds, Have a looks an comment back on it please.

PS this is designed for metric paper space and needs to be inserted into a drawing

[Anonymous]

pl,
I think that is quite an imaginitive way to accomplish that problem. While
I think it might lead to problems for other types of uses (unintentional or
incorrect object snapping when that technique is used in a different kind of
block, for example), in this particular case I can't see much in the way of
a downside (except perhaps for the objections of 'symbol purists') 🙂

Thanks very much for sharing that technique.

Best regards,
David Kozina



wrote in message news:5053594@discussion.autodesk.com...
Hi all looks like you have solved this problem , i was going through the
same problem here and came up with a different way of doing it, I've
attached my block, all i've done is scaled the diffenrent standard componets
down to almost nothing which leaves my visablity state free for differnt
types of welds, Have a looks an comment back on it please.

PS this is designed for metric paper space and needs to be inserted into a
drawing

[philip]

I do have to agree with your comments I thought it was an wasier meathod of doing welds compaiereed to haveing hundreds of visablity state options to look though.

[Anonymous]

I use one visibility state with all options for weld
types separated into four different lookup tables
which are 'strategically' placed in reference to the
symbol. The placement of each lookup table grip
indicates where the visibility changes are made.

First two or three times I tried to develop a weld
symbol, I felt that it was way to complicated and
was running into the same basic set of limitations
that everyone else is.

When I realized that it could be done in a much
cleaner fashion with a small amount of LISP code
controlling the visibility of the common components
(flag, all around, comment) thereby reducing the
number of options the user has to wade through
to get the desired symbol, it became a no-brainer.

In the attached screen shot, you'll notice 4 lookup
table grips, each controlling weld types. The top
one is for far face, bottom for near face, left one
for the odd-ball combinations (near and far face)
and the right one for identical near and face face.

Each of the components that define the symbol,
with the exception of the reference line, is a block.
Anyone could simply redefine the individual pieces,
while maintaining the same block names, to alter the
appearance of the symbol.

Works well, IMO. My previous offer still stands if
anyone is interested in checking it out.




wrote in message news:5053613@discussion.autodesk.com...
> compaiereed to haveing hundreds of visablity state options to look though.

[Anonymous]

geez, nice formatting




"Jason Piercey" wrote in message
news:5053927@discussion.autodesk.com...



When I realized that it could be done in a much
cleaner fashion wit
h a small amount of LISP code



Each of th
e components that define the symbol,
with the exception of the reference line, is a block.
Anyone could simply redefine the individual pieces,
while maintaining the same block names, to alter the
appearance of the symbol.

[Anonymous]

Looks like the attachment didn't show up




"Jason Piercey" wrote in message
news:5053927@discussion.autodesk.com...
In the attached screen shot, you'll notice 4 lookup
table grips, each controlling weld types. The top
one is for far face, bottom for near face, left one
for the odd-ball combinations (near and far face)
and the right one for identical near and face face.

[philip]

I know what you mean about lisp we had a nice little lisp for doing welds but very hard when you have user of LT in your office (we have LT Acad & ADT) so using Dynamic blocks is the most common format for all these formats

[mugenlude]

I'd be interested in checking out the block and coding. Sounds like an interesting way to handle it. If you could send the files to
jfrank02@hotmail.com I would appreciate it. 😃

[Anonymous]

My main problem with welding routines isn't the initial
generating of the symbol, it is changing the display of
the symbol (quickly and easily) after it has been placed.
Dynamic blocks are absolutely wonderful in that respect.

At first I was trying to do it all with just the dynamic block,
but it just wasn't feasible to include *all* the options in a
single block definition so I resorted to LISP and am fairly
happy with the results.

Fortunately, I don't have to support any LT stations so
I can use LISP without having to worry about it.




wrote in message news:5054505@discussion.autodesk.com...
I know what you mean about lisp we had a nice little lisp for doing welds
but very hard when you have user of LT in your office (we have LT Acad &
ADT) so using Dynamic blocks is the most common format for all these formats