Replies: 2 comments 2 replies
-
The changes are committed to the library now and I will start to test them with a wide range of boards, once most cases work as expected I'll create a BETA release of TcMenu designer and lib. |
Beta Was this translation helpful? Give feedback.
-
Even the source of out of order card layout is now solved. It was caused by the example starting at grid row 1 instead of 0 when there was no title. Given 3 items with a grid position and few without, this results in row 1, 2, 3 being taken but 0 being left open, in which case the first row to layout automatically (IE without a grid position) gets row 0. This should also be fixed on master. |
Beta Was this translation helpful? Give feedback.
-
We've had a few long-standing issues in the rendering classes, these issues have been quite difficult to fix because of a couple of wrong decisions taken when they were first implemented. We're trying to rectify as many of these bad decisions as we can now, and once we've done that, we'll take stock of the current issues again, and ask that you retest any issues against the new version.
This also provides the starting point for support of more than one display at once, because we've already modified the concept of active and changed so that they belong to a renderer. This is not the main driver, but a nice side effect of this change for those that need it.
What has been changed?
The active flag on menu items has been complete removed, it made no sense as only one item can ever be active at once, so instead the renderer class just tracks what is presently active using a pointer to a menu item, obviously method MenuItem::getActive has gone, but the methods most used on the menu manager are still there. Similarly the MenuItem::isEditing flag has gone, again only one item can edit at once, and the menu manager already tracks that, most will see no issue in either of these changes.
Renderers can now be configured with a displayNumber, by default it will be 0, the first display, and tcMenu Designer will only create the first. The MenuItem::isChanged method now optionally takes a parameter which is display number. Most will see no issue in this change.
For graphical displays, early on we tried to delay the point at which we determined if the rendering order needed to be recalculated, this is a costly operation and the idea was to save cycles, but in truth, it caused too many problems, we now recaclulate as soon as the displayed menu list structure changes. IE beyond a value change. Along with this we also recalculated the display offset every time around, this caused some issues and added complication to the rendering loop, this is now only done when the active item changes ( the only time it needs to be done ).
Beta Was this translation helpful? Give feedback.
All reactions