Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I don't think structuring GUI-code is fundamentally different from non-GUI code.</p> <p>Put things that belong together, together at some location. Like helper-functions that might go into a <code>util</code> or <code>helpers</code> directory. Depending on the content, maybe make it a package.</p> <hr> <p>Personally I don't like the "one function one m-file" philosophy some MATLAB people have. Putting a function like:</p> <pre><code>function pushbutton17_callback(hObject,evt, handles) some_text = someOtherFunction(); set(handles.text45, 'String', some_text); end </code></pre> <p>into a seperate file simply makes no sense, when there's no scenario whatsoever you'd call this from somewhere else then from your own GUI.</p> <hr> <p>You can however build the GUI itself in a modular way, by e.g. creating certain components by simply passing the parent container:</p> <pre><code> handles.panel17 = uipanel(...); createTable(handles.panel17); % creates a table in the specified panel </code></pre> <p>This also simplifies testing of certain sub-components - you could simply call <code>createTable</code> on an empty figure and test certain functionalities of the table without loading the full application.</p> <hr> <p>Just two additional items I started using when my application became increasingly larger:</p> <p>Use listeners over callbacks, they can simplify GUI programming significantly.</p> <p>If you have really large data (such as from a database, etc.) it might be worthwhile implementing a handle-class holding this data. Storing this handle somewhere in the guidata/appdata significantly improves get/setappdata performance.</p> <p><strong>Edit:</strong></p> <p>Listeners over callbacks:</p> <p>A <code>pushbutton</code> is bad example. Pushing a button usually only triggers on certain action, here callbacks are fine imho. A main advantage in my case e.g. was that programmatically changing text/popup lists does not trigger callbacks, while listeners on their <code>String</code> or <code>Value</code> property are triggered.</p> <p>Another example:</p> <p>If there's some central property (e.g. like some source of inputdata) that multiple components in the application depend on, then using listeners is very convenient to assure that all components are notified if the property changes. Every new component "interested" in this property can simply add it's own listener, so there's no need to centrally modify the callback. This allows for a much more modular design of the GUI components and makes adding/removing of such components easier.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload