<p>

    The parameters panel will be empty if:
   	<ul>
	    <li>No block is currently selected.<br>
	    <li>The currently selected Simulink model is not a valid LTPDA model.<br>
	    <li>The selected block it's not a valid LTPDA block (i.e., it do not contain a proper LTPDA function which answers
            the call for parameters).<br>
   	</ul><br>
    
    Otherwise, the contents of the parameters panel will change accordingly to the user selection in the active LTPDA Simulink model.
   	<ul>
	    <li>If a <b>function/method</b> block is selected, the panel will show the proper corresponding parameters.<br>
	    <li>If a <b>Object from list</b> block is selected, the panel will show the referenced index (that is the only parameter accepted).<br>
	    <li>If a <b>Mux/Demux</b> block is selected, the panel will show the number of inputs/outputs.<br>
	    <li>If a <b>From</b> block is selected, the panel will present the 'Find origin' button.<br>
   	</ul><br>
   
    <h2>Function/method parameters</h2><hr><br>
    If a valid LTPDA function or method block is selected (inside a valid LTPDA Simulink model), the GUI will first ask the inner
    function or method for its required parameters; the panel then will be built accordingly.<br><br>
    
    <img src="images/parampanel_1.png" alt="The parameters for functions/methods" border="1"><br><br>
            
    The window is built automatically: <b>every line corresponds to a different parameter</b>, among those required by the selected
    function.<br>
    Inside every line, then, the structure is obviously similar, so different parameters can have the same fields and boxes.<br><br>
    
    <h2>Required or added parameters</h2>
    In the construction of the panel the GUI will consider whether the parameter was among those required by the function, or
    if the parameter was added by the user. In this latter case it will be passed to the function, which can use it (if someway
    expected, for example if it a possible optional parameter) or ignore it, if just unexpected. The GUI won't change the
    behavior of the inner function, so it's up to the user to be aware of what can be passed to be used by every function.<br><br>
    In the parameters panel the difference among required and added parameters is shown on the far right: added parameters have a
    small '<tt>-</tt>' button, which lets the user to remove it; required parameters have no such button, since the corresponding
    parameter was automatically required by the function and not added by the user.<br><br>
    Please note that a parameter can also be disabled (see 'Enable checkbox', below): since a disabled parameter won't be passed to
    the function, there's no difference in removing an added parameter or just disable it. The only difference of course is a
    disabled parameter can be re-enabled in a second time, while a removed parameter has to be added and set over again.<br><br>
    
    
    <h3>Enable checkbox</h3>
    On the left, at the beginning of every line/parameter, there is a checkbox which lets the user to enable or disable the
    corresponding parameter. If it's enabled the parameter will be passed to the function, so it's up to the user to set the proper
    value. If it's disabled, on the contrary, it won't be part of the plist passed to the function, which thus will use the default
    value (if any is expected).<br><br><br>
    
    The central part of the window is built line by line to reflect each parameter, so it can differ a lot.<br><br>
    <img src="images/parampanel_2.png" alt="A complicated parameters panel" border="1"><br><br>
    
    <h3>Parameter name</h3>
    Wherever expected, the first element on the left, aside the Enable checkbox, is the parameter name.<br>
    For <b>double/char</b> parameters this means the parameter key; note that if the parameter was required by the function, the name is
    fixed (see parameter 1,3,5,6 in the previous image), while for added parameters it can be changed (see parameter 7).<br>
    In case of an added parameter the GUI will show both a text '<tt>Name:</tt>' and an
    edit field, where the user can type in the parameter key itself.<br><br>
    For <b>specwin</b> parameters the key is fixed, so the GUI shows directly the name of the window type ('<tt>Kaiser</tt>',
    '<tt>Rectangular</tt>',...).<br><br>
    Similarly, for <b>Poles and Zeros</b> parameters the key is fixed, so even for added parameters '<tt>Poles</tt>' and '<tt>Zeros</tt>'
    are shown and cannot be altered.<br><br>
    Since the key is fixed also for <b>MIIR and PZmodel</b> parameters, the GUI shows directly the inner parameters to construct these
    objects; note that this is just a way to build a MIIR object, typing in directly the plist. To build it in a different
    way, for example retrieving from the Repository, must be used a proper Constructor block, setting the parameters to be
    retrieved from Simulink (see 'From Simulink checkbox', below) and connection the Constructor block to the function port having
    as a name the corresponding parameter's name.<br><br><br>
    
    
    <h3>Parameter value</h3>
    The following field lets the user to type in the parameters value. This is true for every '<tt>Value:</tt>' field in the
    parameters panel.<br>
    <b>Please note that often is possible to have a brief help text in the tooltip string, just moving the mouse pointer over
    the edit field and waiting a second.</b><br>
    This will explain for example the meaning for the different edit fields in a specwin parameter, or it will explain how to type
    in poles and zeros into their corresponding edit fields.<br><br>
    
    Inside an edit field the user can type in using the traditional MATLAB syntax:
   	<ul>
	    <li><b>10</b>, will be considered a pure number. The parameter's value will be of course the number itself.<br>
	    <li><b>[1 2 3]</b>, among square brackets, will be converted into a vector (or matrix). Similarly, using {} will create
                          a cell array. The parameter's value will be a vector, a matrix or a cell array.<br>
	    <li><b>'Hello'</b>, among quotes, will be considered a string, and it won't be evaluated. The parameter's value will be
                          a string.<br>
	    <li><b>rand(1)</b>, without quotes, will be recognized as a command and it will be evaluated immediately. The parameter's
                          value will the output of the evaluated string.<br>
   	</ul><br><br>
    
    <h3>Expand edit field button</h3>
    The small gray button aside each parameter's value edit field, for double/char parameters, will open up a window with a bigger
    edit field, where the user can type in the value more comfortably than in the small one in the panel. This is particularly
    handy for those case when the parameter's value is a long and complicated command or vector, which can't fit easily in the
    small space given in the panel.<br><br>
    <img src="images/parampanel_3.png" alt="The expanded edit field" border="1"><br><br><br>
    
    <h3>From Simulink checkbox</h3>
    If the parameter is not supposed to be set in the GUI's panel but it must be retrieved from Simulink (for example, using a
    Constructor block for that particular type of object), the user can click on the small '<tt>From Simulink</tt>' checkbox.<br><br>
    <img src="images/parampanel_5a.png" alt="'From Simulink environment'" border="1"><br><br>
    The line will be updated, showing 'From Simulink environment'. Since this parameter will be retrieved from Simulink, the user
    cannot alter it anyway in the current parameters panel.<br><br>
    In the LTPDA Simulink model, the block will be modified with a new inport, with the same name as the parameter's key:<br><br>
    <img src="images/parampanel_5b.png" alt="'From Simulink environment'" border="1"><br><br>
    While the first inport must be connected to the data coming in (if any is expected), as usual, the second port must be
    connected to the constructor block providing the object which will become the parameter.<br>
    In the example shown, the specwin Constructor block provide the specwin object that, inside the '<tt>pwelch</tt>' block, will
    be retrieved as a parameter and passed to the function.<br><br>
    
    If the block had no data input, i.e. no input prior to the 'From Simulink' parameter, it will present a single inport, which
    must be connected to the Constructor block providing the parameter's contents.<br><br>
    
    Since it's possible to set multiple parameters coming from Simulink, the user should take care of the connections to the
    block, to avoid to shuffle the connected Constructor blocks - for example, inverting a specwin object and a MIIR object.<br><br><br>
    
    
    <h3>Load button</h3>
    For MIIR and PZmodel parameters the GUI will show also a '<tt>Load</tt>' button: the purpose of course is to retrieve these
    objects from a file on disk. Please note that for now this will convert the loaded object into its constructive plist, if
    possible, and the GUI will show again the parameters of the loaded object into the common parameters panel.<br>
    <i>This will be discontinued or modified after R1</i><br><br><br>
    
    
    <h3>Adding parameters</h3>
    Immediately below the last parameter, on the left, the GUI shows a popup list containing all the parameters types which can be
    added, and aside a '<tt>+</tt>' button to add a parameter of the selected type.<br>
    Since it makes no sense to pass to a function 2 specwin object, PZmodels, MIIR filters, poles and zeros lists, these types won't
    be available in the popup list if any object of the same type is already shown in the parameters panel.<br><br><br>
    
    
    <h3>Reset parameter</h3>
    In the lower left corner of the window the GUI draws the '<tt>Reset parameters</tt>' button: this will reset the block to its
    empty initial state. If its a function/method block the GUI will then ask again for its list of required parameters, just like
    the block was just added to the model from the library.<br><br><br>
    
    
    <h3>Set name checkbox</h3>
    At the bottom of the window, center line, there is the '<tt>Set name</tt>' checkbox.<br>
    Enabling this the name of the output of the selected block will be assigned equal to the block's name (which can be altered freely
    by the user, standing the limitations on the block's name posed by Simulink); this will let the user to set particular and
    meaningful names instead of the automatically assigned ones, produced by the inner calculation functions.<br>
    The plot of an object assigned a  particular name, for example, will show the proper name set.<br><br><br>
    
    
    <h3>Keep local result</h3>
    Similarly to the '<tt>Maintain intermediate results</tt> checkbox in the main panel, this checkbox will mark the output of
    the selected block to be maintained at the end of the analysis, instead of being deleted just like any other intermediate
    result of the calculation.<br>
    In the LTPDA Simulink model the block will be shown with a purple background, to mark it as a 'probe' and to make it
    immediately recognizable.<br>
    Disabling the checkbox the block's background will be back to its common color, and the intermediate result produced by the
    block itself will be cleared at the end of the analysis.<br><br><br>
    
    
    <h3>Help button</h3>
    In the lower right corner of the window the GUI draws the '<tt>?</tt>' help button: this will recall the help associated to
    the function or method contained into the selected block, and it will show it into a new window.<br>
    The help shown is exactly the same available by the MATLAB command line, typing <tt>help function_name</tt>.<br><br>
   
    <h2>'Object from list' parameter</h2><hr><br>
    If the user selected a 'Object from list' (input) block into the active LTPDA Simulink model, the GUI will show:<br><br>
    <img src="images/parampanel_6.png" alt="'Object from list' parameter" border="1"><br><br>
    The only parameter which can be set in this case is the reference index contained into the input block selected: the index
    will be used together with the Input array, so setting '<tt>1</tt>' will send to the connected block(s) the 1st element of
    the Input array.<br><br>
   
    <h2>Mux/Demux parameter</h2><hr><br>
    Similarly to the 'Input from list' block, the GUI will answer a selected a Mux block into a valid LTPDA Simulink model with:<br><br>
    <img src="images/parampanel_7.png" alt="'Object from list' parameter" border="1"><br><br>
    Changing this parameter will immediately alter the mux block in Simulink; unlike the direct setting of the number of inputs
    from Simulink, the GUI will change also the size of the block, in order to make it easier to connect the blocks and to be read.<br><br>
    The same applies to Demux blocks.<br><br>
   
    <h2>'From' block parameter</h2><hr><br>
    When the user selects a 'From' block into a valid LTPDA Simulink model, the GUI answers drawing the button '<tt>Find Origin</tt>',
    which will provide a direct pointing to the address of the 'Goto' block source of that signal.<br><br>
    <img src="images/parampanel_8.png" alt="'Object from list' parameter" border="1"><br><br>
    If there's more than a single 'Goto' block, or if there's none, the GUI will show a proper warning.<br><br>
    

    
</p>