Using osnaps inside GRREAD loop ?

Is there a means to have osnaps active within a (grread) loop ?

I am trying to use grread loops to create custom LINE, PLINE and INSERT
commands with some additional features. The only drawback I cannot seem
to find a solution for is that there doesn't seem to be any way to
use osnaps while in the grread loop. Did I miss something here or is
this just not possible ?

Thanks

Jesse

 

GRREAD has far more problems than you've noted.

The user doesn't have any use of the keyboard for
anything (such as coordinate entry format options,
direct distance entry, immediate osnap, point
filters, etc.), that is, other than what's manually
implemented (i've seen attempts at it, and never
did one come close to complete emulation).

There is no support for polar snap/tracking, object
tracking, auto-tracking, osnap markers, and so on.
There is no support for menus (including the mouse
buttons) at all.

Given that its either impracticle or impossible to
support the aformentioned features, GRREAD is not
what I consider an acceptable way to emulate AutoCAD's
standard coordinate entry mechanism, if that's what
the intention is.

The only place where it is useful is in things like
SKETCH, and REVCLOUD (e.g, where 'precision' is not
a primary concern).

 

This is my observation as well, however there are some other instances
where its been working very well. Many of the aforementioned problems
were circumvented by adding conditional statements for particular key
presses then either reacting directly or dropping into a subprompt for
user input, for example: grread command prompt [Regen/Axis/Zoom/Point]
pressing A (Axis) would alternate the forced origin axis of the line in
progress between X and Y, pressing Z (Zoom) would drop into a command
loop (vl-cmdf "_.rtpan"). Pressing P (Point) would drop into a
(getpoint) loop for user input, and so forth. It doesn't take long to
realize one has opened up a real can of worms in taking this approach
because now everything normally available at the AutoCAD command prompt
must be emulated, and many of the standard features are not available.
Its a real tradeoff in deciding if its worth the effort since creating a
grread loops does offer some attractive possibilities such as using the
(nentselp) function with a point argument taken from the mouse position
tracking argument of (grread) to detect drawing objects on mouse-over
and, for example, (entget ename '("APPNAME")) extracting application
data and displaying it to the AutoCAD command prompt or bubble text
using (grvecs). Again on the downside, this effectively creates another
entry system alltogether which is dissimilar from AutoCAD's standard
entry system, and takes the user a little getting used to. Fortunately
those testing the programs haven't had any problems or suggested its all
that awkward to use, infact many have liked the extended functionality.
But its certainly come with a heavy development cost. Given the above
functionality, I've considered the idea of emulating object snaps as
well, but I had really hoped to avoid having to.

The only other possibility I can think of for creating an entry system
which more closely matches AutoCAD's native entry system is by using
AutoCAD's native commands directly (i.e. LINE) and triggering a series
of reactors (e.g. :vlr-commandBegin and :vlr-commandEnded) which in turn
perform any interrim operations needed to the newly created objects and
re-initiate another call to the command which triggered the reactor.
But here again this also presents its own world of management problems.

Would you have any other suggestions ?


Regards,

Jesse Danes

 

You have to be clever. Yes, it's a lot of work because you have to emulate what
might otherwise be available. You have to weigh the benefits vs. the deficits
and come up with what works best (as close as you can get). If you checkout my
LABEL_IT routine, there is some emulation that Autodesk doesn't naturally
provide, namely showing both endpoints of a segment. Yes, it uses (grread) and
yes, it was a pain in the butt.

 

You're probably not going to like this, but I'm going to
say it anyway....

While it may be your opinion that resorting to kludges
only to make it possible to support other kludges, like
displaying entity data in a bubble using (grvecs), and
regard all of it as acceptable, my opinion is that opinions
about how to correctly solve problems seem to be designed
to serve the interests of the problem solver, rather than
the interests of those who need and use the solution.

That is mainly because in almost every case, those opinions
serve the need to avoid having to acknowledge that while
there is a better solution to a given problem, the one who
is responsible for solving the problem one may not have the
prerequisite skills and experience with the tools needed to
realize that superior solution.

When there is problem that must be solved, which would require
me to resort to totally unreasonable kludges, in preference to a
superior solution which requires the use of tools that may
not be within my own skills set, I have no choice but to do what
I regard as the professionally and socially responsible thing,
which is to swallow my pride and muster the courage to tell
those who are signing the checks, that they need to seek out the
services of others who are qualified to use the tools needed to
solve the problem, THE RIGHT WAY.

If I were to propose and attempt to defend outrageous kludges
as the preferred means of providing a relatively inferior solution
to a problem, and did so only to protect myself; to serve my own
job security interests; or avoid having to acknowledge that I do
not have the required skills and experience using the right tool
for the job, I would call that fraudulent; a betrayal of those who
depend on me and sign my paycheck; and highly detrimental to those
whom I work with and/or serve.

That is why I have long since concluded that the 'clever' thing
to do, was to emerge from a virtual state of denial about my own
lack of skills; bite the bullet, and learn to use the right tools
needed to do job the way it should be done, rather than subscribe
to some rediculously egotistical idea that the need to credit myself
with the solutions, is far more imporant than the soundness and
quality of those solutions.

That's about all I have to say about this.

 

Having thrust myself uninvited into previous threads you
have participated in and offered my opinion, whatever that
may or may not be worth, I have to comment here, if for
nothing else than to satisfy my own sense of fairness.

Having said that, I must say that I agree with the core
principles of your post, despite the fact that portions of
this may in fact apply to myself.

You're probably not going to like this, but I'm going to
say it anyway....

While it may be your opinion that resorting to kludges
only to make it possible to support other kludges, like
displaying entity data in a bubble using (grvecs), and
regard all of it as acceptable, my opinion is that opinions
about how to correctly solve problems seem to be designed
to serve the interests of the problem solver, rather than
the interests of those who need and use the solution.

<snip>

 

Having said that, I must say that I agree with the core

The truth of the matter is that they apply to all of us,
myself included. It's not a question of black or white,
because we all have conflicting interests. it's more a
matter of how we manage those confecting interests, and
the extents we will go, to cater to our own interests,
and risk the possibility of becoming practitioners of false
or semi-legitimate ideas.

I realized long back that it became much harder for me to
justify 'kludgy' solutions like those discussed in this and
other threads, that were limited to only those tools I was
most familiar with. That's why I concluded that it was time
show some intestinal fortitude, and emerge from the security
of that cozy little sandbox.

I like having the run of the entire beach much better than
having to continuously put forth semi-legitimate arguments
in defense of the idea that my customers should have to bear
the consequences of my choosing to remain in the confines of
that same stupid little sandbox.

I also recognize that there are some old dogs that seem to
have a much harder time learning new tricks. I have little
compassion for them.

It's survival of the fittest. Either adapt to change, or
risk becoming a footnote in your own book.

 

those confecting interests

See what happens when I use a spell checker?

 

I do not know the full history of the parties you may be
making reference to - is it possible said parties are in
fact learning new technologies but are not yet in a state
such that those technologies can be implemented with full
confidence; in the interim the "old kludges", while admittedly
inferior, still get the job done?

I think the concept you've illuminated the most in these
forums is the need to consider every possible facet of an
issue.

 

Great points Tony. Thanks.

BTW: Are you advocating Objectarx or something else?
Where's the beach? I'm ready for some surf. ;-)

