Dear Autodesk,
I am just a lonely component pattern without a home.
All my part and sub assembly friends always have a browser folder to go home too at the end of the day but here I sit out in the open field feeling jealous. When you first built browser folders for the others I thought.."surely I can just wait a while and you will come along and allow me to live in a home too" but alas here I am a few years later still sitting out in the open. It's just me and my only friend the routed systems node left.
Please help us find our home.
Your friend,
Lonely component pattern
All joking aside.. This is the kind of thing that makes users mad.. Finish this **** already.
Solved! Go to Solution.
Is that a laugh at the post, or at the suggestion that new features should be fully developed before (or shortly after) they are added to the software?
Mcgyvr,Ha!
First, I agree with you--this should be fixed (as to if/when it will be fixed--I don't make those decisions). That said, I wanted to point out some technicalities.
I was a developer on the browser folders project, and I recall this issue. The issue was not that component patterns cannot go into a folder (they can--RMB "Add to New Folder"). The issue is that they cannot be re-ordered (you can't drag them to a new location in the browser). You can drag/drop a component pattern into a folder as long as it would not reorder it (with respect to other non-folder entities). I believe it is the same for the routed systems node (that it cannot be re-ordered, but can be added to folders).
Both these restrictions existed prior to browser folders, but the introduction of browser folders exacerbated the problem (since users started doing more reordering to get items into their logical "home" folder).
Also, you'll notice that the re-order restriction seems somewhat artificial in that you can't drag and drop the component pattern, but you can drag and drop other components around the the component pattern (effectively re-ordering it). The re-ordering restriction is simply that you can not reorder it with respect to other non-reorderable things. As to whether there is a technical reason that makes re-ordering of component patterns (or routed system nodes for that matter) difficult, I don't know.
I, too, hope that someday your component pattern will find its way home.
- Matt
@mcgyvr wrote:Dear Autodesk,
I am just a lonely component pattern without a home.
All my part and sub assembly friends always have a browser folder to go home too at the end of the day but here I sit out in the open field feeling jealous. When you first built browser folders for the others I thought.."surely I can just wait a while and you will come along and allow me to live in a home too" but alas here I am a few years later still sitting out in the open. It's just me and my only friend the routed systems node left.
Please help us find our home.
Your friend,
Lonely component pattern
All joking aside.. This is the kind of thing that makes users mad.. Finish this **** already.
I haven't used Inventor in a while so am new to folders. The dragging and dropping action is very clunky. Maybe the feel could be something more like Windows Explorer? I can't understand why all components (including patterns) cannot be reordered. The restriction is only mentioned briefly in Help. They are only icons on a screen after all! We should be able to put them whereever we want and in whatever folders. Once again, Autodesk has let us down. It's a shame because there are a few basics that have been sorted out in 2011 (one could say that after this many releases it is not a great achievement), but still several basic user interface issues that should be addressed before yet another fancy gizmo is added on, or another 50% program size increase (and 100% load time increase). I must congratulate Autodesk though on a stable program though ... that really is a first not to have it crashing often ... maybe it's because I went straight to SP1? Still there is a graphics driver bug for my Quadro that has been around for years only is worse in 2011.
@darnold wrote:
Over 4 years later and still no answer to this and several other well known complaints? Very sad.
When I was new to Inventor, this board was a wealth of knowledge. A place where I continually found answers and help. Now, sadly, I come here less and less and when I do, I have a sinking feeling. "Probably a well known and ignored problem."
David Arnold
Designer-New Dies
Motor City Stamping Inc.
Its all about demand.. and sadly there isn't any to fix this issue year after year...
Here is the idea station post.. Only 6 kudos.. Give it one more..
Six years later and our component patterns still don't have a home...
Donations accepted at these venues:
I used to support "free range" component patterns, as I didn't like the idea of mcgyvr caging them up and doing strange things to them. But recently I saw on the news were a component pattern along with 3 feral dogs and a stray parakeet attacked a mail carrier and chewed off 3 of his ears.
So now I have visited the idea forum and voted to get these patterns off the streets.
DRoam wrote:
I voted on 2 out of the 5 ideas, but this one has the "accepted" status.
It was accepted in 2013, so it's hoping they're getting around to it by now...
I guess in the big picture it's a rather small issue, but it could use some attention.
Niels van der Veer
Inventor professional user & 3DS Max enthusiast
Vault professional user/manager
The Netherlands
@DRoam wrote:
AWESOME!!!!!! Love it..
But I think its like 8-9 years now not just 6 since browser folders came out..
Sadly its taken me about that long just to get in the habit of creating my cable harness nodes at just the right time where I can organize them into the proper folder structure.. And I've actually avoided component patterns now too JUST because of this issue.. I'd rather take a little longer assembling than having a disorganized folder structure/homeless patterns.. silly I know.. But I like to be organized... Not just for myself but for the person that will eventually come after me..
@Curtis_Waguespack wrote:
mcgyvr caging them up and doing strange things to them.
You know me too well..
@-niels- wrote:
DRoam wrote:
I voted on 2 out of the 5 ideas, but this one has the "accepted" status.
It was accepted in 2013, so it's hoping they're getting around to it by now...
I guess in the big picture it's a rather small issue, but it could use some attention.
Just a reminder (that you power users should know by now!), accepted does not mean we are actively working on it.
It means we agree with your, we understand what is being asked for and we would like to do it. It still gets prioritized against all the other projects with our resources.
As I've said on other browser reorder threads we have tackled all the easy low hanging fruit (I fixed dragging virtual components last release?), what is not supported is more than a trivial fix given the compute semantics that are baked into the browser, especially the part browser.
Having said that I'll take another look at the work features and patterns in assemblies.
Hi,
I am unfortunately not able not to use patterns as mcgyvr did, and had to stop using folders totally.
Every time I am scrolling threw hundreds of components in the browser I wander: how hard can it be to allow user to order this icons in groups, folders on in any other clever way. This is solely interface issue.
If you cannot cope to allow ordering entities in the actual assembly structure than just add another table just to order them in tree. This should not be neither hard nor time consuming.
I also cannot understand why there are still are so many ridiculous limitations or lacking basic functionalities that frustrate users so much.
And please do not tell me to put them in to ideas Station. They are there for years but they are ignored.
How it is possible that Autodesk is not ashamed because of that?
Oh I know, It is a corpo after all that cares only for profit and nothing else. We are only getting what marketing decides is good for Autodesk it self and that's unfortunately how things are.
Cris.
@SteveMDennis wrote:
Just a reminder (that you power users should know by now!), accepted does not mean we are actively working on it.
You can't just let me have my denial, can you?
@SteveMDennis wrote:
what is not supported is more than a trivial fix given the compute semantics that are baked into the browser...
It can't be that hard.... just add this chunk of code, right?
If UserTryingToDragPattern = True Then Let him End If
@SteveMDennis wrote:
Having said that I'll take another look at the work features and patterns in assemblies.
Seriously though, thank you for tackling this one. This may not be one of the glaring deficiencies in Inventor, but it's one that every one of us deals with on a daily basis. This high-hanging fruit is well worth getting out the ladder for.
Also, while I'm not necessarily on board with it, I can 100% understand Cris-Ideas frustration on this one. I'm sure you see a lot more going on when you look at the assembly browser, but when we look at it, all we see is a list of the components in the browser, whose order has NO effect on the assembly computations or structure itself, AT ALL. We can do NOTHING to control the assembly by re-ordering things. The ONLY purpose re-ordering has is for organization and sanity of mind... hence the feelings of insanity when we can't re-order things like patterns and work features.
This isn't really my place to say... but might I humbly say that if the "compute semantics" (I can't pretend to know what that means) of the Assembly browser depend so heavily on the order of objects in the Assembly browser..... then maybe, perhaps, the architecture of the Assembly Browser needs to be re-thought and re-written from the ground up, so that it is more in keeping with the true front-side operation of the Assembly browser (which is that the order of components has no effect on assembly solve/operation).
Those are my thoughts.
Thanks again for taking the time to look into this one.
@DRoam wrote:
@SteveMDennis wrote:
what is not supported is more than a trivial fix given the compute semantics that are baked into the browser...
It can't be that hard.... just add this chunk of code, right?
If UserTryingToDragPattern = True Then Let him End If
@SteveMDennis wrote:
Having said that I'll take another look at the work features and patterns in assemblies.
Seriously though, thank you for tackling this one. This may not be one of the glaring deficiencies in Inventor, but it's one that every one of us deals with on a daily basis. This high-hanging fruit is well worth getting out the ladder for.
Also, while I'm not necessarily on board with it, I can 100% understand Cris-Ideas frustration on this one. I'm sure you see a lot more going on when you look at the assembly browser, but when we look at it, all we see is a list of the components in the browser, whose order has NO effect on the assembly computations or structure itself, AT ALL. We can do NOTHING to control the assembly by re-ordering things. The ONLY purpose re-ordering has is for organization and sanity of mind... hence the feelings of insanity when we can't re-order things like patterns and work features.
This isn't really my place to say... but might I humbly say that if the "compute semantics" (I can't pretend to know what that means) of the Assembly browser depend so heavily on the order of objects in the Assembly browser..... then maybe, perhaps, the architecture of the Assembly Browser needs to be re-thought and re-written from the ground up, so that it is more in keeping with the true front-side operation of the Assembly browser (which is that the order of components has no effect on assembly solve/operation).
Those are my thoughts.
Thanks again for taking the time to look into this one.
Guys,
I've been coding in Inventor for almost 19 years now... I'm gonna ask you to trust me on this one. I have personally tried twice to redo the browser to give you fully customizable browser.
@DRoam Again, YES the browser order CAN have impact on Assembly variational compute solutions (especially in underconstrained systems), this is a fact but probably not a huge occurrence out in the wild! I can't break that.
I have "owned" the browser since R1 (especially the Assembly portion) and if I could have fixed this I would have many times over. I know that while it does not keep you guys from getting your job done it can get in the way and shouldn't be that hard on you.
I cannot claim to have been working on Inventor code for 19 years but I know a list when I see one. Keep the underlying data in whatever order keeps Inventor sane, and give the users a list that can be re-ordered to keep the users sane. It's just a bunch of icons on a screen that point into a database or something. Try writing some code that has the icons dancing round in a circle. Think laterally.
@signmeup wrote:
I cannot claim to have been working on Inventor code for 19 years but I know a list when I see one. Keep the underlying data in whatever order keeps Inventor sane, and give the users a list that can be re-ordered to keep the users sane. It's just a bunch of icons on a screen that point into a database or something. Try writing some code that has the icons dancing round in a circle. Think laterally.
Agreed... if I was doing the system from scratch. Unfortunately I am not. For whatever reasons our early architects (I was not one! I was a newbie 19 years ago) decided to use the browser to convey the compute order/semantics back to you the user.
It's that attempt to keep you guys in the loop on the order and how it plays in the compute that causes the problems. If we were to disconnect that some users would say, "How can I control this compute difference?", you would lose that control, and as I say that I realize most probably don't care 99% of the time. But it is the world we live in, maybe disconnection (at least in Assemblies) is the way to go... albeit at a loss of some "control"
I agree with you in principle. In practice it's just not that easy.
@SteveMDennis, I believe you. Not questioning your expertise.
The only thing I think we're questioning is the current "architecture" or at least user-side "behavior" of the Assembly Browser (architecture may not be the technically correct term, but when I say that what I mean is "how it's programmed and built to work from the ground up". Hopefully that makes sense).
Here are my thoughts at this point:
Those are just my thoughts. Thanks again for continuing this discussion with us and understanding our frustration.