Jump to content

Multiple selections by marquee


Recommended Posts

<<Try using the Alt key + marquee for multiple selection.>>

Thanks for suggestion. I believe that is a different sort of function, though. Alt windows = option mac. This form of multiple selection selects everthing *touched* by the marquee. What is missing, that we used to have, is a way to limit the selection to objects *totally within* the marquee. Again the problem is that picking up objects missed on the first pass deselects the objects selected on the first pass. It's funny for a while.

Donald

Link to comment

I use click click mode. With the selection cursor the convention has always been: Hold down shift key for multiple selections.

Holding shift key down does not work for multiple selections when using a marquee. If a marquee encloses an object previously selected, it will deselect it. It should remain selected. The only way I see to make multiple selections is to hold the shift key down and select every individual object.

This is pretty unworkable when the need is to select a few hundred objects and the desire is to use a marquee to select some objects and avoid selecting others.

Regards,

Donald

Link to comment

I've noticed this too. It worked correctly in VW8. NNA says they changed this to be more consistant with other applications, but in my opinion the multiple selections by marquee is useless in its present form. There is no reliable way to know what you've selected. At the very least I'd rather have this option as a preference.

Link to comment

I agree that the marquee selection of 8.5.2 was more predictable and would like to see it come back.

Until then I have noted and use the following actions, which may be of use.

1. shift + marquee will retain previously selected objects if they are NOT fully enclosed by the marquee.

2. ctrl + marquee will retain previously selected objects if they are fully enclosed by the marquee.

The shift or ctrl key can be selected after the marque has been drawn, but before releasing the mouse button, so the appropriate key can be selected. smile.gif

Link to comment

I can explain our reason for making this change and would be interested to hear your comments. A big part of VectorWorks 9 was a push to standardize our interface to match OS UI conventions on both platforms. For years, new users have complained about the shift-selection behavior being non-standard. Two particular points were cited: shift-click and shift-marquee behaved iconsistently (one toggled the selection, one extended it) and that the shift-marquee behaved differently from other Macintosh applications (including the Finder!).

When we investigated this further, we found a clear reference in the Apple interface guidelines, also probably explaining why we don't work like other drawing programs on the Macintosh.

These inconsistencies are the kind of things that make a product very difficult for new users to learn and adopt. If you've ever used a program that didn't properly support shift and cntrl selection operations in lists, for example, you've experienced the same type of frustration that new users were facing with MiniCAD and VectorWorks before the current version.

Regards,

Sean

------------------

Sean Flaherty

CTO

Nemetschek North America

flaherty@nemetschek.net

Link to comment

Sean,

Thanks for the information on why the change was made. Thats helpful. I guess I'd just like the selection behavior to be a preference, if possible (like the click and drag preference). What happens over and over in 9 is I select a bunch of stuff, then I try to select more stuff, but some of the stuff I selected the first time is deselected and I'm not sure what stuff is selected anymore. I could group it to find out whats selected but then all my stuff is put in the active layer so that dosen't really work. And when I'm dealing with a whole lot of stuff, looking for all the selection handles is impossible. Does that make sense?

I'm also not convince the typical behavior for an operating system is most appropriate for cad application. I don't recall having any problems understanding the selection behavior when I was initially training on MC 4 years ago. But I also crossed from PC to Mac at the same time, so maybe I just wasn't used to it anyway.

It's kind of like the Trim command being removed. No offense but I don't think programmers can fully understand how users think (and vice versa), so what seem like a good Idea from a programmers perspective my not have a practical application for the users. ( then again what a user wants may be impossible or impractical from a programmer perspective) For me and most of the users I know the Trim command is used constantly. It's an unbelievably useful command, which I suddenly realized how much I used once it was gone. So thank you for putting it back in 9.5 (or so I've heard)

Over all the selection change and the Trim command are really the only things that I have any real serious problem with in 9. Other than that its a really exciting improvment. I've just started to assign modifier keys to my short cuts, that alone is a really cool feature. So thanks again,

Link to comment

Mike,

The Trim command will definitely be returning in 9.5 (due this fall).

Your comment about preferences though hits one area of software design that I think is a problem with many applications now. If we added a preference for every time we changed a behavior, VW would have HUNDREDS of preferences. We hear constantly about the complexity of our competition and strive constantly to avoid a situation like the "system variables" that exist in AutoCAD. I've also seen legacy applications fade away under their inability to move forward any more since they have to maintain so many old and unused branches of code. Have you ever had the feeling when running a Microsoft application that it will do exactly what you want...if you could just find that preference setting you need?

Where there are clear consistencies in UI paradigms I think we should take advantage of them. Preferences are useful when there is no clear "correct" behavior and several paths are required by different user sets. That being said (sometimes it is good to hear the philosophy!), you seem to making a case for this behavior being a preference. I'll keep listening to users and see whether this should be added in an update as well.

Best Regards,

Sean

------------------

Sean Flaherty

CTO

Nemetschek North America

flaherty@nemetschek.net

Link to comment

Good to hear Sean chime in here.

In my opinion the main problem with the shift+marquee behavior now, is that if we enclose an object in the second pass, that was selected in the first, it is deselected.

A marqee should not deselect objects.

Clicking in one spot (on an object to deselect a particular object, or on the drawing to deselect all selected objects) should deselect objects.

We lost a way of selecting things that was useful and cannot be replicated by any workaround.

As to the issue of intricate preferences, it is perhaps made out to be a bigger problem than it really is. The default mode should simply be the most common or easiest one. So people who like to keep it simple do not need to dig down into preferences.

Flexibility via preferences lets the program bend and conform. I think flexibility gives a more broadly useable tool. A deeper better tool.

If autocad is an example of how not to arrange preferences, (I don't know personally) it may not really follow that deeper tool options make a tool less useful. As a foil to autocad, I think formz can be seen as an example of how interface structure can support tremendous flexibility. Yes, there is a lot to absorb, but I found that once a basic understanding is found, working with the tools are like listening to the radio while driving the car. It may look complicated, but I can make 3D models faster, more precisely, and more easily than anything else I have tried. If I go to the formz message board, I don't see users complaining about there being too many options.

There must be something about how information is structured in interfaces that makes the difference between something that is really useful and something that is impossible to work with. When I speak here of preferences, what I mean is a way to have the program work the way I prefer, it doesn't necessarily mean that the choices occur in the vectorworks or document preferences. It is an interface design problem.

If there is a theme here on the user's side, it sounds to me more like "we like choices," than "we like standards."

Regards,

Donald

Link to comment

Very thoughtful comments all. The simplicity we may all be searching for is found in a -command-letter- keystroke like the dearly departed Trim command. At baseline logic, I too believe the marquee rope movement should not deselect. Deselection should be as simple as an empty mouse click. I will pray for the trim command to rise like the phoenix in the fall.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...