GETPOINT Fails error If I switch to another drawing in my VBA application

GETPOINT Fails error If I switch to another drawing in my VBA application

Anonymous
Not applicable
7,500 Views
23 Replies
Message 1 of 24

GETPOINT Fails error If I switch to another drawing in my VBA application

Anonymous
Not applicable

 

To place a drawing into another location using ALIGN I use an overall OS coordinate system drawing to get matching points to place the first drawing.

 

Both drawings are loaded into AutoCAD


I've created a combobox to switch drawings whilst my application is running and even ACTIVATE and REGEN the selected drawing:

ThisDrawing.Application.Documents.Item(ComboBox1.ListIndex).Activate
ThisDrawing.Application.Documents.Item(ComboBox1.ListIndex).Regen acAllViewports

The GETPOINT line is only successful in the drawing that was active BEFORE I started my application and Fails in the other activated drawing:

The error I get in all other drawings I select and activate:



Anyone any idea what's need to be set before I can use it in the newly activated drawing?

Thanks

 

0 Likes
Accepted solutions (1)
7,501 Views
23 Replies
Replies (23)
Message 21 of 24

Anonymous
Not applicable

Hi RICVBA,

 

Yep:

 

Tried it in AutoCAD 2016 and unfortunately the file I open or select is properly closed with the command Patrick posted, no error is generated if I attempt to close the file immediately after opening or lateron.

 

Thanks for pointing out. Will hunt further for the solution to Activate the drawing in a way to be able to use GetPoint in another drawing that the one I've started when initiating my routine..

 

Cheers, have a good one this weekend, yet another good year at our doorstep.

0 Likes
Message 22 of 24

Anonymous
Not applicable
Accepted solution

Hi RICVBA,

 

Just found the solution in AutoCAD2016:

 

Switching between opened drawings does cause the GETPOINT error.

 

So instead of opening all drawings I need to ALIGN, I only open the drawing that is to be ALIGNed.

 

I start my application => use GETFILE to open the Base drawing (where to get the base points to ALIGN TO from) => Activate that drawing => use GETPOINT to gather the three points I need => send them to the Windows Clipboard => Close this Base drawing without saving => proceed in the original drawing to use GETPOINT to point where the 3 base points refer to => carry out the ALIGNment based on this info => Check the three points by placing circles on the original coordinates from the Clipboard for QC purposes => close my application.

 

Somehow AutoCAD 2016 allows to activate a newly loaded drawing as the Current one for GETPOINT to function and when I close this drawing the originally loaded drawing is automatically Activated to use GETPOINT in too.

 

This solves my problem!

 

Thanks for thinking with me here, much appreciated!

 

 

0 Likes
Message 23 of 24

Anonymous
Not applicable

glad to see you made it

 

mark your post as the solution so that other people with the same problem can drop here more quickly

 

best wishes! 

0 Likes
Message 24 of 24

Anonymous
Not applicable

Hi

 

Just in case it's of any interest to you, I too was faced with the same problem of wanting to run a macro in one drawing then mid-program switch to a different drawing and get some points off screen.  The purpose of mine was to extract string data from one open drawing and drop it in to another open drawing, before returning back to the first drawing and getting more info.

 

The way I got round it was painfully simple in the end, although a tad crude.  By making the second drawing active, then using SENDCOMMAND to call a second module in the same DVB file, the program would essentially pause whilst the second macro ran. This allows for 'ThisDrawing' to be redefined as the second drawing so the user can pick the points on screen without any errors.  Once the second macro has finished it immediately hands control back to the first macro which subsequently carries on.

 

I used two AcadDocument objects rather than ThisDrawing, just to keep things neater, and ensured that the SENDCOMMAND was the final action of the first macro. By using public variables, data can be exchanged by both macros no problem. 

 

Like I say, it's a bit crude but seems to work really well.  Hope that's of help to someone.

0 Likes