How update a block (swap with block of same name)

Scott,

To put what some of the others have said in a different form:

Though ^c^c might be a clever way of indicating a cancel by using
a symbol rather than nil, ^c^c can be bound to other values and
unexpected things can happen if you rely on the value of ^c^c being
nil all the time (unless of course you have localized it).

I personally don't have a preference for
(command "blah" "blah" "blah" nil) or
(command "blah" "blah" "blah") (command)

It seems to me that passing nil as one of the arguments is extremely
close to calling command with no arguments. The behavior seems
identical at the command line. There is only a mention in the help file
about how calling command without arguments behaves. I don't view
the help files as necessarily complete. Anyone else agree/disagree?

Regards,
Doug

 

I personally don't have a preference

Doug, I agree, can't see a difference.

As an aside, using (command) as an equivalent to ESC is problematic in the
context of a script, because it will have the effect of cancelling the
script. I assume (command nil) would also do this but haven't tested it.

When I've had occasion to update blocks in multiple drawings by means of a
script, I've had to work around this, either by entmaking the block
definition, or by going ahead and and inserting the external block and then
deleting it.

 

Additional notes...

The <blockname>=<filename> usage can redefine a block to match ANY external
file. For instance -INSERT SMALLBUSH=GIANTTREE will redefine your SMALLBUSH
block to match the first instance of GIANTTREE.DWG that is found on the
path.

For this reason, in the present case, prompting the user for <filename> or
allowing the user to browse to select it is potentially dangerous, as well
as unnecessary, since an erroneous selection of the external file will
completely foul up the blocks in the current drawing.

In the present case of redefining a block to match a revised external block
of the same name, the shorthand usage is simply -INSERT <blockname>= with no
filename given after the equals sign. This will redefine the block to match
the first like-named file that is found on the path. Since the desired
filename is already known (it matches the block name), there's no reason to
either prompt or browse for it.

 

True, Tom, but the external file may not reside in the path. In which case the file and it's directory must be supplied in some manner.

 

Tom,
Good point about use of block re-definition in a script. Definitely
don't want to cancel in there.
Regards,
Doug

 

True, Tom, but the external file may not reside in the path. In which
case the file and it's directory must be supplied in some manner.

Absolutely. I failed to make that qualification here, though it's been the
assumption throughout the thread that the block was in a library on the
path.

If not, then you'd have to use the full syntax, and either hard-code the
full pathname in the insertion routine (e.g.
myblock=\\Server\Folder\Folder\etc\myblock) or else let the user designate
the filename in some way, and accept the fact that they might get it wrong.
Of course this would be easy to fix by running the routine again and
selecting the right file instead.

As I mentioned before, this was what we did before we had xrefs, for
instance inserting a "base plan" block in other drawings and maintaining the
base plan separately. The only real difference from an xref (aside from not
segregating symbol names) was that you had to deliberately update the block
when you opened a file referencing it, instead of having it updated
automatically. Typically the base plan would reside in the same folder, so
it was on the search path, so the blockname= syntax worked. I vaguely recall
having a macro that did something like (command "-insert" (strcat (getvar
"dwgname")"=") etc) to make this easy.

 

<<As I mentioned before, this was what we did before we had xrefs,>>

So did we, in fact I still use the same method instead of XREF for some of our more peculiar cases. One of the major advantages we get from xref's (aside from auto-updating) is layer control.


<< I vaguely recall having a macro that did something like >>

I had an old routine that allowed you to pick a block and it would reinsert the drawing file. I use something similar now to "reload" and "unload" XREF's.

 

Hi Doug,

I was reporting me to the AutoCAD help.

But I remember to have read in past somewhere that
it is preferable to use the form:

(command) instead of: (command... nil)

and, subsequently I have modified all of my functions,
in such way.

I have looked for in the documentation of 2005 up to R14
but without success.

I have perhaps had too trust in what it is written in the
AutoCAD guide.

....

(command [arguments] ...)

The arguments to the command function can be strings, reals,
integers, or points, as expected by the prompt sequence of
the executed command. A null string ("") is equivalent to
pressing ENTER on the keyboard. Invoking command with no
argument is equivalent to pressing ESC and cancels most
AutoCAD commands.
....
<clip>

 

There is no difference between:
(command "blah" "blah" nil) and
(command "blah" "blah") (command).

Remember, (command) returns nil, so it evaluates as nil in the 2nd case,
which means it is the same as the first case.

--
R. Robert Bell


"Marc'Antonio Alessi" <nospam maalessi at tin dot it> wrote in message
Hi Doug,

I was reporting me to the AutoCAD help.

But I remember to have read in past somewhere that
it is preferable to use the form:

(command) instead of: (command... nil)

and, subsequently I have modified all of my functions,
in such way.

I have looked for in the documentation of 2005 up to R14
but without success.

I have perhaps had too trust in what it is written in the
AutoCAD guide.

....

(command [arguments] ...)

The arguments to the command function can be strings, reals,
integers, or points, as expected by the prompt sequence of
the executed command. A null string ("") is equivalent to
pressing ENTER on the keyboard. Invoking command with no
argument is equivalent to pressing ESC and cancels most
AutoCAD commands.
....
<clip>

 

Remember, (command) returns nil, so it evaluates as nil in the 2nd case

I still like Tony's (command BURP), but I suppose it would be good practice
to localize BURP to be on the safe side.

 

<snicker>

--
R. Robert Bell

I still like Tony's (command BURP), but I suppose it would be good practice
to localize BURP to be on the safe side.