Author Topic: Editor key strokes  (Read 3061 times)

0 Members and 1 Guest are viewing this topic.

poncelet

  • Guest
Editor key strokes
« on: March 11, 2012, 04:01:55 PM »
Hello guys,
I was looking this cool app by Lee Mac:

When the app is running the editor can accept keystrokes (hot keys).
Have anyone done something similar with .net during a jig or with an entity before gets committed?

vegbruiser

  • Guest
Re: Editor key strokes
« Reply #1 on: March 12, 2012, 06:03:54 AM »
That's a pretty cool demo; care to share the link to it? EDIT: All of Lee's work can be found here: http://www.lee-mac.com/programs.html - which one is this?

Lee Mac

  • Seagull
  • Posts: 12916
  • London, England
Re: Editor key strokes
« Reply #2 on: March 12, 2012, 07:43:06 AM »
That's a pretty cool demo; care to share the link to it? EDIT: All of Lee's work can be found here: http://www.lee-mac.com/programs.html - which one is this?

Thanks AlexF  :-)

I haven't uploaded that particular program to my site as yet, though a draft of the code can be found here.

Lee

kaefer

  • Guest
Re: Editor key strokes
« Reply #3 on: March 12, 2012, 11:57:18 AM »
Have anyone done something similar with .net during a jig or with an entity before gets committed?

Am I correct in surmising that you aren't interested in developing such an application yourself?

Rhetorical questions aside, for keyword entry use either the two-argument constructor of PromptOptions (or its derived classes), or manipulate the Keywords collection directly. This is the same all over the EditorInput namespace.

Alternatively you could implement System.Windows.Forms.IMessageFilter.

vegbruiser

  • Guest
Re: Editor key strokes
« Reply #4 on: March 12, 2012, 12:26:52 PM »
That's a pretty cool demo; care to share the link to it? EDIT: All of Lee's work can be found here: http://www.lee-mac.com/programs.html - which one is this?

Thanks AlexF  :-)

I haven't uploaded that particular program to my site as yet, though a draft of the code can be found here.

Lee
Much obliged Lee, Thanks. :)

And (thinking out loud) the kind of flip-flop functionality exposed by this tool is similar to that which can be found inside Autodesk Inventor - wherein the command (end-result) options can be edited from a MiniToolbar (they could be edited from a userform in older versions of Inventor; IMO the MiniToolbars are nicer) - perhaps OP could create the same/similar for this tool?

poncelet

  • Guest
Re: Editor key strokes
« Reply #5 on: March 12, 2012, 01:38:53 PM »
Have anyone done something similar with .net during a jig or with an entity before gets committed?

Am I correct in surmising that you aren't interested in developing such an application yourself?

Rhetorical questions aside, for keyword entry use either the two-argument constructor of PromptOptions (or its derived classes), or manipulate the Keywords collection directly. This is the same all over the EditorInput namespace.

Alternatively you could implement System.Windows.Forms.IMessageFilter.

Why the question then?

TheMaster

  • Guest
Re: Editor key strokes
« Reply #6 on: March 12, 2012, 09:10:49 PM »

When the app is running the editor can accept keystrokes (hot keys).
Have anyone done something similar with .net during a jig or with an entity before gets committed?


You might not need to go through all of that.

Put the objects in a temporary block, and handle the RXClass.EntityAlignment event on the RXClass for the BlockReference object (AcDbBlockReference). 

The code you cite is a 'cute' trick  (I did a dynamic move/rotate/mirror command in LISP and ActiveX too using my AcadX library), but the problem there is that it can generate a massive amount of UNDO information when the block that's being manipulated is database-resident, unless the programmer understands that and knows how to eliminate it (by using and aborting a transaction before/after the dragging is done). And the other problem is that when it is done purely in LISP, by looping over calls to  (grread), there is no osnap or other drawing aids available, which AFAIK, is a deal-breaker, so grown-up tools are better suited for a job like this.

« Last Edit: March 12, 2012, 09:20:05 PM by TheMaster »

poncelet

  • Guest
Re: Editor key strokes
« Reply #7 on: March 12, 2012, 09:38:00 PM »
Yes i see. By the way this moving text is a jig? I have no idea about Lisp.

Lee Mac

  • Seagull
  • Posts: 12916
  • London, England
Re: Editor key strokes
« Reply #8 on: March 13, 2012, 07:40:02 AM »
And the other problem is that when it is done purely in LISP, by looping over calls to (grread), there is no osnap or other drawing aids available, which AFAIK, is a deal-breaker, so grown-up tools are better suited for a job like this.

Agreed. Consequently, I rarely use a grread loop for anything other than fancy selection interfaces (where OSnap and other drawing aids aren't required), or for Text placement utilities, such as the above, where positioning is perhaps not so critical.

kaefer

  • Guest
Re: Editor key strokes
« Reply #9 on: March 14, 2012, 01:16:46 PM »
Put the objects in a temporary block, and handle the RXClass.EntityAlignment event on the RXClass for the BlockReference object (AcDbBlockReference). 

Barring the provision of a custom object, that would work exclusively when grip-editing the temporary block?

You made me curious; but it seems that grip-editing a BlockReference whose definition includes an Alignment parameter is currently the only way to access this feature from .NET.

TheMaster

  • Guest
Re: Editor key strokes
« Reply #10 on: March 14, 2012, 03:11:57 PM »
Put the objects in a temporary block, and handle the RXClass.EntityAlignment event on the RXClass for the BlockReference object (AcDbBlockReference). 

Barring the provision of a custom object, that would work exclusively when grip-editing the temporary block?

You made me curious; but it seems that grip-editing a BlockReference whose definition includes an Alignment parameter is currently the only way to access this feature from .NET.


If I recall correctly, I used an empty dynamic block with an alignment grip/parameter at the origin. The user's selection was cloned into the dynamic block's definition, and an insertion of it replaced the user's selection. They could then grip-edit the insertion, and when they finished, the insertion was replaced with the original entities transformed accordingly. I used the QAFLAGS trick to activate grip editing for the block insertion.

The idea was to make a dynamic move/copy/rotate command that allowed the user to pick the objects to be moved/copied/rotated, along with an alignment reference curve (or an alignment vector) that defines the alignment, and they could then edit the objects like it was an insertion of a dynamic block with an alignment parameter.

That work was focused on dynamic alignment in editing of existing objects rather than initial placement (which alone may be novel, but not terribly practical).

It should go without saying that all of that can be done using Jigs