--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/m-toolbox/html_help/help/ug/gui_gltpda_3_content.html	Wed Nov 23 19:22:13 2011 +0100
@@ -0,0 +1,180 @@
+<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>
+