Regards,
Doug

 

Thanks John

Its good to actually have someone offering usefull advice amidst all the
clutter in this newsgroup.


Regards,

Jesse Danes

 

I asked if you might suggest other solutions. This reply is nothing
more than a longwinded superiority trip and veiled slander. In fact
I've never seen a reply from you that had anything usefull or
intelligent to say except to slander, rant, cut down or present yourself
as the ultimate authority on all things AutoCAD. I ask only one more
thing of you, and that is that you restrain yourself from replying to
another one of my posts in this lifetime.


Regards,

Jesse Danes

 

<rubbing eyes, head shake>

I don't get the <snicker> part, then again it's 5:25am here
and I just got up.

I understood Tony's post to mean that serious development
frequently requires the use of languages or tools the
developer does not have expertise with. If said developer
wants to survive one has to "bite the bullet" as it were and
acquire those skills. In this case it could be C++, in
another it may be C#; yet in another it may be how to use
functionality in the Windows API, using any language that
supports that. In the absence of those skills, resorting to
kludgy work arounds, espousing those techniques as somehow
secret and superior, and subsequently being trapped by the
protectionist philosophy one may exhibit as a result of
possessing a limited skill set is what I believe he's taking
exception to and addressing.

But I'm sorry I don't know what "play with the big boys"
means.

