About   |   Getting Started   |   Downloads   |   Documentation   |   Forum


Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
mouse drag trail
07-28-2016, 07:23 PM
Post: #1
mouse drag trail
I'd hoped that ArtboardPointVector and the function mouseDownLocs() collected the points where the mouse was dragged, but after experimentation it appears I was wrong--the initial point is all there is.

If a tool does things to various art during the drag events, it's apparently all undone after dragging. In the mouseUp callback, the user's actions with the tool have to be recreated, but is there a way to retrieve the path where the user dragged the tool? It would be fantastic if there were, and in addition some way to temporarily suspend the auto-undo feature to support a variety of tool behaviors. Thanks in advance.
Find all posts by this user
Quote this message in a reply
07-29-2016, 08:54 AM
Post: #2
RE: mouse drag trail
It later occurred to me that as I drag, I could probably save relevant info in my own vectors and other variables. The scope of the automatic undo probably is limited to what happens on the screen and in the artwork tree; is that right?
Find all posts by this user
Quote this message in a reply
07-29-2016, 09:41 AM
Post: #3
RE: mouse drag trail
(07-29-2016 08:54 AM)Rick Johnson Wrote:  It later occurred to me that as I drag, I could probably save relevant info in my own vectors and other variables. The scope of the automatic undo probably is limited to what happens on the screen and in the artwork tree; is that right?

I was going to suggest that as a solution to your problem.

And as far as I know, yes, Adobe only "throws out" the artwork changes that occur during a drag operation when the undo API is called.
Find all posts by this user
Quote this message in a reply
07-31-2016, 09:53 AM
Post: #4
RE: mouse drag trail
Thanks, Garrett. That approach ultimately worked, although not quite as visually intuitive to the user as if deleted objects stayed deleted as the user dragged. I ultimately stored the hit points as well as the mouse trail in ArtboardPointVectors. It seems to me an iterator would be more elegant than a vanilla for loop, but here's what I did:

Code:
            // ArtboardPoint vector named hitPoints
            long numPts (hitPoints.size());
            for(long iter = 0;
                iter < numPts;
                iter++){
                hdi::core::HitData aHit(NULL, hitPoints[iter], hdi::core::SegPointOrInteriorHitRequest, 2);
                if ( aHit.hit()) {
                    if (aHit.art()->artType() == hdi::core::ArtTypePath) // or other conditions tested
                        // do stuff
                    }
                }
            }

I'm too embarrassed to admit how much time I spent trying to use an iterator here--what I found in books, forums, tutorials, etc., didn't seem to apply here. Maybe what I came up with can be helpful to others as either a way to do this, or as a clumsy way not to...

For the "scribble" type mode, I'd have liked to use a Polyline variation of the Polygon in the Draw class, but short Line segments worked fine for the visual representation of the mouse trail.

To make deleted art disappear again during subsequent drags I considered storing a vector of object references and re-deleting them each drag event, but experiments showed that they were drawn before they were deleted, ruining the effect. It also struck me that it probably wasn't safe or reliable to store references as they could change; empty objects could be tested easily enough, but duplicates with old IDs reassigned to new art could cause problems. It may not be as polished as I'd like, but it works!
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)