Luis and Joe, This what I needed!

;Use for 2d LINE points within xrefs or blocks.
;(matrix block_insertion block_point block_rotation)
;
(defun Matrix (ins pt ro)
(setq p1 (polar ins ro (car pt))
p2 (polar p1 (+ ro (dtr 90)) (cadr pt))
)
)

 

What doesn't seem to work?

I'm using 'NENTSEL' to select a LINE in an xref file,(in my case) and have
it position return relative to the current drawing mspace.

 

Yes, you're right.

I didn't add the other functions because I figured it didn't need the
mirrored, scale, but it does follow a rotated block or xref.

The others are just a matter of division or multiplication, and orientation
that could easily be added.

In fact, i will be adding those additional conditions later.

For the current utility it will work fine, but to be bullet proof, I know
I'll need to add those other fields.

Simple huh?

 

Rudy,

It may be simple for you, given your programming experience. But it ain't so on my
end, given my relative lack of such.

See the functions I posted this evening in your other thread about use of @PTrans.
For me, those three functions replace John Uhden's and Larry Leuallen's work, which
they so graciously shared. Not to mention functions I use by Vladimir Nesterovsky.

I'm just building on what others have done. Testing my approach would have been a
nightmare if I didn't have John's and Larry's functions as a benchmark.

Regards
Joe Burke

 

Sorry, I didn't mean to put anyone down.

 

Rudy,

I didn't think you were putting anyone down.

Joe

 

Just curious Joe, what do you think of my utility, and do you think I'm
reinventing the wheel?

 

Rudy,

I'm off to work right now. I'll have to reply later.

Joe Burke

 

Rudy,

It's certainly a unique approach I wouldn't have thought of. So in that sense... it's
not reinventing the wheel.

But I can't help stepping back from the details of threads subsequent to your
original, "Trans or other?" Where you said, "This must also take into consideration
that the xref can be rotated, mirrored or moved." I'm assuming you simply forgot to
mention scaled.

Both you and Luis have posted partial solutions to the more general issues at hand. I
have to ask, with all due respect, why bother with half-baked solutions when full
featured solutions are available?

Please understand, I don't mean to argue with you or Luis. I'm well aware both of you
are far more experienced with this stuff than I am.

BTW, the driving force behind ObjMatrix and InverseObjMatrix was not related to
translating points WCS<>OCS. That (the TransPt function) was a fringe benefit. My
primary goal was using these functions with vlax-tmatrix and the transformby method.

Regards
Joe Burke

 

Thanks Joe for your comments.

When I'm complete with the rest of conditions I'll post the code.

I hope you understand, to us it's a matter of condensing the code and making
it faster.

Let's say someone wrote a piece of code that would do some sort of function,
that was 1/2 a page long. More than likely we would try and simplify it and
condense it so that you wouldn't have to go through so many cycles were it's
just a waste of time.

To me, I'm always trying to find a faster method, without having to create
so many sub-functions.

 

Joe Burke wrote:

Joe.

Strange how things happen. I am the Larry Leuallen to whom you refer
above. I am glad that somebody got some use out of the functions I
developed. I remember John and I going at it here on the board.

I have been away from Acad programming since shortly after I wrote those
functions. To ice the cake, I recently had a house fire (bad) and lost
much of the data that I had developed over the years. I just got a new
computer and am in the process of piecing together what I can from
partially restored hard drives and smoky CD's (got to clean them
first!). So, anyway, I just got the newsgroups installed and was
scanning the messages when I saw my name and thought I'd say hi.

By the way, those matrix functions were developed for a personal project
I was writing. I was a comprehensive distance and angle function with an
ObjectDCL interface. Pick any object that had a length or angle and it
would return the length and angle and optionally store it for future
use. The matrix functions were required to get the length of curves that
were part of a block. Well to cut to the chase, I wanted the data to be
persistent across sessions by writing it out to a file and reading it
back in. That did not work because of round off errors. I'd have the
displayed distance 15.00000... and it displayed back as 15.00000...1 or
14.9999.... Ticked me off so I dropped the project. Other than that, I
never used the matrix functions I developed. It would have been nice to
pick a critical length from one Acad dwg and a couple of days latter
recall it with full precision and use it in another dwg.

If I get things sorted out I may rejoin the Acad programming community
and give that program another whack.

Peace and love,
Larry

 

Hi Larry,

Good to hear from you. I believe I joined the NG since you haven't been around. So
you are a bit of a mystery guru on my end.

Here's a twist. The reason I became interested in you functions was for a program
which measures the angle between two lines or pline segments. I wanted it to work
with objects in xrefs and blocks. It wasn't much use otherwise. So I incorporated
yours and John's functions. Eventually it worked well, thank you. BTW, I also store
the measured angle in a global symbol so it can be used to rotate objects by the
angle. Handy.

Regarding the accuracy issue, I'll suggest something you surely know. There's a
recent thread dated 9/28 named "mathematical anomaly". I posted a function there
which uses rtos to round off those kinds of errors. Basically process the number
using string functions and spit it back out with atoi in this case, or atof in your
case. I think something like that would fix the problem.

I'm certainly curious if you have an opinion about the matrix functions I posted
recently. I've since incorporated those into the angle function and others which need
similar transformations. For instance, copy an object from an xref using transformby
and vlax-tmatrix. The driving force behind those functions was to return a matrix or
inverse matrix simply by passing a block reference. Using them to transform a point
was sort of icing on the cake.

Hope to see you here in the future.

Aloha
Joe Burke