Visual Lisp, reactors und UNDO/REDO
Tony Tanzillo
Zoltan Djapjas wrote:
>
> Hi folks !
>
> Now as I proceed with my litte reactor-driven program I (at least) got to
> this point:
>
> I've connected two entities (a dim and a text - don't ask why) via reactor
> to the dim and added the text as an owner to the reactor. Now with a little
> programming I'm able to ERASE one of them and the other disappears too. So
> does the reactor.
> Now I invoke an UNDO and the two objects reappear on the screen but - of
> course - the reactor isn't restored. Logically, if one object is deleted the
> other still remains...
>
> The online-documentation tells that this is a very complicated thing to deal
> with and leaves you alone ("afairi" - as far as I've read it)
>
> So this is my question: How can I manage to refit the reactor to my nice
> dimension ?
> And what about REDO the UNDO ? Uh, oh..... ???
>
> Thanks for your help in advance !
>
> Zoltan
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Zoltan Djapjas
Zoltan Djapjas
>Is your reactor persistent?
Dear Tony,
yes it is in fact.
The programm should someday work as an architectural dimension in german
style. This means the "dimblk's" are not symmetric and they point to the
dimensioned wall (for instance) with the longer end. But AutoCAD likes to
turn the dimblk's around, if it is necessary (maybe the text is too long to
fit between the dimension-markers or if the dimensioned distance is so close
that even the markers don't fit) with the effect that the dimblks are
rotated by 180° and then are simply pointing to the opposite (and therefore
wrong) direction. When I erase the dimtext by setting it to " " this
behaviour is no more needed (because there is no text drawn) and everything
works fine with that dimension, exept that I now need to add an individual
text which doesn't care if it doesn't fit. The user can move it away like he
wants. That's ok with me and the users so far.
But when I come to the point to modify the dimension by moving around or
stretching it, the text must be changed, too. And it has to be deleted if
the dimensioning is deleted of course.
My idea (developed in the last more or less sleepless night...) is to build
a global lisp-list, which keeps track of the data (position, dimstyle and so
on) which is stored to the object-reactor everytime a command changed the
dimensioning. The data will be pushed to the (FIFO - first in first out)
UNDO-list with the information about the dimensioning-object to which the
data belongs to. A UNDO will now pop it back to the list by installing a
database-reactor which will get the object's name which is restored and the
callback-function to this reactor has to reattach the data to the reattached
object-reactor.
This is somewhat complicated, but the UNDO-list will only be needed in the
actual session.
>think, think.....< or do you mean that the data should be attached to the
individual dimensioning and not to the reactor ? Will that data be restored,
when the object is undeleted ?
OK, you see my head is already smoking, so if you could give me a hint ?
Zoltan
Tony Tanzillo
entries that are attached to it, before and after the UNDO,
and see if there is any difference. I don't know why this is
happening, but a persistent reactor should be automatically
handled by UNDO and restored when the object is undeleted.
Otherwise, you may have to hook some additional reactors and
reattach it manually.
--
Zoltan Djapjas
>Try comparing the entity data of the object and any dictionary
>entries that are attached to it, before and after the UNDO,
>and see if there is any difference. I don't know why this is
>happening, but a persistent reactor should be automatically
>handled by UNDO and restored when the object is undeleted.
Maybe I've got an old version. Mine is "Build Version: 597"
Many thanks for your immediate answer to my last postings, I would be very
happy to solve this problem, because time is running away with this
dimension-thing....
greetings, Zoltan
Owen Wengerd
There's a bug in R14 whereby an undo doesn't restore dictionary entries.
Could that be the culprit? :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Tony Tanzillo wrote in message <36AEF2DF...@worldnet.att.net>...
>Try comparing the entity data of the object and any dictionary
>entries that are attached to it, before and after the UNDO,
>and see if there is any difference. I don't know why this is
>happening, but a persistent reactor should be automatically
>handled by UNDO and restored when the object is undeleted.
>[...]
Tony Tanzillo
Owen Wengerd wrote:
>
> Tony/Zoltan:
>
> There's a bug in R14 whereby an undo doesn't restore dictionary entries.
> Could that be the culprit? :)
> --
Zoltan Djapjas
>That would certainly cause a problem.
Indeed. Them Shit-Damn-Computers. Sorry.
Alright. What does that mean ? Does this occur in C++ - ARX modules too ?
If not and if I would be consequent I would like to draw by hand again. My
rubber has no such "UNDO-problem"....
Owen, did you guess on this topic or do you really know that's a fact ?
Maybe that is the reason, why the tutorial only says "everything more than
this is complicated".... But why then reactors at all ? They are not easy to
manage with, even I got it finally all to work, exept the undo. But if they
are not managed right within AutoCAD they're worthless at all because the
undo-feature is so very important. The users do wrong klicks all day long
and always undo. Except with my dimensioning ? That's really not funny...
Hey Autodesk-people are you reading ? Does anyone can make a clear statement
on this ?
OK. Came down again.
And so I ask again: any ideas anyone ?
thanks, Zoltan
Owen Wengerd
>Owen, did you guess on this topic or do you really know that's a fact ?
I'm not sure, but this UNDO bug may have been fixed in R14.01. It's not
hard to test: create a command which removes dictionary entries that you
added previously, then run the command and UNDO it again to see if the
entries come back after the UNDO. :)
Matt Stachoni
If you simply need to reverse the dim blocks in the dimension, why don't you
simply reverse the definition points?
(defun c:fd (/ ss i en ed defp1 defp2)
(prompt "\nFlip dimension endpoints")
(command "._undo" "begin")
(setq ss (ssget '((0 . "DIMENSION"))))
(setq i 0)
(while (< i (sslength ss))
(setq en (ssname ss i))
(setq ed (entget en)
defp1 (cdr (assoc 13 ed)
defp2 (cdr (assoc 14 ed)
)
(setq ed (subst (cons 13 defp2) (assoc 13 ed) ed)
ed (subst (cons 14 defp1) (assoc 14 ed) ed)
)
(entmod ed)
(setq i (1+ i))
)
(command "._undo" "end")
(princ)
)
This works for me...
Matt
stac...@bellatlantic.net
msta...@architectsde.com
www.architectsde.com
On Wed, 27 Jan 1999 11:17:52 +0100, "Zoltan Djapjas" <ZDja...@T-Online.de>
wrote:
Zoltan Djapjas
Matt Stachoni schrieb in Nachricht
<36b6d174...@adesknews.autodesk.com>...
>If you simply need to reverse the dim blocks in the dimension, why don't
you
>simply reverse the definition points?
That's exactly what I'm doing and the problem is already solved. I only
wantet to explain the circumstances why I got into the main problem of
restoring reactors after undeleting entries or handling an undo after any
command.
Thank you !
Zoltan