Manipulating options during [GRREAD]

[Muhammed.OPERA]

Hi everybody,

I've been using (grread) function and i managed to manipulate everything if the answer to the function is by picking a point or typing a string in the command line but here's the problem:

If i clicked any button in the text printed during the work of (Grread) function, it always returns (11 -1) and that return doesn't change with changing the clicked button.

How can i determinate which button the user clicks from the command line to know which rootline to take ????!

Thanks in advance.

[john.uhden]

I love grread.

When you say "clicked any button in the text printed during the work of (Grread) function"

do you mean a text object in the drawing, or text in the text screen, or something else?

I would have to look at some old work of mine, but I seem to recall certain codes send a second code, or something like that.  I don't remember about 11.

Sorry I can't look now; I'm being called for dinner.

[Muhammed.OPERA]

Thanks for your concern, take your time.

I mean user clicks a button in the command line like that:

(princ "\nSelect column type [Points / Select rectangle / Undo]: ")

The grread function always returns the same (11 -1) with every command line option whether i choose Points or select rectangle or Undo, from the command line.

I managed to manipulate what to do if user clicks a keyboard button like P , S or U that's easy cause the return includes the ascii code for the entered character but if i clicked the option from the command line here's the problem.

Try it and please help cause i got stucked  here.

[Muhammed.OPERA]

Try this and see the return:

(defun C:opgr (/ A B C)
  (setq B "Points"
	C "Select rectangle")
  (while
    (princ (strcat "\nSelect option [" B "/" C "]: "))
    (setq A (grread t))
    (princ A)
    (princ "\n")
    (princ)
  )
)

---

[Kent1Cooper]

---

@Muhammed.OPERA wrote:

....if the answer to the function is by picking a point or typing a string....

How can i determinate which button the user clicks from the command line to know which rootline to take ????! ....

---

By using (initget), even allowing arbitrary input if you like, rather than (grread).

(initget 128 "Option Choice Variable")

(setq pt (getpoint "\nPick point or [Option/Choice/Variable]: "))

(cond

  ((listp pt); they picked a point

    (... do whatever with a point value ...)

  ); picked-a-point condition

  ((= pt "Option")

    ; they picked on that in the prompt line, or typed in "O"

    ; [not case-sensitive] or any amount more of the word

    (... do whatever the "Option" choice dictates ...)

  ); chose-"Option" condition

  ((= pt "Choice")

    ; they picked on that in the prompt line, or typed in "C"

    (... do whatever the "Choice" option dictates ...)

  ); chose-"Choice" condition

  ((= pt "Variable")

    ; they picked on that in the prompt line, or typed in "V"

    (... do whatever the "Variable" choice dictates ...)

  ); chose-"Variable" condition

  ((= (type pt) 'STR)

    ; they typed some string other than one of the listed options

    (... do whatever that string dictates ...)

  ); arbitrary-text-string condition

); cond

If you don't want them to be able to type in anything other than the offered options, omit the 128 and the last condition.  It can still accept either selection or typing of listed options or picking of a point.

[_Bilal]

One more question...

How to use the object snap modes (end, intersection, mid ....) to select a specified point in the grread (while loop)?

I personally prefer the Lee Mac GrSnap code to display a marker when you move the cursor over an object snap location.

[john.uhden]

You keep using nentselp while tracking and derive the endpoints yourself.
Then you add glyphs and remove and add, etc. with each change in cursor or
viewctr/viewsize. Endpoints and midpoints and nearest are easy, but I've
never tried intersections.

[ВeekeeCZ]

---

@Muhammed.OPERA wrote:

Hi everybody,

I've been using (grread) function and i managed to manipulate everything if the answer to the function is by picking a point or typing a string in the command line but here's the problem:

If i clicked any button in the text printed during the work of (Grread) function, it always returns (11 -1) and that return doesn't change with changing the clicked button.

How can i determinate which button the user clicks from the command line to know which rootline to take ????!

Thanks in advance.

---

I've come cross this lately (it's THIS routine) and I think it's not possible. It's not compactible. Can't have everything.

[john.uhden]

Now I remember.
Code 11 represents input from an AUX menu item.
Forget about it. I didn't save any of my efforts to decipher what the
second value means because I just got lost in trying to read menu items via
AutoLisp. Not that it can't be done, just not by me 'cause I'm not a
masochist.

[Muhammed.OPERA]

@Kent1Cooper Thanks for your concern.

But that's not what i'm asking for. The [Initget] function can't be used inside grread.

That's the same for [Getxxx] functions, these can't be used while grread is active.

[Muhammed.OPERA]

@ВeekeeCZ Thanks for your concern.

I have tried ur code but it have the same problem.

It work perfect if user clicks a keyboard option like M, R or C but if user used the mouse pointer to select copy or move from the command line inside ur code, the command will come to an end.

Try it yourself.

[Muhammed.OPERA]

@john.uhden  Thanks a lot for ur concern 

I'm so sad to hear that cause i don't know what to do.

If you know anyone can help me with that matter please mention him cause as i said i got stucked in that.

[CADaSchtroumpf]

---

@Muhammed.OPERA  a écrit :

Try this and see the return:

I'm not sure I understand your request (initget) would be simpler ...

This?

