objectdbx and redefine block

hi,
a follow up from last week..."objectdbx and copyblock"

works perfect, the way TT described, i am actually able
to redefine blocks from a drawing containing the new definition
(without pulling it into the drawing editor), to any drawing,
be it current, active but not current (mdi=0) or just existing
on the system, as long as it is not R/O.

the only detail i am not able to figure out is to delete the
block definition not being used anymore (purge it)
(vla-delete blockobject) is working fine only if the
drawing being processed is the current, or loaded
into the same drawing editor (mdi=0), of course i am
able to purge after i pull the drawing into a drawing editor,
but i would like to do it using objectdbx

TIA
mark

 

I would venture to guess that (vla-delete) requires
AutoCAD to scan for references to the block, and that
may be an operation that's dependent on the drawing
editor, or that the drawing's database be the 'current
working database'.

If that's the case, then the only possible way to do
this, if any, would be by making the AxDbDocument the
current working database, which can't be done using
LISP, VBA or ActiveX.

My AcadX library does allow you to do this.

 

Tony,
then, i will have to include in my s::startup
a block puging mechanism...
i will live with it for now.
thanks
mark

 

I have successfully "purged" (vla-deleted) objects from a drawing opened via
ObjectDbx. What symptoms are you experiencing that indicate things aren't
working?

 

John,

I'd appreciate any code examples you or others might be willing to share regarding
changes made to a file opened with ObjectDBX. For instance, something as simple(?) as
delete an object and save the change back to the source file. I've Google searched,
but didn't come up with much.

If I understand Mark's first message, it sounds like what I found after some
half-baked fooling around. Source file contains an unreferenced block definition. I
can vla-delete (purge) the block def when source file is contained in the documents
collection. It's open, but not active. If I open the same source file with DBX, the
block def remains after trying to delete it. No error message as I recall. It just
doesn't work given similar delete code.

I'm sure there's much I don't understand here. My sense is getting data from a DBX
file is a fairly straightforward operation. But changing the DBX file in some way,
and saving the changes, requires some other level of understanding.

Thanks
Joe Burke

 

Mark,

Thanks for the code. I hope to have time to study it tomorrow.

One thing which might be of interest, not tested. While Google searching the topic, I
ran across a message from R. Robert (as I recall) which said in effect, you shouldn't
use vla-xxx functions when dealing with ObjectDBX files. IOW, this might work:
(vlax-invoke vobj 'Delete) but this (vla-delete vobj) might not. Of course if that's
true, you'd probably need to revise other parts of your code likewise.

A shot in the dark at this point...

Joe Burke

 

The following is an excerpt (c/w original spelling mistakes
et al. from a message I posted on Tuesday, December 09, 2003
03:02 PM in a thread titled:

"visual lisp symbols and constants - where 'splained?"

started by David Kozina.

I wouldn't quote it but it would not come up in a google
search for some reason.

This is only my opinion and based on my experience, as limited
as that may be. I encourage you to confirm through your own
testing whether these assertion are true and to what degree
(pretty much goes for anything I post really). Still, you
may find it interesting given your post and why I offer it.
There's a lot of info in said thread btw.

Anyway ... <quote>

Code:

While not exhaustively proven, I have determined to my own
satisfaction that ...

1) Using vlax-invoke-method, vlax-get-property etc. are

o  less prone to unexplained errors,
o  generally speaking, perform faster

than equivalent vla-* functions ( though the benefit may
only realized when performing MANY function calls like
inside a while loop ).

2) and, using

(vl-catch-all-apply
'vlax-invoke-method
(list
Object
'QuotedMethod
Parameter1
Parameter2
...
)
)

<<< and equivalent get / put code for properties >>>

Generally performs faster than

(vla-catch-all-apply
'(lambda ()
(vlax-invoke-method
Object
'QuotedMethod
Parameter1
Parameter2
...
)
)
)

Even though the latter is prettier.

I found this out when batch processing via dbx. I was
able to elimiate 99% of the errors that used to pop up
and improve overall performance dramatically by
adoptiong the above. For one-off code or quick and
dirty utilities I still use vla-* etc for mere
convenience, but for anything that is destined for
intense use I follow the above.

</quote>

And later in the same thread ... <quote>

Code:

I never benched vlax-invoke versus vlax-invoke-method,
vlax-get versus vlax-get-property, or vlax-put versus
vlax-put-property. Also, I found that simple bench
marking of vlax-invoke-method versus the equivalent
vla-xxx call did not reveal performance differences.
However, when running objectdbx against thousands of
drawings I found a performance and *stability*
improvement going the vlax-invoke-method etc. route.

Another thing I forgot to mention ...

Even though this would appear to me to be proper form
to trap the attempt to retrieve the value for a
property that sometimes does not exist:

(if
(vlax-property-available-p
Object
'PropertyName
)
;
; get and do stuff with PropertyValue
;
)

I found better performance trapping an attempt to get
the property and then branching so:

