HI All,
I've trying to track down a solution for an issue that we are experiencing. When some of our lisp programs get run, you can no longer double click on text to edit it in paper space. If I put text in model space, I am able to double click to edit it. Is there a variable for this?
EDIT: I just verified something else, if I move the text to be outside of the View Port, I can double click to edit the text. If I try to double click to edit while inside the viewport then it switchs to model space withing the viewport.
"When some of our lisp programs get run..."
If you think it might be a variable being changed without your knowledge, you could give this a look/try:
@dmfrazier wrote:"When some of our lisp programs get run..."
If you think it might be a variable being changed without your knowledge, you could give this a look/try:
That sounds like it requires you to know which variable. I have a case where I don't know what variable is causing it to happen.
Type in VLIDE at the command prompt and load your lisp file into it via File-->Open.
Once your code is loaded you will need to place a "watch" on all of your variables in order to see if any are acting up.
Without knowing which var you're trying to watch ...may just have to take your variables after the defun statement one by one but at least you'd get to see how their values change in order to *find* the correct one to modify.
Also sounds as if you're working in paperspace with a viewport into a section of the model.
If you're having trouble doubleclicking text in the viewport while you are in paperspace then the text is likely been placed in modelspace. That's why when you double click in the viewport it'll allow you to edit the text then, and alternatively when youre in modelspace it will also allow you to edit with a doubleclick.
If that doesn't help then perhaps placing your text outside the viewport to edit then issuing a move command would suffice?
hth..
@Anonymous wrote:Type in VLIDE at the command prompt and load your lisp file into it via File-->Open.
Once your code is loaded you will need to place a "watch" on all of your variables in order to see if any are acting up.
Without knowing which var you're trying to watch ...may just have to take your variables after the defun statement one by one but at least you'd get to see how their values change in order to *find* the correct one to modify.
Also sounds as if you're working in paperspace with a viewport into a section of the model.
If you're having trouble doubleclicking text in the viewport while you are in paperspace then the text is likely been placed in modelspace. That's why when you double click in the viewport it'll allow you to edit the text then, and alternatively when youre in modelspace it will also allow you to edit with a doubleclick.
If that doesn't help then perhaps placing your text outside the viewport to edit then issuing a move command would suffice?
hth..
Hi bhull1985,
I have an odd case of having trouble replicating the issue that another drafter is having. I haven't managed to replicate the error on my own computer however, I have a copy of a drawing that the issue happened on. I compared all of the variables that we have in the program and the variables are all the same between the drawing where it works and the drawing where it doesn't work. Unfortunately I don't think moving the text outside the viewport and moving it back would work for our drafters. I do know the text is on paperspace as I can select it. It just doesn't go into the text editor when I double click on it. If i type ED on the keyboard I can edit the text, but most of our drafters use double clicking to edit text. Thanks for the possible answers but unfortunately I've already looked at all of the variables called out in the program.
Also is it possible that I"m using the wrong term? When I'm saying variable I'm referring to cmdecho, osmode, pstylepolicy, etc.
Those are system variables, so yes and no...
If I remember correctly there is a sysvar that will control the double click to edit or not actions, wether a dbl click executes ddedit or not, basically. I'll look into it..
A quick google search of "double click edit autocad" returned some references, here's what may fix your drafter up.
From nukecad's post on cadtutor forums:
dblclkedit is the variable you are after.
From the help-
DBLCLICKEDIT controls whether double-clicking an object results in the display of a dialog box. If double-click editing is turned on, one of several dialog boxes may be displayed, depending on the object type that is double clicked.
When you double-click most objects, the Properties window is displayed. Double-clicking some types of objects displays specialized editors that are more powerful, convenient, or frequently used. Objects that display specialized editors when double-clicked include
Attribute: Displays the Edit Attribute Definition dialog box (DDEDIT).
Attribute within a block: Displays the Edit Attributes dialog box (ATTEDIT).
Hatch: Displays the Hatch Edit dialog box (HATCHEDIT).
Leader text: Displays the Multiline Text Editor dialog box (DDEDIT).
Mtext: Displays the Multiline Text Editor dialog box (DDEDIT).
Text: Displays the Edit Text dialog box (DDEDIT).
Hope this is a more useful response than my previous one
Yes, that may fix it as well
Issue a "send to back" on your viewport object. The actual viewport pline itself, that is, ofcourse.
Well of course right after you guys replied our internet went down here so I'm only now finally getting a chance to review what you guys suggested.
bhull1985, that system variable is one of them that i found when I had been searching for a solution myself and while I don't currently have access to the person's computer who gave me the problem, I have the drawing that they sent me and this system variable is set to on.
dmfrazier, I tried sending the Viewport to the back and it's still not working.
Thanks guys for trying to help, this is such an odd problem and the fact that I have not been able to replicate the problem on my own computer has made this even tougher to find a solution to. Is there some way to get like say a word file with all of the system variables and their current setting? Also can system variables be different between 2 different open drawing files?
The system var would need to be changed on his machine.
They are local to each session of autocad, but roll over into the next one most of the time. I.e. are stored values that can be modified via lisp
@Anonymous wrote:The system var would need to be changed on his machine.
They are local to each session of autocad, but roll over into the next one most of the time. I.e. are stored values that can be modified via lisp
So If I'm understanding what you're saying correctly, this wouldn't be a system variable causing the issue if it happens on 1 drawing but not the other drawing with both drawings open?
If you have Express tools installed, there is a command SYSVDLG that will show you all sysvars and which are saved in DWG, registry, or not saved.
To produce a listing (without custom function):
Command: setvar
Enter variable name or [?] <last one>: ?
Enter variable(s) to list <*>:*
You can copy from the command window and paste into your editor of choice.
Hi dmfrazier,
I did the setvar followed by ? followed by * and went through and tried changing any that were not read-only to match the value on the drawing that works and this didn't fix it. Any other ideas on what could possibly cause this to happen?
Current AutoCAD Service Pack?
Windows up-to-date?
.Net updates?
Uninstall/re-install?
(We're getting desperate now!)
Type DDUCS to open the UCS settings and then set the current UCS back to world.