TreeTable in Matlab 2025a

Since javacomponents are deprecated as of MATLAB 2025a, has anyone found a way to generate treetables similar to what was possible with jide ?

We have been relying on those for a lot of GUI and see nothing in UITABLE/UITREE that would be similar. Necessary features are

• tree opening
• resizable columns
• cell renderer allowing push buttons and pull down menus
• column sorting is a bonus

[Cris LaPierre]

In the meantime, I would encourage you to provide this feedback directly to MathWorks: https://www.mathworks.com/support/contact_us.html

[dpb]

@Cris LaPierre, is there anything preventing using the Swing GUI toolkit independently even if not distributed with base MATLAB?

Having to rewrite working code that doesn't have same features seems like a major hardship placed on users.

Would there not be a way even if Mathworks thinks they don't want to ship the toolkit to provide an access path for the users who are using it?

The examples show a rudimentary toy-like case, would not all the callbacks and so on also have to be retooled for the different component?

[Etienne Balmes]

We understand the need for MATLAB to move towards JS based containers and are even willing to retool all the callbacks (not too much of a problem since we have a unique callback handler), but Matlab UI is missing a number of key concepts (like integrating buttons is the use case I submitted above) We started reaching out in 2020, but the real progress is still far from including features available in JIDE (which had a direct connection with MATLAB through SWING). A JS based equivalent would be https://www.ag-grid.com but connecting that to Matlab without help is beyond our capabilities as we need to be able to work daily on the toolbox version we are going to ship the next year.

[dpb]

The above link didn't quite work , maybe https://www.ag-grid.com/javascript-data-grid/getting-started/ is example component...

It would seem the short tem solution for all would be for Mathworks to reverse the decision to pull Swing until whatever is the longterm replacement does have at least equivalent functionality.

It's bound to be extremely frustrating given a 5-year history of the functionality need for them to then have gone ahead and made the unilateral decision to pull the existing functionality. One would hope TMW will listen to the support request and provide a workaround if not entirely reverse the course of the leviathan.

[Cris LaPierre]

To that end, please submit the feedback directly to MathWorks if you have [not sic--dpb] done so already.

Answer 1

[Samayochita]

Hi Etienne,

I understand that you are trying to generate treetables in MATLAB. Unfortunately, there is no built-in treetable component available but here is a high-level view of how you could implement treetable by using “uitree” and “uitable” and synchronizing their events so that expanding or collapsing nodes dynamically updates the table rows.

1. Build the UI layout

• Use “uifigure” followed by “uigridlayout” with two columns. Column 1 will contain “uitree” for hierarchy. Column 2 will contain the “uitable” for data.
• This makes them look like one component aligned row by row.

2. Define the tree data: Represent the hierarchical data as a nested structure.

3. Handling expand/collapse logic:

• Attach “NodeExpandedFcn” and “NodeCollapsedFcn” callback to the “uitree”. Inside these callbacks, recompute which nodes are visible and refresh the “uitable” accordingly.
• This makes the table row count increase or decrease dynamically when tree nodes are toggled.

4. Flattening helper function

• Write a recursive function to convert hierarchical nodes into a flat array of rows.
• For every expanded node, add a row to the table.

Note:

• “uitable” in App Designer supports interactive column resizing by default.
• Drop-down menus in “uitable” are supported using the 'ColumnFormat' property.
• There is no direct way to put a push button into a “uitable”. You might be able to do it with Java, but the only component that “uitable” supports is checkbox.

Some links for your reference:

• uifigure: https://www.mathworks.com/help/matlab/ref/uifigure.html
• uigridlayout: https://www.mathworks.com/help/matlab/ref/uigridlayout.html
• uitree: https://www.mathworks.com/help/matlab/ref/uitree.html
• uitable: https://www.mathworks.com/help/matlab/ref/uitable.htmlhttps://www.mathworks.com/matlabcentral/answers/444826-how-can-i-make-a-push-button-in-a-uitable
• https://www.mathworks.com/matlabcentral/answers/452199-how-can-i-have-dropdown-in-every-cell-of-a-table-in-app-designer
• https://www.mathworks.com/help/matlab/ref/matlab.ui.container.tree.html
• https://www.mathworks.com/help/matlab/ref/matlab.ui.control.table.html

