Best Of

@Philip_Thomas_PTC I think that's a very sensible rollout strategy. I don't mean to imply that it should already be implemented, but wanted to add my thoughts now in case there's ongoing discussion for the future, which it sounds like there is! Thanks for the reply

@Philip_Thomas_PTC

I was imagining that we get a workflow much like creating a new regular variable while in sketcher (or other situations). You could create a QV while in another feature and the QV would be added to the feature tree right before the current feature. This would be an explicit QV. If you delete the feature that was used to create the QV, it would still exist, just like a regular variable.

Evan's second concept is more of a parallel with implicit mate connectors. I could see that being useful to keep the tree less cluttered, but much like implicit MCs, I often later want to be able to reuse them, and there's currently no way to do that. I'd almost prefer that those MCs got added before the feature the same way on-the-fly variables do. It would be more consistent and make them more useful. I suspect that part of the reason for that workflow was that at the time, MCs needed an owner. Now that they don't, I don't see why they shouldn't be created above the feature for potential reuse.

@EvanReese - we very nearly did allow the creation of QVs ‘on the fly’. The main reason we didn’t for this release was that a user would not be able to locate where in the tree the QV was defined (if they had reused the QV and later needed to edit its definition) or worse still suppressed or deleted the feature containing the definition. One idea discussed was limiting the scope of use to only the containing feature (a ‘local’ QV if you like). We still might do this but wanted to see how QVs were received first (pretty well by all accounts :))!