This task error occurs when certain bogus memory addresses are used. It only happens on the actual hardware, not in a PC simulation. On the PC simulation, an exception is generated and the simution will shutdown.

Some of these were generated by the User Interface edit controls if an edit resulted in any sort of modal window being displayed. The Modal window opens up a new, and recursive, message processing loop that has the possibility of deleting the edit window or supporting controls objects in memory. If there is more code to run, that uses anything in the object, this task error or memory corruption can result. Code in many of the edit controls that are susceptable to this was moved arround to minimize or eliminate the potential effects.

The main cause of these issues was due to refreshing (repopulating) the tree or grid controls in the main windows due to some asynchronous event like the setup lockout key or the coil tailout input when the Grid or Tree is in the background due to an error message or any other sort of prompt. The solution to this was to redraw the existing controls (setup lockout) or delay the refresh until the Main Window regains focus.

Refreshing is required when new elements are added or deleted that the grid needs to display.

Redrawing is acceptable when new elements have not been added or removed. We just want to update the appearance due to a value change or to indicate that an object is no longer editable like setups.

Redrawing can be an imperfect, but safe, alternative, until a Refresh can be done safely.