(if
(null
(vl-catch-all-error-p
(setq PropertyValue
(vl-catch-all-apply
'vlax-get-property
(list
Object
'PropertyName
)
)
)
)
)
;
; do stuff with PropertyValue
;
)

To me it seems like sloppy programming, but I needed
outright performance in one of my utilities -- so I
went the latter route.

</quote>

I'm out for the balance of the day, so if you post
something and it appears I'm ignoring it -- I'm not.
I *may* be able to visit this forum tonight. Cheers.

 

Thanks, Michael.

I'm pretty sure I've seen that thread while Google wandering. It made an impression
then. I've tried to follow your advice since.

Joe Burke

 

John,
(vla-delete ...) IS working fine, i was doing tests
on different drawings tested while writing code...
my mistake.
i can go ahead and polish my code now...
thanks
mark

 

Mark,

I'd be interested in seeing your polished code, if you don't mind posting it. I
haven't had time to study what you posted previously.

Thanks
Joe Burke

 

That's good news! As Joe requested, how about educating us what the problem and
fix was?

 

Mark and John,

I found answers to the questions I posted a few messages back. Basically I didn't
understand how to SaveAs a DBX doc. For one thing, I was trying to use the Save
method rather than SaveAs. Delete an unreferenced block definition works now. One
more lesson learned.

So no need to post your code on my account, Mark.

Thanks anyway,
Joe Burke

 

there was no problem, and no fix, the code i posted earlier works just fine,
just remove the semicolons from in front of the (vla-delete bobj) ...
while i was doing tests, multiple bogus block names were being accumelated
of the same block definition, when the code was finalized, of course it did
not purge out the blocks created in a different session!
and btw, John, i do not think i can educate you, i have seen your code
maybe u can polish up my code and post it, for all of us to share.
mark

 

For the sake those following this thread, there are a few
things that I failed to point out.

Redefining a block that is used as a dimension arrow will
require some additional work. In addition to renaming all
references to the block (translating the name back to the
original block's name):

1. You must perform the same name translation to any
dimension style's DIMBLK1 and DIMBLK2 settings.

2. You must perform the same name translation to the
current values of those same dimvars.

3. You must perform the same name translation to the
stored values of those two dimvars in any dimensions
where they are overridden (stored as handles in the
dimension's Xdata).

All of the above is unnecessary if you use ObjectARX or
the SwapIds method in AcadX, which swaps the identities
of the old and new block objects, and eliminates the
need to resolve any references.

In short, I'll stick to ObjectARX for redefining blocks,
as similar problems can crop up if any private application
data contains references to a block object. And since you
don't know about them, or what to do about them, you'll
be hitting the wall.

 

Mark:

I took only a cursory glance at your code, and found an apparently good
knowledge of VisualLisp and ActiveX. The second observation was your preference
for saving lines of code. Maybe it's from having spent time here and
appreciating others' structure, or maybe it's from worries about word wrap
problems in posting, but tree-structured indents might help readability. Lately
I tend to create a lot of white space for the sake of structure. It's all the
same when you "compile" to .FAS.

As to content, I think (but not sure 'cause I haven't really tested) that there
is something special in passing the document object to a subfunction in order to
save(as) it, rather than acting on the object in the current function. It think
it was Joe who had posted the SaveDbx function from James Buzbee (and probably
from someone earlier like Tony or Vlad). Sounds stupid, and maybe it is, but I
think the approach solved an earlier problem I had. Then again, there are
plenty of anomalies one encounters when working with LDT drawings. :/

Anyway, I hope to do as you ask and see if there might be some flow
improvements. I've become enamored with the Stephan Koster approach of (and ...
(or...)) as opposed to (if... (progn...)), but some days the right lane is
faster than the left lane (actually most days in Virginia, but that's another
story). Bear in mind that Tony is right about many things. ARX is the ultimate
way to go, but there's a steep learning curve to climb which requires a lot of
time if starting from 0. - John

 

Hi John,

For what it's worth... I've seen the James Buzbee SaveDbx function you mentioned
while Google researching ObjectDBX in general. I haven't posted it. So if someone did
recently, it wasn't me.

Given my limited experience with ODBX, far less than yours, I haven't encountered a
problem so far with doing a SaveAs in the current function. As opposed to passing
that task off to SaveDbx. I'm only dealing with vanilla ACAD. Until recently, A2k2.
Lately A2k4.

BTW, I really like your Stephan Koster approach. Given a fairly simple code task,
it's not hard to implement. And the advantages are obvious. But I find myself
intimidated trying to apply the idea to more complex code. I know it can be done. I
also think it's a matter of screwing your head on in a certain direction that's not
exactly "standard". Assuming there is such a thing as "standard".

Actually what I find most interesting about it is seems to stress my basic lisp
knowledge. And I guess that's good in itself.

Joe Burke

 

My mistake. It was Mark Propst on 2/05/04.
It was probably also my mistake about the perception that a separate function
helped. If I run into the problem again, I'll post the circumstances.