ReleaseNotes:Planimate 4.28 Release Notes

From Planimate Knowledge Base
Jump to: navigation, search

Release notes, bug fixes and misc enhancements to Planimate 4.28


  • "_panel closed" broadcasts now get sent to all closed panels including popups and viewports, when they become hidden.

As with other system broadcasts, if the panel is a view panel, the broadcast is sent to the nearest owning dynamic panel.


  • Popup item details are always fully written to the _PLError.Txt file
  • New tables default to having 2 title rows enabled


  • New System Attribute "Last Stop Reason"

This returns a numeric code describing why the run/engine stopped LAST time. This can be very useful in handling error recovery and may make handling "just loaded" situations easier than using the "_model loaded" broadcast (but that BC is still available). Also very useful in handling restart dispatchers since the model can easily know that a "control" item will be present.
The current codes are as follows:
0 Loaded/No Previous Run no previous run, model just loaded or created 1 User Stopped Run user selected stop from menu/keyboard 2 Model Stopped Run model self stopped (exit, posted stop message) 3 Platform Required platform stopped run (closing, load/save model/scenario, editing time ref) 4 Error In Model/Engine error in model or runtime engine 5 Broadcast Option broadcast set to stop 6 UI/Portal Click Option user interaction: portal clicks, 7 Restart Dispatcher restart dispatcher restarted the run (item preserved)
I've added a label list to name these codes.

  • Have implemented fine timing/profiling of a model's run. The tests give microsecond accurate measurements. These results (when enabled) appear in the report generated by the "Show Run Profile" menu option.

The debug option "Enable Event/Routine Profiling" causes Planimate to keep track of the count, average run time, peak run time and total run time of:

  • FEC events, the time scheduled events which initiate item movement, unblocking etc.
  • Individual routine operations, summarised by individual operation type (eg: Set, Increment, Search, Dialog etc...)

These stats go a long way to identifying where a model's run time is going.
Note that enabling profiling causes a model to run at about 60% its normal speed, this is due to the large overhead in calling the system to fetch the fine timer count.
Profiling must be enabled BEFORE the run is started, setting the option during the run has no effect until the run is restarted.
There is quite a bit to say about the operations and the relevance of their times, here are some initial observations:

  • the peak time for an event may be quite large. This can occur if Windows pre-empts Planimate to run another task, the system performs network activity, the event involves animation or a dialog, or data is swapped to and from the swap file during that event.

For meaningful results try perform profiling with a lightly loaded system, as much free memory as possible and without animation. Use the the "advance to time" feature to ensure as much CPU time as possible is spent within the model you are trying to profile.
Be aware those taskbar icons, especially the "fast-starts", network monitors, virus scanners and other "helpful" utilities all consume system RAM and steal the processor occasionally so they can update themselves. This can lead to huge one-off peaks for otherwise fast operations, lasting from 10 to 500ms.

  • Using "advance to time" on a panel without spatial links seems faster than on one with them, will have to investigate this.
  • the profiler quickly identified that row inserts were taking ages (20ms average) compared to everything else (20us). It turned out the insert was on a debug table with 170000 rows and 5 columns in it, ie: a 6.8MB shuffle each time.

An append to a big table will be faster than an insert at row 1. Same for row deletes, deleting from the end will be faster.
(btw:block deletion is optimised so use it instead of row by row)

  • Iteration/ifs/whiles will tend to have a large time since PL is spending a lot of time processing within them. The results are cumulative so a nested iteration will lead to a large iteration total time.
  • A large average time for "Set" could indicate Planimate has to swap to get to data (running low on memory)


  • ODBC Data source can now be dynamically looked up via an attribute/label list

If the DSN starts with a ":" the following text is interpreted using the same mechanism as the ODBC attribute parser, hence
":pMyAttribute" will use the formatted value of portal attribute "MyAttribute" as the DSN name.

  • Table Driven Entries and Dynamic Table Column Add/Remove:

Table driven entry will no longer cause crash if the "_time" column is no longer valid. However it will NOT track movement of the time column once the run has started.
Hence if using dynamic columns with table driven entries:

  • Ensure the time column ends up in the original position as at the start of the run whenever columns are manipulated
  • Dont manipulate columns in the table unless the table is empty (no rows)

Otherwise the table driven entry may produce spurious items

  • Fixed labelling of Activity State system attribute


  • I've changed Dialog forms to be ownerless topmost. This means they always appear at the top of any other windows/popups but they dont have an owner so they shouldn't mess up the Z-order.
  • RTF notes now are placed in a stand alone application.

Required some rework of way RTF notes and DB file is handled, look out for any probs.

  • Breakpoint dialog now has a "Debug" button enabling debugging options to be changed (eg: trace animation) while still at the breakpoint/current point in the thread.


  • reworked the way the attribute rename bugfix is done to prevent it messing up the model further on load


  • Have fixed issue of attref editor feeding long names to the attribute creation dialog.
      • In addition, upon load, any attribute names which are too long are cropped to the proper length and a warning message is given:

