+7
Adjustable feature selection box.
When constructing or dimensioning, the feature selection box should be adjustable in size to see more features or full feature identification for easier selection.
Kundesupport af UserEcho
You can have my last vote for this one
What baffles me is why isn't all dialogs sizeable? It's like a dropdown selection in the programmers IDE and then it's done...
If only...:) Most of the dialogs in PC-DMIS are written in MFC, which doesn't have this. Homebrew dialog resize support has to be manually coded to move things around. Not saying it's impossible or anything, just that it's not a flick of a switch - else it would have been done. Some of the newer dialogs are WPF, and for those, resize comes for free.
That explains it (and some other weird quirks in the UI). Neil, are there any general plans to migrate "upwards" towards WPF - or will that be done when other stuff (fixes/additions) are being made to the dialogs?
I think it's fair to say that in general we won't be adding any more new MFC dialogs, and you should start seeing more and more WPF ones introduced - starting in 2017 R1. We won't be swapping them all overnight, we will focus on specific areas, and take time try to consolidate/improve work flows at the same time as adding the prettier and more modern tech....which is where userecho can help us decide where to focus.
Even making them bigger would be a help, not massively so but a bit wider definitely.
I guess when testing (i.e. not IRL) features are called the default cir1, cir2 pln1 etc, but in real life it might be
25_035_cbore_pos1 etc, often longer than that!
That said the ability to order (and reverse the order) by program order, or alphabetical was a great enhancement.
Sorry to go off topic as well, but why are we limited to three votes only?
The similar systems I've seen used usually limit the votes to 3. When a new system like this is launched, there are many new and good ideas suggested. All of them are usually good ideas, so the majority would get voted by the majority...meaning...they all get a similar number of votes...so it doesn't really help us decide which to prioritize. Limiting to three will mean people are more selective, and should help the great ideas separate from the good and the good to separate from the pretty good...etc. If we decide it's not working, we can look to be more generous with the votes. The system is configurable to have more. Also, if you change your mind when a better new idea comes in, you can un-vote something and use your vote elsewhere.
I do get that but three is a little limiting! There's nearly 40 topics already so even if we had 10votes we could only vote for 25% - you'd still get a good idea of what people want.
It's less than a week and there are already things I can't vote for which are really good ideas!
I assume that the suggestions are removed as they are added to the "todo-list" and all other suggestions "stays" here as-is and we get three new votes to continue voting for them?
You will notice top voted items will get marked as "Planned", then "Started" then "Completed" as they go through our process.This system is connected to our development server, so anyone who votes on an item that is being done will receive emails indicating the different status gates it goes through. I believe items that are completed disappear from the default view. All other items remain with their votes intact, so it's a continually rolling prioritized list.
So, when is it OK to remove a vote from an item without disturbing the process? When it's "Started", or do we have to wait for "Completed" before being sure you don't change priorities if the vote is moved to something else?
Edit: BTW, I think it would be good to keep a visible list of suggestions made through this forum that makes it into the product - it would show newcomers that time (and votes) spent here is not wasted!
+1000 for the implemented suggestions list
When most voted items are planned for inclusion in the next version, we want the teams implementing them to be able to reach out to a handful of those who voted for it, and to involve them in the process to ensure the implementation meets expectations. We would look to reach out to those people shortly after an item gets set to Started, so I suggest perhaps give it a little time (maybe a month) after seeing this status change before removing your vote. We generally work in pre-planned 6 month cycles, and so whilst I understand why you would be itching to move your vote to your next desired improvement, we effectively wouldn't be counting the votes for the next version until we are in the planning phase for the next 6 month cycle anyway.
Your suggestion for somehow publicizing which suggestions were implemented as a result of this forum is a great one, and I agree would help to engage more people. We'll have to think about how best we can do that. We have a new "What's New" landing page we are introducing in 2017 R1 that gets shown on first run, and that could be a good place for us to do just that.
5 Letter limit for naming variables went obsolete with FORTRAN and BASICA
All selection windows for feature selection , probes selection, for construction, dimensions, alignments etc etc,
should be expandable to show full length of variable object name
An item like this should nrver come up as request for change