Home > Support > Features


Application: Studio
Version: v6.1
Tool: All

Records found: 22

Status: P: Pending, S: Suspended, C: Corrected, R: Not reproductible.

Select feature id:
Description contains:
Select application:
Select application version:
Select tool:

Tool acronyms: IN: Installation, LM: License management, UE: UML editor, ME: MSC editor, TE: Text editor, SE: SDL-RT editor, PM: Project manager, PG: Prototyping GUI, CG: C code generator, MT: MSC tracer, MD: Model debugger, MS: Model Simulator, MV: Model validation, DE: Document editor, TT: TTCN-3 support

Tool id description comment date status forecast
* 4699 The file selection dialog on Linux lacks a lot of usual and convenient features, such as a favorites bar or the history of the browsed directories. It would be much better to use a file selection dialog consistent with the current desktop environment so that the user finds back the same features as in the other applications.  Done. There is now a preference to use the dialog for the current desktop environment if it can be figured out and if the corresponding command is installed (kdialog on KDE or zenity on GNOME). The same has been done for color chooser dialogs, and also for info and question dialogs, if these are not already displayed as panels in their parent window (see feature 4693).  2023-11-27 C v6.1 
* 4693 It could be interesting to handle standard dialogs in a consistent way across platforms: today, when for example asking for a confirmation, the dialog is a separate window on Windows & Linux, and a panel inside the parent window on macOS. When the dialog is a window, its placement is also inconsistent between platforms (centered on the parent window on Linux, centered on the screen on Windows); it also has minimize, maximize and close buttons in its title bar which are unneeded on a dialog. It could be better to handle everything as it is done on macOS: a panel within the parent window.  Done. There is now a preference (set by default) to display info & question dialogs as panels inside their parent window. The save/discard/cancel dialog has been handled the same way, since it looks a lot like the info or question dialogs,   2023-11-27 C v6.1 
*E 4703 The color selection dialog is awkward to use and doesn't look like any other color selection dialog on any platform. It would be better to change for a more up-to-date and "modern"-looking one.  Done. The color selection dialog has been remade by using the gradients already used in the diagrams, giving it a much more modern look. It follows the same conventions as the color selection dialog in some Windows applications: a bar allows to select the hue for the color, then a zone above allows to select its saturation and value. Red, green and blue components are available as entries, as weel the Hue, Saturation and Value, and the hexadecimal representation of the color.  2023-11-27 C v6.1 
CV 4826 Today, the only way to sort code coverage results is by number of hits. It would be nice to be able to also sort by agent name, which would make the comparison of two sets much easier.  Done. The 'Sort' entry in the 'Edit' menu in the model coverage viewer window is now a submenu, allowing to sort either by number of hits or by name. Sorting by name means that all agents are sorted by agent name, and inside them, the states are sorted by name, the transition by name of the incoming signal and all symbols in the transition by type first, then by text.  2024-11-13 C v6.1 
CV 4823 When a set of model coverage results is in covered / uncovered mode (i.e, without the minimum and maximum number of hits displayed, but just a checkbox), nodes having partial coverage are not very visible: they have an unchecked box just as those that are not covered at all, just in a different color. It would be better to have another mark clearly separating the partially covered nodes from the uncovered ones.  Done. The marker for partially covered nodes is now a hatched box instead of an empty one.  2024-11-05 C v6.1 
CV 4552 It would be better to use "model coverage" instead of "code coverage" everywhere, as there is sometimes no actual "code" to cover (e.g, simulation).  Done. Done in Process as well.  2023-01-26 C v6.1 
ME 4819 Today, when the visibility for message parameters in the MSC editor is "abbreviated", a parameter with a complex value is represented by an empty string. This is not very useful, and can actually be confused with an actual empty styring. It would be better to represent it another way to show that there is something there, but it cannot be shown.  Done. A complex parameter will now appear as something like "[...]" in the text of the message when abbreviated.  2024-10-22 C v6.1 
ME 4820 In a MSC, if the message visibility is not "full", it impacts only the parameters for messages. But the MSC can also include synchronous calls with complex parameters, so it would be nice if this option impacted them too.  Done. Parameters for synchronous calls now appear just as message parameters. Note that this does not impact return values, as they are not structured as parameters.  2024-10-22 C v6.1 
MV 4818 Support complex parameters in incoming messages for system validation with OBP. Today, only parameters with a basic type can be used.  Done. The possible values for message parameters of any type can now be defined via templates that are used during OBP exploration. These templates replace the former feature that only allowed for constraints to be put on parameters with a simple type. Now all parameters are displayed, even complex ones, and several sets of constraints can be entered for each.  2025-01-14 C v6.1 
MV 4837 Figure out automatically for each variable in each behavioral agent if it should or shouldn't be included in the OBP system state. A variable can be excluded from the system state if each symbol that reads it is always preceded by a symbol that sets it in the same transition.  Done. There is a new button under the variable constraints zone in the OBP validation profiles allowing to figure out automatically if all variables should be included in the system state or not.  2025-01-14 C v6.1 
MV 4825 Today, running an OBP exploration on a SDL system systematically forces the regeneration of all bytecode. But this regeneration is not always necessary, it would be better to have an option for that.  Done. An option has been added in the OBP options for exploration. Note that having the code coverage active is required for the exploration, so if the chosen simulation profile does not have it activated, the bytecode will always be regenerated, regardless of this option.  2024-11-05 C v6.1 
MV 4824 When running an OBP exploration on a SDL model, there is no possibility to choose the profile that will be used for the simulation. But some profiles may prevent the simulation from running properly, e.g profiles with no XML-RPC server defined when the SDL system needs one. It would be better to be able to choose the profile that will be used for the exploration.  Done. A selector for the simulation profile to use has been added to the OBP options for exploration.  2024-11-05 C v6.1 
MV 4531 When running an exploration, if a message coming from the environment has parameters with an infinite number of values, the exploration runs anyway and the problem is spotted when the message can actually be sent to the running system. It would be better to spot the issue before running anything and prevent the exploration from even starting.  Done. The verification is now done just after the bytecode generation for the system, and the results are displayed in the same output dialog. If any message coming from the environment has a parameter with a non-bounded value, an error is displayed and the exploration doesn't start.  2023-01-20 C v6.1 
MV 4527 It would be nice to add a 'comments' field in the OBP exploration profiles, or even one comment field for each tab.  Done. A comments field has been added to each tab in the OBP profile.  2023-01-18 C v6.1 
MV 4525 It would be nice to be able to stop OBP exploration as soon as the code coverage reaches 100%.  Done. A checkbox has been added under the exploration kind in the 'BP run' dialog, allowing to stop the exploration when the code coverage rate reaches 100%. Note that this is checked at each heartbeat.  2023-01-17 C v6.1 
MV 4526 Add a 'stop' button in the OBP exploration progress dialog allowing to stop the exploration completely to be able to extract the partial code coverage.  Done. There is now a 'stop' button allowing to abort the exploration and which makes the code coverage extraction available. Note that the exploration cannot be resumed after an abort.  2023-01-17 C v6.1 
MV 4538 In the OBP progress dialog, it would be nice to have the code coverage rate displayed.  Done. A field has been added that display the code coverage rate in percentage, refreshed at each heartbeat. The code coverage rate is also highlighted at the end of the exploration if it's not 100%.  2023-01-17 C v6.1 
PM 4860 After a conversion from a PR/CIF file, there can be a lot of warnings displayed when the converted project is opened. Today, when some of these warnings are considered as not important, they have to be selected one by one to dismiss them. It would be nice to have a more efficient way to do that, for example being able to select all the warnings that are not actually errors, or having categories for the warning/error messages.  Done. The generated warnings now have a kind and a category, and the dialog displaying them allows to select the warning having a given kind and/or a given category.  2025-02-12 C v6.1 
PM 4859 When importing a PR/CIF file, all behavioral agents are first imported as legacy diagrams, then converted to new-style. It would be much safer and more efficient to directly create them as new-style diagrams, since these have a structure that is very similar to the PR.  Done. The PR/CIF import now directly creates new-style behavioral diagrams.  2025-02-12 C v6.1 
PM 4822 In the OBP exploration profiles, message constraints and variable constraints cannot be scrolled with the mouse wheel.  Done. Scrolling with the mouse wheel n,ow works as expected on all platforms.  2024-10-24 C v6.1 
SE 4856 Some configurations of implicit and explicit joins in a legacy behavioral diagram may cause the PR export or the conversion to new-style to fail. This typically can happen if a symbol is just after a label as well as the target for several links.  Obsolete. The PR/CIF import now uses the structure defined in the PR to create directly a new-style diagram, so this kind of issue can no more happen, since the structure of new-style behavioral diagram is very close to the structure of the PR file.  2025-02-12 C v6.1 
SE 4691 In the new-style behavioral editor, there is no possibility to save partitions in their own file as in other diagram types, or as in the legacy behavioral diagram editor. It would be nice to allow it too.  Done. As in other editors, the partition attributes dialog now includes a choice for where the partition should be stored: either in the diagram file, or in its own file.  2023-11-15 C v6.1