"Model Attribute "name" cropped to 20 characters"
These long names should not have been able to get in there and may cause some of the editors to crash.
Thanks to Matt for helping identify this nasty one

  • Fixed cell stat update problem. This was introduced around


  • breakpoint dialog has option to terminate the run
  • breakpoint dialog displays comment line of routine if available


  • added a new system attribute to limit how deep PL will scan a spatial net looking for the closest target.

The attribute needs to be set each time the model is loaded, it is not saved. The default is 9999999 (ie: dont limit search depth).
Setting this value means Planimate may not chose the shortest distance path in a spatial net if it contains more intermediate nodes than an alternative which is further in distance, and the node limit happens to be exceeded in scanning the shorter path.
This will be obvious in incorrect animation but should not affect the item arrival time. In other words, reducing the search depth may cause PL to chose a route which is not the "shortest". It may also cause Planimate not to find the correct route at all (if it has too many intermediate nodes) in which case PL will report a flow error.


  • sped up allocation of routine change objects
  • sped up execution of routines in "Only During Move" mode
  • sped up portal code (track list management) and less allocation needed


  • added extra check for the "intray" to enable the "drop item" feature to be used at a given tray even if some item classes dont have the "drop" attribute defined. As long as there isn't an outgoing flow for this class, an error wont be produced.


  • no functional difference but many renames of internal modules. Im releasing this to ensure no strings have been messed up, look out for any funny titles or text in menus, forms.


  • have reworked FEC management for zero time events

The FEC now will order zero time (immediate events) as follows

  • Broadcasts - have top priority (including item and system info BCs)
  • Moves and Unblocks
  • Clock resetting/restart
  • Button clicks during animation
  • Other events (0 delays etc)

The idea is to process as many activities as possible (eg: handling BCs) before making move and unblock decisions based on the side effects due to attribute/table changes.
This (hopefully) starts to bring some order into the otherwise murky world of zero time events. You still must not depend on the order of BCs being processed, unblocks and moves being performed etc.
Let me know if the new rules raise issues with models, particularly interactive ones

  • have reworked tuple allocation/memory handling. The previous version did not handle multiple tuples of the same type properly, which would have caused problems with multiple pages printed, tables sorted etc. if you used the broadcasts returned values.

This was required to get the table edit BC working properly.


  • tables have an option to send a BC whenever any cell in selected columns is modified by any means. The bc sent includes the _row and _col of the modified cell. The routine can use this information to update data, summaries etc.

If a row/column/shift operation caused the change, then _row may be 0 (indicating potentially all rows are affected) but _col will always be properly set because separate broadcast will be sent for each column with this feature selected.
In other words, a separate BC is not sent for every cell modified but only for every column modified.
To use this feature:

  • In the table editor, use the [Table]->Advanced->Recalculate Broadcast menu to select/add a broadcast.
  • For each column that you want change notification, enable the "Send Recalculation BC" option.

The broadcast is sent to the dynamic scope of the table, with item attributes _row and _col set as described above.

  • fixed bug in msvc handling of RTF notes

seems VC does not automatically flush contents of a stream when the stream is deleted. I do an explicit flush() which seems to fix it

  • label name drop down in attribute editor is now sorted by name for all label list types. This is independent of any setting for the label list.

(let me know if this causes a delay problem with very long label lists)


  • Popup forms (like the popup selection list) now lock a parent popup from closing while they are up, to prevent their owning popup disappearing before they do.


[new file format]
  • I've implemented bulk row deletes in the internal table data structures and updated Planimate table handling to make use of it.

This will make deleting a large number of rows (using a single delete row operation) from a very large table very much faster than it used to be.

      • Look out for any problems with tables when row operations are involved.
  • Display option to hide dataset load/save menu items even if datasets are in use
  • popup panels are now properly sized when the subsystem they view has a display zoom factor set on it
  • Fixed a bug in window/scrollbar management which caused unnecessary margins when a panel was zoomed to a size bigger than the display screen
  • Fixed a bug which caused dynamic table refs replaced with standard table refs to not properly forget their P3
  • Paint buttons have an option to prevent them highlighting when clicked


  • fixed handling of table cell-specific formatting, was not properly handling default format in the new editor when other cell properties such as colour were used
  • holding down control key as model loads prevents run on load, if user has an editor key only.
  • internal rewrite, should not affect PL have reworked window management code. Cleaned up basic screen drawing code. Forms now inherit from Screen() and support scrolling, menu bars


  • another closing bug fixed. This one occurred when trying to close a Planimate application which had the File Load/Save options disabled. Planimate used this flag to determine if a modified model *could* be saved, and it coudln't, it considered it a failed save and refused to close.

