JCapper Message Board

          General Discussion
                      -- build 198

"Prerequisites List for seamless parsing of rider changes from the XML:

1. You must install a current version Build 198 ver 2.0 (or later) c:\2004\JCapper.mdb file.



2. You must be running JCapper Build Build 198 ver 2.0 (or later.)



3. The Data Vendor Setting persisted on your User Sys Defs Screen must be: HDW.



4. You must have valid entries in the TrackAbbreviations table for those track codes where you want Scratch BOT to be able to parse changes from the XML. (See the separate section on the TrackAbbreviations table below.)



5. You must Populate the CXNNames table in your current version Build 198 ver 2.0 (or later) c:\2004\JCapper.mdb file with rider names.



6. The following settings must be persisted in your Enhanced Settings Module as:
   
   HDW File Mgr Initial Data Folder: -1 Override DFM Checkbox.
   
   CXN Names Formating: 0 Remove Punctuation Characters. (It cannot be 1 Punctuation Characters Left Intact.)
   
   Scratch BOT: 0 All Scratches in the XML or 2 Block Vet Scratch Display on Reports. (It cannot be 1 Scratches For Loaded Card Files Only.)
   
   Rider Changes: -1 Rider Changes ON.



7. One or more .JCP files for today’s race date must be loaded into the program using the DFM Card Loader.
   
   Note: If you are running a third party Excel spreadsheet and you have loaded .JCP files into that spreadsheet – in all likelihood Excel will place a lock or .ldb file on any .JCP files loaded into that spreadsheet.
   
   Be aware that Scratch BOT will not be able to write replacement rider names and stats to .JCP files that have been locked by a third party Excel spreadsheet.
   
   Your best work-around would be to remove lock file(s) by closing down the spreadsheet prior to running an XML parse routine. (And then relaunch the spreadsheet afterwards.)


When the above prerequisites have been met: Scratch BOT seamlessly parses and processes rider changes from the XML."

"No response from file build is killing me"

"Chris, there's a LOT of places in JCapper where implementing the same technology can will go a long way towards making the user experience better.

The following areas are (now) on my list:

• Build Database Routines

• Calc Races

• JCP and XRD file build routines

• Data Window Queries

• Data Window Exports



-jp

."

1. HDW File Mgr .JCP File Build Routines
   
   During a .JCP File Build Routine - if you look to the bottom right hand area of the screen - the interface now displays continuous status updates that describe the current operation being performed.
   
   With each status update the HDW File Mgr also updates Windows with information about it's current state. As a result, Windows now appears to treat the program window where the HDW File Mgr is running as currently active (continuously about 98% of the time that .JCP file build routines are being run.)
   
   Note that .JCP file build routines don't run any faster - but the display of status updates on the face of the module with each new operation now enables you to see what is happening behind the scenes while each .JCP file is being built - and the total elapsed time where Windows buts in and displays "Not Responding" on the module's title bar now appears to have been drastically reduced.
   
   Here's a screenshot that I took of the module this morning while it was in the middle of an HDW File Build Routine for 17 .JCP files:
   http://www.jcapper.com/messageboard/avatars/HDWReader_10142016.jpg
   
   The above screenshot catches the module while the .JCP file for FNO was being built while A/E Trainer Profiles were being created. Had I taken the screenshot a second earlier or later it would (likely) have caught the module while a different operation was underway.



2. Main Module SQL Build Database Routines
   
   During build database routines in Modes 3, 4, and 5, a very subtle update (for the human eye) takes place on the face of the Main Module.
   
   As each new horse is processed - the current horse is assigned a number. From there the label on the face of the Main Module (just above the progress bar) showing the filename of the current .DAT file being processed is updated. For even numbered horses 3 dots or "..." (without the quotes) are displayed next to the current file name. Odd numbered horses display 4 dots to the right of the filename.
   
   Also, with each update to the number of dots: The Main Module now updates Windows with information about its current state. As a result, Windows now appears to treat the program window where the Main Module is running a SQL Build Database Routine as currently active (continuously about 98% of the time while sql build database routines are being run.)
   
   Note that sql build database routines don't run any faster - but the subtle display of status updates in the form of dots on the face of the Main Module as each new horse is processed now enables you to see, provided you look carefully (but why in the world would you even want to?) that a new horse is being processed behind the scenes.
   
   The desired effect though is that the total elapsed time where Windows buts in and displays "Not Responding" on the Main Module title bar now appears to have been drastically reduced.




3. Main Module Calc Races
   
   During Main Module Calc Races routines - or more specifically - during the Creating Export File part of a Calc Races - another very subtle update (for the human eye) takes place on the face of smaller pop up screen that displays the progress bar for the Calc Races.
   
   As data for each new horse is being written to the export file - the current horse is assigned a number. From there the label on the face of the pop up screen (just above the progress bar for the File Export part of the Calc Races) is updated with either 3 dots or 4 dots. For even numbered horses 3 dots or "..." (without the quotes) are displayed just above the progress bar on the pop up screen. Odd numbered horses get 4 dots.
   
   Also, with each update to the number of dots: The Main Module now updates Windows with information about its current state. As a result, Windows now appears to treat the program window where the Main Module is running a Calc Races as currently active (continuously about 98% of the time while the File Export part of a Calc Races is being run.)
   
   Note that Calc Races routines don't run any faster - but the subtle display of status updates in the form of dots on the face of the pop up screen as each new horse is processed now enables you to see, provided you look carefully (but again why in the world would you even want to?) that a new horse is being processed behind the scenes.
   
   The desired effect though is that the total elapsed time where Windows buts in and displays "Not Responding" on the title bar of the Calc Races pop up screen now appears to have been drastically reduced.