Set64rs-Change-from-dbgrid-to-flexGrid

This is a sub list of Set64rs-Software-Issues

SetProfilePointer

• should update ControllerConfiguration table in db to set ProfileExecuting display.

ReadControllerProgramLimits

• needs to store PRL/PRH in the db

UpDateControllerConfigurationTable

• FUNCTION: updates PRL / PRH in database at bootup > checks to see if range is in ProfileLog

• called by:
  • bootup in form_activation

>>>>relies on ReadRunState to read fresh values ...only does current channel at bootup form activation

>>>>should freshen up the values it stores itself rather than relying on other routines

>>>>should be called by InitializeInterface so it occurs when channel is switched

RESOLUTION: appears like might be redundant after fixes below : ELIMINATED

Daisy chain of routines badly apportioned

ChangeChannel > Sets up recordsets for given channel at bootup and upon switching channels : was name InitializeInterface

• called by:
  • ProfileChannelNumberDisplay_Click > When the channel changes

• calls:
  • RecallProfileExecuting
  • ReadRunState

>>>>is there redundant code at bootup to do the same thing? RESOLUTION: YES: eliminated redundant data.recordset setting commands

RecallProfileExecuting > recalls profile name from config table > Sets pointer arrow in ProfileLog to match this > sets profile name display field: RESOLUTION: Rolled into SetProfilePointer

• called by:
  • BootUp > not needed as ChannelChange calls it > ChannelChange is in BootUp !
  • ChangeChannel
  • StartProfileButton > this could lead to erroneous results: better to mash RecallProfileExecuting into SetProfilePointer and call it instead. It will always highlight the physical settings!

• Calls:
  • SetProfilePointer

>>>> currently uses PROFILENAME to set ProfileLog pointer > this risks not flagging user of erratic PRL/PRH pointers >>>> should use freshly read PRL/PRH ?

SetProfilePointer > was setting dbgrid.row = row with name matching that recalled from configuration db table

• updated to use direct access to physical hardware to get PRL/PRH and determine which profile is set to run.
• RecallProfileExecuting rolled into SetProfilePointer

• called by:
  • RecallProfileExecuting

>>>currently uses PROFILENAME to do the set > Should use freshly read PRL/PRH? RESOLUTION: YES: now uses

Corresponding routines that might need work

StoreProfileExecuting > Stores PROFILENAME, LOWADDRESS, HIGHADDRESS in config db

StoreProfileExecutionState > Stores mdlProgramModeNumber, CurrentSegment, SegmentTime in config db