(defun C:opgr (/ A B C)
  (setq
		B "Points"
		C "Select rectangle"
	)
	(princ (strcat "\nSelect option [" B "/" C "]: "))
	(while (and (setq A (grread T 4 0)) (not (member A '((2 112) (2 80) (2 83) (2 115))))))
	(cond
		((or (equal A '(2 112)) (equal A '(2 80))) (setq A B))
		((or (equal A '(2 115)) (equal A '(2 83))) (setq A C))
	)
	(princ A)
	(prin1)
)

[Kent1Cooper]

---

@Muhammed.OPERA wrote:

.... that's not what i'm asking for. The [Initget] function can't be used inside grread.

That's the same for [Getxxx] functions, these can't be used while grread is active.

---

Yes.  I was suggesting an approach that does not use (grread), but I think gets you the information you want [if I understand correctly].  Is there some reason (grread) needs to be the method?

[ВeekeeCZ]

---

@Kent1Cooper wrote:

---

@Muhammed.OPERA wrote:

.... that's not what i'm asking for. The [Initget] function can't be used inside grread.

That's the same for [Getxxx] functions, these can't be used while grread is active.

---

Yes.  I was suggesting an approach that does not use (grread), but I think gets you the information you want [if I understand correctly].  Is there some reason (grread) needs to be the method?

---

The most obvious motivation of using GRREAD in menu is that you don't need <enter> confirmation - you just hit a letter key and that's it. For that reason it's pretty fast. At least that's the reason why I have used this in my routine linked above.

But what the OP want's is not possible. He does not read or understand what I have said before.

[Kent1Cooper]

---

@ВeekeeCZ wrote:
....

The most obvious motivation of using GRREAD in menu is that you don't need <enter> confirmation - you just hit a letter key and that's it. For that reason it's pretty fast. At least that's the reason why I have used this in my routine linked above.

....

---

I have never considered that {Enter} confirmation any kind of "burden," since all AutoCAD commands work that way with typed-in options [as well as for typing in command names, and Osnap modes, and so on], so people are accustomed to it.  And in the (initget) approach it can still be a one-step operation [no {Enter} confirmation] by picking the option in the prompt [also as in AutoCAD commands that have options].  Another big advantage of the (initget) approach is that you can have more than one option starting with the same letter, with more-than-one-letter option abbreviations [as in, for example, the -LAYER prompt].

[john.uhden]

@Muhammed.OPERA 

You don't need initget and kwords.  Grread takes input keystroke by keystroke giving you (as the coder) the opportunity to react to almost anything (except '(11 #)).

Yes, there is more coding involved, but you don't need separate functions for getthis and getthat, and an Esc doesn't have to stop anything unless you want it to; it's just a '(2 27) I think.

[Kent1Cooper]

---

@john.uhden wrote:

You don't need initget and kwords.  Grread takes input keystroke by keystroke giving you (as the coder) the opportunity to react to almost anything (except '(11 #)). ....

---

Which means exactly that they do need something other than (grread) for the situation where it returns (11 -1) as described in Message 1 [and see @ВeekeeCZ 's two Messages].

And another reason:  Suppose you build a routine that needs multiple options beginning with the same letter, similar to the -LAYER command's prompt that offers Ltype, LWeight and LOck.  Ltype is considered the most-used of the three, so it gets the L-alone option abbreviation.  If it were built using the (grread) approach with immediate reaction to a keystroke without {Enter/space} to "register" it, if you wanted L-alone to trigger the Ltype option, you would not be able to access the LWeight or LOck options!  They would need to structure the reaction to the L keystroke to not go immediately into the Ltype option, but to await some confirmation that you want that, and not LWeight or LOck.  So it would be back to needing {Enter/space}, which I think would be confusing if it was needed for some options but not others, and it would be better to require it for all, just as all AutoCAD commands do.

[ВeekeeCZ]

@Kent1Cooper 

I don't know what happened here... nobody suggested to use the grread for the -layer command.

All I have said was, that I can imagine that the speed may be the reason for GRREED usage - as in my case that was MOCORO+... or let's take THIS ONE  Lee's tool... it would be a total nightmare with classic initget approach.

But who knows what tool the OP builds... he just might build some cool tool with a nice dynamic preview and wants to have some more options available on the command line... as simple as that.

And BTW - Don't really understand why you consider a big advantage ability to have more-than-one-letter options... If I would really prefer the speed of it (as my MOCORO+), that would be the 1st thing that I would change - make them single-letter keys (which I did in MOCORO+). The key letter could be the less typical, it may not match the classic PGP abbreviations... but unique, preferably with some logic in it, possibly all letters close to each other on the keyboard (again, as my MOCORO+)... I would get used to it soon because it would be fast and convenient. But this is far off-topic.

[Kent1Cooper]

---

@ВeekeeCZ wrote:

I don't know what happened here... nobody suggested to use the grread for the -layer command. ....

---

No, it was just an illustration of something people are familiar with, that has multiple options starting with the same letter, with one option being the single letter alone, and others being that same letter followed by more.  [I did describe the problem with a conditional: if the -LAYER command had been made using the (grread) approach for immediate effect at key-stroke without {Enter/space}.]

Any routine that someone might build in which that kind of options breakdown would be appropriate will have the problem, using the (grread) approach, of not having access to some of the options, except by requiring confirmation when they want the one with the single-letter abbreviation.

The -LAYER command could presumably be made to use that approach by restricting itself to one-letter option abbreviations, but it has so many options sharing so many letters that it could be difficult.  Presumably ON could instead be On using the O only, but then OFF couldn't possibly be anything except oFf, and then Freeze couldn't use that F, so it would need to be something else, presumably freeZe, [since E is used for rEconcile, and that only because R was already taken for Rename], etc., etc.

The (initget) approach avoids all such difficulties, along with having things operate as all native AutoCAD commands that have prompts with options operate, which I personally think is worthwhile in itself.