Pasteclip Dialog Window Suppression

I'm doing a full automation program in which no user input is allowed. One of the tasks I need to carry out is to copy an OLE object from Excel into the AutoCAD drawing and I've got that part working using the PASTECLIP command. The trouble with this is that the PASTECLIP dialog box opens up and waits for the user input....which is a no-no in my case. I have tried placing one, two or even three sets of "" after the command to make the window go away. But it stays put until the user responds to it. Is there a way in LISP to keep the dialog box suppressed?

As I double check this it's a dialog box for the OLE text size. I don't need to make any changes, just have the box never open or close automatically and let the rest of the code complete the drawing.

Perhaps MSOLESCALE.

I'm not too sure why such happens in mine:

Command: (progn (command "pasteclip" (getpoint)) (prompt "\n\nThis has 
finished") (princ))
pasteclip
Specify insertion point: [color=red]Unable to find OLE object.  Object must be selected 
before entering the OLESCALE command.[/color]

Command:

This has finished

Wasn't aware of that setting...but then again there are so many environment settings one never knows of with AutoCAD.

I tried a couple of variations on this, using pastespec but still the problem with the dialog box remains. I thought, like filedia, there was a system variable to suppress dialog boxes, but that still eludes me in this instance.

I did find an option setting under System Tab under OPTIONS for turning off the OLE Text Size Dialog and that worked. But unfortunately, I need to try and find out how to do this on the fly and then return the setting back so the user's environment is not altered after the LISP code completes it's work.

I have this partially resolved by having all the other users in the office turn off their "OLE Text Size Dialog" setting in the options settings. This was decided by the boss because he wants to move on with it. But I think shortly we will have some mild mannered user go postal on us when this setting causes a conflict somewhere else in their environment. I can't imagine how, but Murphy's Law will come in to play here somehow.

The big issue I have with this now is that I'm using this command to paste the OLE object into the model space.

(command "._pasteclip" '(-170.0 0.0) "")

This brings the object in and places the corner of it at (-170.0, 0.0)....sometimes. I ran it on my machine and it worked. I double checked it and it worked but it placed the OLE object at (-107.25. 4.4375). How the heck it came up with those coordinates I will never know. I then asked the boss to check it and sure enough it came up in the wrong place again.

I'm wondering if because at the initial outset of the drawing process, location (-170.0, 0.0) is not actually seen on the screen. I can't imagine this, as I had to learn this lesson the hard way with all the trimming and copying I have to do in this process. I do not recall having trouble with drawing lines which are not visible on the screen at the time they are drawn. But this hit or miss situation has me baffled.

The temporary resolution to this was to first draw a line from 0,0 to -175,0. Then I did a zoom all, which brings the point of insertion onto the screen. I copy the OLE object into it's proper place then erase the original line. Then the drawing process takes over and all is well. But I got to believe there is a better way to accomplish this task.

(command "._pasteclip" "_non" '(-170.0 0.0) "")

Lee,

Haven't tried this yet but will do so shortly. I've never heard of that syntax before. What does it do? Does it tell the pasteclip command to ignore the dialog window or does it force the insertion of the OLE object to the correct point even though it's not on the screen?

"_non" ignores any OSnaps.

Yep, "Non" is short for "None" ... like in "Force an osnap of None instead of using the Running Snaps". You could of course modify your OSMode system variable to omit running snaps (temporary turnoff, by making it negative, revert by making it positive again) - but then you'll need to error trap in order to restore it in all scenarios (lots of lisps don't do this properly and you end up loosing your running snap settings if something goes wrong).

BTW, I've found how to turn off the OLE Size dialog programatically.

(vl-load-com)

(defun ToggleOLETextDialog (on /)
 (vla-put-DisplayOLEScale (vla-get-System (vla-get-Preferences (vlax-get-acad-object)))
   (if on :vlax-true :vlax-false)))

Thanks a million guys. I was really hoping there was a programmatic method for this. Anytime I can change the user's environment (without them knowing it) through the code, the better off the whole process is. Need I say more about how territorial some folks can be and this shop is not lacking for that issue.

And yes imeb, I found a really nice error trapping snippet at afralisp.net which takes care of that issue about setting system variables like osnap to zero while the code does it's work. If any kind of error is encountered, including the user pressing Ctrl+C or Esc...etc... the error trap catches this event and resets everything back to it's original state. And the user's never knew it happened. I think Lee-Mac has an error handling routine available on his site too. I should check it out.

I used the programmatic method to toggle the OLE Text Size Dialog box on and off and that works great. But the "_non" switch is a no go. The OLE object continues to be shoved into a place next to some text which is not actually drawn in the model space at the time the OLE object is pasted into the drawing.

The only thing that seems to work is to draw a line from '(0.0 0.0) to a point somewhere near '(-170.0 0.0) and then do a zoom+all. Can't figure this one out because where it does insert the OLE object is not on the screen at the start of the run either. Yesterday, I did have a successful run with this but I think it was due to the current Zoom level I was at when I ran the program. When this program starts, the model space is completely empty and after only a few steps I have to do a zoom+all to get certain areas on the screen in order for the trim to work. As the drawing progresses, this zoom+all step is repeated several times. I have found this the only way to get the trimming to work. It all takes place in less than a few seconds so it's not like any delay is happening. But it's a pain to see sometimes how zoom level has everything to do with whether something works or not, even when I'm using absolute coordinates.

BTW - When the OLE object is pasted in place, I already have osnap set to 0....so I'm really not sure what the heck this thing is snapping to that makes it end up somewhere around '(-107.875 0.0) instead of '(-170.0 0.0).

You're correct about some functions depending on what's visible on screen, it's even more complex than that: Some functions are affected by the "virtual" screen size - i.e. the portion of the drawing not requiring a regen when zooming. Things like interactive selection by crossing, trim, etc. seem to be affected. Painful, but such it is

Perhaps zoom to an even greater size than you think might be required. That way you may reduce the number of zooms.

I'd have to check deeper into the zoom command, but this process creates a drawing which has three orthographic views of a large assembly. The zoom all or zoom extents only works for the size of the drawing at the time it's requested. Again, the whole process happens in the blink of an eye, but a zoom request is made and then .002 seconds later, now that the drawing is much bigger, another request is made for zoom+all, etc... I think in all I zoom+All four times to get this where it needed to be. The trimming actions are a real pain even without the zoom because I have to get it down to the 1/32" sometimes less, and the angles are sometimes 6 decimal places to get it where the trim fences and what's selected to be trimmed will end up correctly drawn.