Thanks,

Michael.

Medic: Can we get some coffee over here?

 

Sometimes condescending, sometimes acerbic, sometimes, well enough
of the compliments, but "nothing useful or intelligent to say"?
Sorry, I have to disagree.

Before you start thinking I'm going for brownie points I'm not, and
you'll need to examine my posting history to determine that for
yourself. Tony and I have had famous fights, sadly, right here in
front of everyone but I've learned to just let them go. Fight again?
Ackkk, I don't want to, but alas, we may. But I digress.

If you remove your ego out of these discussions, and trust me, that
is not easy, an ongoing challenge, and a indeed lesson in itself, you
can find pearls in his discussions.

 

Ackkk, replace "out of" with "from".

 

I should have been more clear in saying his replies to 'my posts' which
for the handfull they have been, perdominently follow this line of
abnoxious behaviour. For the 1-5% of usefull information that could be
extracted from the ramaining 95-99% attitude problem, it simply isn't
worth anyone's time, mine yours or even his. And yet he has made
sweeping and decisive conclusions about circumstances and facts he
really knows nothing about. What he thinks of as 'kludges' I would be
more inclined to suggest are lack of imagination and innovation on his
part. As nice as it might be to have the ease and luxury of using the
'right' tools, realistically we just don't have the time schedule
available to retrain and rewrite 20,000 lines of code.

Simply put his attitude is just uncalled for and not needed. I learned
a long time ago that its not how much you know that matters, because
comparatively any one of us knows very little at all. But what's
important is how its used and presented to others that makes all the
difference. Making the complex simple, or presenting broad concepts
with brief and immediate clarity. And above all, doing it with a well
rounded and positive attitude; these are the hallmarks of wisdom and
genius. And in all these areas he receives a very generous F. Although
someone can be an expert on trees, they can still miss the forrest.

Well that said I will end this post on a note of philosophical humor ...

"If tony is speaking in a forrest and there's no one there to hear him,
is he still abnoxious ?"



Regards,

Jesse Danes

 

In thinking about it, although it made me chuckle at the time, that last
remark about 'speaking in a forrest' was probably uncalled for as well.
So for that i offer my apologies to the group.


Regards,

Jesse Danes

 

With an apology offered and rather than pick/chose/delete any
personal references to anyone in this discussion, all messages
were left. Equal give and take on both sides, everyone picked on
equally. And now back to code please?

 

Jesse -

You are new here. Most folk posting here have been doing so from
back when the Autodesk discussion groups were on Compuserve at
300 baud rate and $12 an hour. Please let the occasional personal
remarks slide by and concentrate on the code give/take. It's not
worth replying.

 

I advocate whatever tools are suitable to the task.

While there's plenty of relatively simple customization
that can be handled entirely in LISP, that's not what
I take exception to. If LISP can do the job without the
need for major comprimises, then by all means, use LISP.

What ruffles my feathers is the suggestion that blowing
away basic AutoCAD functionality like OSNAPS and so
forth, mainly for the purpose of supporting other kludges
(e.g., a kludge-o-rama) is somehow justifiable.

A willingness to take LISP to extremes like displaying
tooltips or bitmap cursor glyphs using grvecs, etc., and
to comprimise basic AutoCAD functionality to realize all
of the kludges, should be viewed as precisely what it is,
a symptom of another kind of problem.