I've changed it to this now: If you CLOSE PL with a model in Application mode and with the "Hide Load/Save Menu Items" option ON (the default is OFF), then any changes to the model will not be saved - even if you use an editor key.
While editing a model I suggest keeping this option off and only activating it when shipping to a client.
Heres a summary table:
EXE/KEY/MODE Can Save By Menu May Save On Close --------------------------------------------------------------------------
Full/Edit Key/Editing YES YES *3
Full/Edit Key/Application *1 *2 *3
Full/Run Key/Application *1 *2 *3
Interdyne Build/ NO NO
Stand Alone Application/ NO NO
Demo EXE (any mode) NO NO

  • 1 Only if the load/save menus have not been disabled by turning on the "Hide Load/Save Menu Items" option.
  • 2 Planimate will offer to save any changes unless the "Hide Load/Save Menu" option is on in which case changes are not normally saved.
  • 3 IF the model uses "Save And Close" or the /SAVEONEXIT command line option is used, the model will be saved.
  • fixed bug in password handling, introduced in F due to a side-effect of changing the way a function is called.


  • fixed bug in right align option for paint buttons
  • bogus message on CTRL-SHIFT-H bug for standalone EXEs fixed
  • Now we have the Save As Application functionality, I plan to drop support for "INTERDYNE" compilation builds.


  • now properly handle closing a stand alone EXE. Previous versions would not close if the model had changed which could not be saved by the EXE since saving is not available.
  • now display the following message if a close box [x] is attempted on a running/animating model

"Cannot close, a run is in progress. Pause or stop the model first."

  • The "pause" menu which appears when a click occurs during animation is now suppressed if the "clicks while running" option is enabled. The right button can still be used to display the pause menu.

The background menu can be disabled altogether using the "Dont Show background Run Menu" option.

  • Updated paint button's "visible" handling to make it consistent with other objects. "Hidden" PaintButtons will now hide when running in editing mode as well as in application mode.
  • rearranged paint button menu to make it clearer that certain options apply to each state.
  • buttons can be right aligned
  • Have slightly reworked the random number generator code. Run results should still be the same as in previous versions.
      • Note *** I'm planning to switch to a 32 bit version of the current random generator (which is 16 bit), which will yield a much finer value granularity.

When this is implemented, model runs depending on random variation will change in behaviour due to the different random sequence. This future EXE will give a warning to this effect when an older model is loaded.
Let me know if you have any comments on this.


  • fixed RTF redraw bug which caused PL to consume CPU when an RTF note was redrawn. This is due to the new RTF note library requesting a redraw at an unexpected time, probably to implement transparency (not avail in PL)
  • more internal editing, window co-ordinate function names have been cleaned up, part of fixing the RTF redraw bug.



However we've put a lot of work into updating the source to work on a different Windows compiler. Model file compatability is same as


so if you find a difference between 




, please report it.


  • old plain text notes will no longer save after an edit - convert to RTF notes. New ones have not been add-able for a while
  • porting to new compiler, look out for any strange behaviour particularly in the editors and option selection


  • Implemented basic string operations for labels:

Append To Label - appends a formatted value/label to a label Crop/Trim Label - extracts a substring of a label name Remove Label Extention - assumes label is a filespec with an extention, removes the last "." and everything following.

  • have created new routine operation flyout "Label/String" and moved some of the label operations which deal with string issues there as the label flyout was getting too big


  • New Display Option "Enable Mouse Clicks While Running" enables buttons to be selected while the simulation is running (not paused).

This works as follows:
A click on a button is processed whenever Windows gets an opportunity to process an event (Planimate yields to it). The button will visibly react to the click but the click message will be posted to the model FEC to be processed as the immediate next event.
The result of this is:

  • models which are routine intensive (eg: searching) will be rather unresponsive to the mouse whereas models with animation will be OK
  • models which have zero time logic without ANY capacity or intensive routines will take a while to get round to responding to the mouse click
  • The button clicks can occur and be processed before the completion of side effect actions as a result of the current operation.

This last point is particularly important. I may have to disable buttons which can influence a model's run (eg: broadcast) or handle them specially but this has not been implemented at this stage.

  • "Free Text" is now a value format mode rather than a table option. Only columns will work in free text mode, its not supported for attributes and individual table cells.
  • have completely rewritten table cell edit code to clean it up

Cell views now display and can be edited in free text mode.
All Table cell editing/Cell View editing needs to be validated to ensure I've not broken anything (ie: formatted value, label list, time dialog and free text) - it seems OK to me.
This rework will make enhancing editing of table cells much more straightforward

  • Compatibility Window MOVED

This version of Planimate will only load models saved with version


or later (model file version 306). Keep an older EXE to translate up old models.

This version of Planimate requires at least a Pentium level processor or compatible.

idkbase note 150