Auto-selecting parent group after editing child component h̵u̵r̵t̵s̵ destroys productivity
When editing one of the bottom components within a group that contains more components than can be displayed at once in the outline without scrolling (in my case, that is more than about 23 components), after making the edit (such as changing the ID), Justinmind automatically selects the parent group, scrolling the bottom components in the group out of view, making it slower to quickly make changes to all of the elements in the group.
Actually, it's even worse than described: sometimes, this awful bug will select an ancestor group 4 or 5 levels up the tree, as if straining to ensure that it is impossible to keep the element you just edited in view.
In general, auto-scrolling the outline and auto-selecting elements in it causes far more problems than whatever it may solve. The nonsense of auto-scrolling the outline in the Events editor causes constant problems. Sometimes, it is all but impossible to select a specific element, because it immediately auto-scrolls and changes the selected element. Oy!
This problem remains unacknowledged by Justinmind, but it is costing me money and frustration, and greatly diminishes my satisfaction with the tool.
TIME AND TIME AGAIN (yes, I'm yelling!), I select a component, nudge it a pixel using the cursor keys, or edit some other value in the inspector, only to have the selection suddenly pop up to a parent or ancestor element, so that the next cursor key press affects the parent or ancestor element.
This is enormously frustrating and has caused me to damage my prototypes more times than I can count.
Here's a little GIF illustrating the problem:
This problem remains unacknowledged by Justinmind, but it is costing me money and frustration, and greatly diminishes my satisfaction with the tool.
TIME AND TIME AGAIN (yes, I'm yelling!), I select a component, nudge it a pixel using the cursor keys, or edit some other value in the inspector, only to have the selection suddenly pop up to a parent or ancestor element, so that the next cursor key press affects the parent or ancestor element.
This is enormously frustrating and has caused me to damage my prototypes more times than I can count.
Here's a little GIF illustrating the problem:
I suggest you use dynamic panels, they are better than groups but the result is similar.
I suggest you use dynamic panels, they are better than groups but the result is similar.
Thanks for the comment, Maciej.
I use dynamic panels extensively, where they're appropriate, such as for simulating a tabbed interface (showing each layer in the panel when its tab is clicked), or for imposing auto-layout (vertical or horizontal stacking).
But for simply collecting several related components that may move together be shown/hidden together, groups are the right tool for the job, and I'll be grateful when the good people at Justinmind fix this nasty bug.
Thanks for the comment, Maciej.
I use dynamic panels extensively, where they're appropriate, such as for simulating a tabbed interface (showing each layer in the panel when its tab is clicked), or for imposing auto-layout (vertical or horizontal stacking).
But for simply collecting several related components that may move together be shown/hidden together, groups are the right tool for the job, and I'll be grateful when the good people at Justinmind fix this nasty bug.
I think I'll revisit and comment on this report every week. I'd like someone at Justinmind to at least acknowledge it and cut-and-past their usual text:
"I will forward your request to de development team and we will notify you when this is fixed in a new update."
Anticipating your response,
Dave
I think I'll revisit and comment on this report every week. I'd like someone at Justinmind to at least acknowledge it and cut-and-past their usual text:
"I will forward your request to de development team and we will notify you when this is fixed in a new update."
Anticipating your response,
Dave
Replies have been locked on this page!