You could also refer to the following file exchange: https://www.mathworks.com/matlabcentral/fileexchange/42946-treetable-create-a-sortable-table-control-with-collapsible-row-groups

Hope this was helpful.

[Etienne Balmes]

Thanks for the detailed response, this is helpful (and along the lines of our prototype) with slight modifications

• step 1 : uigridlayout does not support interactive width resize (at least I don't see how)
• step 2 : actually we only store the tree column in the uitreee. In Java like Yair's treeTable example which you refer to (this is no longer viable as of 2025a), this is the difference between a table and its display model
• step 3 : the expand collapse logic only rewrites an index.
• step 4 : is really written as function that populates the view table from the raw data table

But the crucial problems we still have are

• your dropdown bypass is only defined per column whereas we have different menus on different cells. I have thought about changing the dropdown dynamically but will that work ?
• https://ag-grid.com/react-data-grid/cell-editors/#popup-editor implements what was available in java : a cellRenderer and a cellEditor which can programatically return the HTML content to be placed in a cell. These concepts do not exist in Matlab ?
• your sync bypass leaves the issue of synchronizing the scrolling of tree and table, the attached capture from the uitree / uitable example shows why we trashed the idea so far : you would need to know pixel by pixel which part of the tree is visible in the scroll viewport (here halfway through region) and be able to show part of the view table accordingly. Do you know of callbacks to associated with scroll viewports ?
• Since this last item seems a complete NoGo (but I would love you to prove me wrong) we have worked a protoptype where we show the tree as a column, but uitable only displays square icons, so there is no way to show more than one level with the correct indentation ...

• From this post it is also clear that the HTML rendering of uitree fully writes a the tree to HTML. This is not viable if you have 1e6 entries. Obviously UITABLE is able to only write code for the visible rows (otherwise workspace navigation would be much slower). But this client/server operation is not documented. A clear description is given by ag-grid as server side model
• We consider dropping all Matlab components and using ag-grid into an UIHTML component, but debugging is a problem and we loose the compatibility with MATLAB which our users know.
• By the way the java idea of CellRenderer which allow formating of contents (like having the right number of significant digits) does not seem to have a MATLAB equivalent.

[dpb]

I admire your perserverence to try to move in the direction Mathworks is pushing and wish you good luck in maybe finding an adequate workaround.

I'd just ask until Mathworks does catch up, have you tried setting the Java environment to use the JDE with R2025a so you could continue with the same functionality?

[Etienne Balmes]

The java functionality is still there, just incompatible enough with JS based interactionsto make it a dead end. Right now, we just ask our users to not update to 2025a.

JAVA is slowly loosing ground (see [Yair's answer] ), so I actually understand why MathWorks wants to switch to more active environements that are JS based. We need to be ready when one of our big clients says, we must operate in 2025a or later (that leaves at least 2-3 years probably).

[dpb]

OK, seems reasonable approach..

I do/did understand it's a dead end in the long run(*), but it also seemed like might invest a lot of effort into what is also at best a temporary patch. But, unfortunately, "the client is always right" (even if they're really not!).

If push comes to shove, package the jar file with the app?

(*) But, also as you/Yair note, the pace and scope of Mathworks' implemenation of features hasn't yet produced a builtin replacement for existing functionality which makes terminating the dual packaging for users who have need/use problematical.

[Etienne Balmes]

Please note that I will continue editing my answer as to why I can't accept @Samayochita answer in the first comment which tends to be hidden. https://fr.mathworks.com/matlabcentral/answers/2179688-treetable-in-matlab-2025a#comment_3340351

[dpb]

It's got to be tough to support a major app given the dynamic nature of MATLAB and particularly with the reinvention of things and the shift in implementation toolsets. While some at least is understandable owing to external changes, it can't be easy when new doesn't match old and particularly when there is actual loss of functionality rather than just a recoding of a different widget but that at least can do the same thing.

You have my sympathy for what little that's worth <vbg> and good luck in finding a way forward.