How about Software that imports DRF files, makes scratches, and builds new DRF files.

[JustCoolGene]

PA programmers, why not build a DRF file scratch utility program?

If you own a few handicapping programs that use DRF files, you know what a hassle it is to import DRF files into each program and make scratches.
You must first go to Equibase and get the scratches, then import the DRF file into your program, and finally.. find and remove each scratched horse one at a time. You must do this process for each track you are playing.

How about a commercial software program that grabs all daily scratches from Equibase, builds a scratched horse table, and then removes all scratched horses from ALL your daily DRF files with the push of one button. Users would then have a folder with all today's DRF files with all scratched horses removed. Then users would just import a DRF file into their software and run the reports...avoiding the time consuming process of scratching each horse individually in each program.

Gene

[Jeff P]

JCapper (all versions.)

I don't rewrite the comma delimited data file - but do import scratches and races off the turf from the web. Scratches and changes are persisted to a pair of text files - one for scratches and one for races off the turf. The text files are then picked up by the JCapper program during a Calc Races routine (number crunching.)

There is some user setup involved... track name and 3 character track code are saved to a setup table. From there, a couple of mouse clicks drives processing of scratches and races off the turf for any track found in the setup table.

Been doing it since 2003 and it's as close to automatic as I can make it.


-jp

.

[JustCoolGene]

Jeff,

As an example, if I have five DRF files in my download folder, then the software will get scratches, remove them, and then rewrite my original five DRF files into five new DRF files. I then have five new rebuilt DRF files, each having all scratched horses removed, ready to use in my commercial programs.

Gene

[Jeff P]

No. See my above post. (I think I was editing it while you were replying to it.)

It wouldn't be any great trick for a JCapper user familiar with programming to parse the text files to pick up scratches and changes and then have a separate routine go through today's comma delimited text data files, remove scratched horses, and overwrite surface and distance where applicable...

But (currently) everything happens from within JCapper. The routine (purposely) doesn't touch a user's paid for comma delimited text data files.

Hope I explained most of that in a way that makes sense.


-jp

.

[Dave Schwartz]

Any reputable program would (effectively) do this. Our software starts with the basic data (from HDW, not DRF), grabs the early scratches at a couple of button clicks, and then re-ranks all the horses and changes ratings based upon the current mix of horses.

It continues to do that throughout the day as you "hit the live tote" (update) button.

[JustCoolGene]

Dave,

I think you misunderstood the kind of software this thread is about. We are not discussing an auto scratch feature that processes non-DRF files from within only one proprietary program.

We are discussing a "fully automated" software utility that takes all DRF files that a user purchased for the day and then re-creates new DRF files that include current daily scratches, distance, and surface changes... all with the push of ONE BUTTON. These "changed" DRF files will allow users quick access to much more accurate selections, reports, and rankings produced from all the different software they use.

Gene

[guckers]

We are discussing a "fully automated" software utility that takes all DRF files that a user purchased for the day and then re-creates new DRF files that include current daily scratches, distance, and surface changes, all with the push of ONE BUTTON. These "changed" DRF files will allow users quick access to much more accurate selections, reports, and rankings from all the different software they use.

Gene

I'm willing to try putting something together for this... It sounds really up my alley of tool development...

Is someone willing to share a few hours to walk me through the drf format (since I don't use drf), and where you would get scratches and other changes to recreate the chart you need.

[BIG49010]

The problems you will run into with bris, if you take the original file and then delete a part or change say the race surface, and then save the new comma delimited file, they won't work when you use their Custom PP program and perhaps other programs that are available.

There are hidden details which cause the program to crash. I can't tell you anything about DRF, but I am assuming you are speaking to have one program for all vendors.

[DJofSD]

If you're using data files from BRIS then look at field number 5. To mark that entry as a scratch, change the string to the letter "S".

[Dave Schwartz]

I think you misunderstood the kind of software this thread is about. We are not discussing an auto scratch feature that processes non-DRF files from within only one proprietary program.

We are discussing a "fully automated" software utility that takes all DRF files that a user purchased for the day and then re-creates new DRF files that include current daily scratches, distance, and surface changes... all with the push of ONE BUTTON. These "changed" DRF files will allow users quick access to much more accurate selections, reports, and rankings produced from all the different software they use.

I understood what you meant but fail to see the difference between removing a horse from the file and just removing all traces of the horse from the race.

Please enlighten me.

[JustCoolGene]

CJ already has a program like the one described in this thread which his subscribers have used for years. It is "fully automated" and uses BRIS DRF files that a user purchased for the day and then re-creates new DRF files that include current daily Equibase scratches, distance, and surface changes, all with the push of ONE BUTTON. The only difference is that CJ replaces pace, late, and final BRIS figures with his own figures. His users can then use this "replaced" file in most commercial software available including the BRIS PP Generator. The BRIS PP Generator works great and displays and prints CJ's figures any way you want in the racing form. His program works flawlessly, however you need to use CJ's data. The only problem with CJ's program is that the BRIS figs are replaced into new locations within the BRIS files. This causes problems in some software. CJ's software removes all data related to scratches before the file is rewritten back as a new BRIS file. He has the solution, it's too bad it doesn't work without having to use his figs, otherwise it would be a perfect solution. Maybe CJ will help BRIS users out!

Gene

[Dave Schwartz]

Oh, I get it. Less printing.

[Tom]

I would buy a program that would take all my BRIS files and makes scratches, surface changes and re-write the file.

[JustCoolGene]

The main point of having a "replaced" or "rewritten" BRIS files is that the user could then import the new file into software such as RPM, Tom Console, A+, MPH, Power-Online, Sartin, and many others to quickly produce accurate program selections and metrics without having to make changes for each horse individually within each program. Most users don't make these changes because it's too much of a hassle, thereby relying on less than accurate results. Race selections change if you scratch the LONE front runner or take the race off the turf.

Gene

[Dave Schwartz]

You make changes on individual horses?

I don't. Load up the scratches and they're done.

Surface changes are a small issue, but you can do it on a race-by-race basis, except track condition. That can be done for the "rest of the card."

[JustCoolGene]

Dave,

Over the last 20 years, many people in the world have purchased many of the BRIS based programs discussed and we all need the ability to "Load up the scratches and they're done" feature you mention. Users would then have a "state of the art" scratch utility for all the programs we bought that did not have the feature built in. That is precisely the reason we need the software utility discussed.

[GameTheory]

Dave,

Over the last 20 years, many people in the world have purchased many of the BRIS based programs discussed and we all need the ability to "Load up the scratches and they're done" feature you mention. Users would then have a "state of the art" scratch utility for all the programs we bought that did not have the feature built in. That is precisely the reason we need the software utility discussed.What you are talking about is very easy now that we have a reliable scratch feed from Equibase -- personally I've been using my own "scratch-watch" program that monitors the RacingChannel/Phonebet toteboard for scratches, but you need an account for that. (I think the toteboard is a little better because you never miss a late scratch, except maybe a last second gate scratch. I think maybe the Equibase feed isn't always up-to-date with scratches that occur after the card has started.) But anyway, it could be easily redone using the Equibase feed which is open to everybody, and the reprocessing of DRF or BRIS files is trivial, although as some mentioned BRIS programs may not react well to data tampering. Third-party programs probably won't care.

The one thing you're glossing over is that you'd have to re-run it many times a day and re-process the files as new scratches come in all the time, so it isn't one and done for the whole day. (Or it could just stay running in the background and alert you if there are new scratches -- it could check every 10 minutes or something.) But as long as you're willing to restart your programs as needed with the updated files, it is no big deal. If someone wants to pay me to make such a thing, they can have it in a day or two...

[DJofSD]

Dave,

Over the last 20 years, many people in the world have purchased many of the BRIS based programs discussed and we all need the ability to "Load up the scratches and they're done" feature you mention. Users would then have a "state of the art" scratch utility for all the programs we bought that did not have the feature built in. That is precisely the reason we need the software utility discussed.
It's a great goal, however, some of the old software, like those programs of the AODDS era, require use of the so called HAT files. These files have a checksum or security feature that is a part of the data file when you download from BRIS. This is the extra data in a trailing field. As I recall from many years ago, without that extra tidbit, some of the programs will not work.

You can try to change the data file and rewrite it using the trailing token found at the end of each record but I don't know if that will be sufficent. If you are using programs with this little quirk, you're just going to have to try it to see what happens.

[JustCoolGene]

I will purchase a copy from whoever builds the most comprehensive version of the software. I really don't want to hire a contract programmer to do the work. I would then own the rights to the software and I really don't want to get into marketing, sales, upgrading, and support.

There is a market for whoever builds the software. Afterall, there is 20 years of BRIS-based software currently being used.

Gene

[openhorse]

Users would then have a "state of the art" scratch utility for all the programs we bought that did not have the feature built in.
Dec 26, 2010, Webside Story is fired as contractor for DRF Web programming.
Replaced by internal team using RSS feed and real time updates for scratches - direct from Equibase.

Enough users wanted real-time entries justifying this massive overhaul. The first in a decade at DRF. They are doing what they can at the HTML Pure-Results level because the data hasn't been normalized (i.e. Stacked PP's 6 deep for BRIS). This is done to compensate for the frustration of the data providers not being able to update Static Context in the data files they sold only hours before. The real purpose of Formulator Web.

Handicapping software that uses this type of pre-generated data file is known within certain circles as the 'The O'Henry House Model'.

Though this type of software is common, the pitfalls indicated so far in this thread indicate that it is not a perfect solution for getting an accurate results set over the long haul. Yes, you can scratch horses during input, but what about all the other factors that need to be re-calculated on the fly: like Jock Change, Rail Ft, and some of the permutations ...?

The pre-generated PP is a great convenience, because you are paying for someone to extract for you a subset of Static Context from a world of computers quite capable of generating Dynamic Context. However, To assume this is the only way to write software that predicts winners is a complete fallacy.

The reason is simple. Pen and Paper is easily automated - you really can run your own DRF on your desktop/laptop and generate all your own context nowadays. Run your meets, run your stats, build your card, and bet. Thank Moore's Law.

In conclusion, I suggest the best way to solve the problem of having innaccurate entries or jockeys is to:
Change your school of thought - and have your software actually build something original - that no one else will ever have.

[headhawg]

If you're using data files from BRIS then look at field number 5. To mark that entry as a scratch, change the string to the letter "S".Has anyone used this method for scratches? Field 5 is intended for scratches of an entry (or entries, I suppose), but I was wondering if this could be used as a scratch flag for any horse. It would be much easier to use than having a scratch list file. I'm curious if there are any gotchas by using field #5 as a generic flag.

[vegasone]

I have been using that field for scratches forever. Wrote a little program to check scratches online and update database field.

[headhawg]

Thanks vegasone. I assumed that it would be ok, but I wanted to know if anyone else had done it this way and might warn me not to do it.

[MitchS]

I run multiple programs and scratches can be time consuming and tiresome. A little utility program like this would be SWEET!

[vegasone]

It is written in VB6 and was a quickie. Got tired of updating manually. It works with Access , but it is trivial to modify to work with SQL, MYSQL or EXCEL spreadsheets. If you want source let me know.


Takes about 3 seconds to run all scratches on all tracks.

[teddy]

I applaud you finding a way to handicap outside of the box, based on other factors. No one else is doing that so at least you have some promise to be the first. Short term cycles is preached over and over on the MTN handicapping show. Trainer intent also...

[openhorse]

The problems described in this thread, and the amount of work required to correct them even partially, at best, were in fact the entire reason i went 'back to the' old skool Pen & Paper approach: following the jockey pool from Meet to Meet within a single Race-Circuit.

Adding in 40 trainer angles just seemed like the common sense thing to do; having a grandpa who was a trainer at Santa Anita for a brief time.

Viewing the game from the perspective of grains of sand which you color yourself, vs. a pre-colored brick, requires a change in one's school of thought, 'back to the' old skool Pen & Paper approach. Thanks to Moore's Law, what was not possible 20 years ago with .2 Mhz computers is more than possible with a dual core on your desktop today. Right now.

To those who believe this is impossible, the automation of common-sense 800 year old handicapping methodology, with a modern programming language (not one with Beginner in the Acronym), please continue looking at a gift horse in the mouth.

Here is an example of SpotPlays generated from grains of sand, pure results. Not a solid brick to whittle down and wonder where the context came from. With todays Scratches and Rider Changes, of course.

Santa Anita: Letting the cat out of the bag here: Backwheel the favorite with these trainer angles on maiden SWT races.

-------------Santa Anita Trainer Spot Plays 3/24/2011

[headhawg]

I really don't want to hire a contract programmer to do the work. I would then own the rights to the software and I really don't want to get into marketing, sales, upgrading, and support. I really didn't want to give free advertising but some people might be interested. Apparently Gene has had a change of heart. $150 is steep in my opinion even though I know how long it takes to develop software. Ebay link (http://www.ebay.com/itm/ScratchManager-Horse-Race-Handicapping-Software-Re-Creates-Your-Daily-BRIS-Files-/320892092871?pt=LH_DefaultDomain_0&hash=item4ab6a8c1c7)

[GameTheory]

I really didn't want to give free advertising but some people might be interested. Apparently Gene has had a change of heart. $150 is steep in my opinion even though I know how long it takes to develop software. Ebay link (http://www.ebay.com/itm/ScratchManager-Horse-Race-Handicapping-Software-Re-Creates-Your-Daily-BRIS-Files-/320892092871?pt=LH_DefaultDomain_0&hash=item4ab6a8c1c7)
There is a website also:

http://scratchmanager.com/

[JustCoolGene]

GameTheory And Headhawg,

Thank you for your comments. I didn't want to mention Scratch Manager on the board because I am not a sponsor on PaceAdvantage.com. Mike has sent me the details on becoming a sponsor, however, I haven't made a commitment to him. I have worked very hard with a new member named Tyler who goes by the name of "doubleback" on the board. He was great to work with and very talented like many software programmers here on PaceAdvantage. I hope people don't get mad at me for discussing Scratch Manager. Tyler and I built the program as a service to all the PaceAdvantage users of BRIS single files. We don't expect to make money on this project. We hope to just make enough to cover some of our costs in time and effort.

Headhawg, I respect your opinion regarding the cost of Scratch Manager being a little steep, so I have listened to you and dropped the retail price
____________________________________

Thanks To Everyone At PaceAdvantage,

Gene

[classhandicapper]

I'm bumping this because I'm looking for a solution this problem right now.

I'm looking for a way to get all the scratches for a race card in a text or Excel file. Then I could easily import them into a scratch table in my database and exclude any horses I want from the handicapping reports I generate for that day's card before the races start.

It's too much work to do manually for multiple tracks but I need it because some of the reports are pace sensitive.

[sjk]

I am still doing it manually after all these years and don't find it takes much time. I make a table in the database with all the runners and a factor of 1.0001. I look at the scratches and delete the leading 1 (making a factor of .0001) for those listed. Only takes a few minutes for all the tracks.

[headhawg]

When I was working on HHXv3 I wrote an scratch routine for it. There was both an auto and manual scratch component to it. The autoscratch would check with the Equibase site for scratches, write the scratched horses for all tracks loaded to a text file, and then put the 'S' flag in field 5 so HHX would know not to run any calculations on that horse. The user could also manually scratch if he/she had no Internet connection. Attached is a text file sample.

It's been three years since I wrote that code so I have know idea if it works 100% anymore. Track names may have changed; the Equibase XML file may have also changed. Writing the parser in Liberty Basic sucked, but it seemed to work ok at the time. Took me a lot of hours.

[vegasone]

It is really very simple to extract the scratches from the equibase site at the end of the day or during the day. Mostly though I would compare the results file with the initial group of runners and get a scratch list that way.

I pull the scratches in the morning before handicapping. This is done automatically and it is updated later when testing by comparing runner lists.

[classhandicapper]

I am still doing it manually after all these years and don't find it takes much time. I make a table in the database with all the runners and a factor of 1.0001. I look at the scratches and delete the leading 1 (making a factor of .0001) for those listed. Only takes a few minutes for all the tracks.

That's approach I was contemplating. Naturally, I already have a table with all the horses running. I could easily extract Track, Date, Race, Horse, and have 1 field empty (scratch filed). Then I could manually alter the scratch field before I run my daily reports and exclude the marked ones.

I was hoping to automate that somehow. In fact, I'm kind of shocked it's not an existing service somewhere already. The number of database handicappers isn't large, but if you are already creating PP files the service would be quick to develop and might attract people if priced low enough.

[classhandicapper]

When I was working on HHXv3 I wrote an scratch routine for it. There was both an auto and manual scratch component to it. The autoscratch would check with the Equibase site for scratches, write the scratched horses for all tracks loaded to a text file, and then put the 'S' flag in field 5 so HHX would know not to run any calculations on that horse. The user could also manually scratch if he/she had no Internet connection. Attached is a text file sample.

It's been three years since I wrote that code so I have know idea if it works 100% anymore. Track names may have changed; the Equibase XML file may have also changed. Writing the parser in Liberty Basic sucked, but it seemed to work ok at the time. Took me a lot of hours.

That's exactly what I am looking for.

[QuickHorse]

How about if the software would update the scratches in real-time using its built in Live Tote Board? That would be kind of neat.

Mike

[classhandicapper]

I'm bumping this again because I'm getting tired of marking scratches manually or having to recalculate some things manually because of scratches.

Does anyone have a good automated way to get "today's scratches" into a text file, Excel file, database etc..?

[mikesal57]

I'm bumping this again because I'm getting tired of marking scratches manually or having to recalculate some things manually because of scratches.

Does anyone have a good automated way to get "today's scratches" into a text file, Excel file, database etc..?

Class...

See if this can help you...

Click XML file and open in NOTEPAD...

I'm sure someone here can write you a program to incorporate this info...

http://www.equibase.com/static/latechanges/html/latechanges.html#sthash.jp77oS0W.dpbs

mike

[headhawg]

I'm bumping this again because I'm getting tired of marking scratches manually or having to recalculate some things manually because of scratches.

Does anyone have a good automated way to get "today's scratches" into a text file, Excel file, database etc..?This would be child's play for a real programmer. For someone like me it would be a lot of hours that I just don't have. The code that I wrote for HHXv3 may still work, but it only does scratches for the data files that are loaded; it doesn't parse the XML files for all of the tracks.

But just out of curiousity -- what would the txt/csv file look like to you (or are you looking to have the data file modified)?

[Jeff P]

I've been doing this for scratches, surface changes, and race distance changes in JCapper for years.

Last year, after closing day for Saratoga, I bit the bullet and spent the better part of three weeks adding changes in track condition and rider changes.

That said, getting it done turned out to be a lot more work than I imagined going in.

Mistakes, corrections, and corrections of corrections for all of the above mentioned changes types can and do show up in the xml.

It's not terribly difficult to handle the more common cases once you've seen them.

But there are a number of hurdles you'll have to overcome - mainly for the things you don't expect.

For instance, sometimes a track somewhere will ask Equibase to change the name of their track -- with the result being that one day out of the blue the new track name shows up in the xml and breaks your parse routine.

After reprogramming the app several times for those I ended up creating a table with a user interface that gave the user the ability to make those kinds of changes on the fly.

When I enabled parsing of rider changes I discovered there are differences between the rider names in the xml and the rider names in the data file and/or chart file for the same rider.

To handle those I ended up creating a table that (among other things) contains fields for rider name as read from the xml and rider name for the same rider as read from the data and/or chart file -- plus a parse routine that runs automatically to populate the data file or chart file side of the table -- plus a button the user can click to clear the table -- plus a second button the user can click to manually initiate the populate table with rider names routine...

Plus an aglorithm that matches rider name as parsed from the xml with the data file name for that same rider -- with a high degree of accuracy.

I found it really helpful to auto-strip any and all punctuation characters from names on all sides (data file, chart file, and the xml) before doing any name matching.

In something like 997 out of 1000 cases the name matching happens automatically behind the scenes - and rider changes process seamlessly. (To make this work you need to have clean data sitting in the table.)

But for the rare case where the algorithm fails to match a name:

I ended up creating a formal user interface enabling the user to perform manual rider changes. Sometimes the rider name in the data file is something like "no rider" -- or the rider name in the xml is an obvious data entry error -- or something incomplete like "tbd" or "tba", etc. And every once in a blue moon you have a new rider name in the xml for somebody who happens to be picking up his or her very first mount.

Obviously, under those circumstances auto-name matching isn't going to happen.

Having a manual rider changes interface also comes in handy for late rider changes announced as the field faces up to the gate.

In such cases the horse is returned to the paddock so it's not uncommon for several minutes to pass before the change is announced or appears on the track video. But somehow such changes have a way of not showing up in the xml so you can parse them (at least not before the race goes off.)

The formal interface for manual rider changes enables the user to pull up the current horse after selecting date-track-race from drop downs -- select the replacement rider name from a drop down pre-populated with rider names sitting in the table -- or alternately key the replacement rider name manually -- and then persist the change by clicking an Apply button.

To my way of thinking a rider change entails more than just a name change. It also entails stats changes. Sometimes the stats changes are significant enough to cause a change in probabilities not just for the horse with the rider change but for the other horses in the field as well.

To that end I created an algorithm to pull up stats for the replacement rider and overwrite the existing rider name and stats in the data file with the replacement rider name and replacement rider stats.

None of this required what I'd call true brilliance. But I wouldn't call it child's play either.

By posting this -- my hope is that someone who decides to take this on will end up avoiding some of the obstacles I encountered along the way.



-jp

.

[mikesal57]

AWESOME write up Jeff , as usual..

Just hope you didn't scare away any takers...:lol:

Mike

[headhawg]

None of this required what I'd call true brilliance. But I wouldn't call it child's play either.classhandicapper just asked for scratches, which I have done already, so I know that anyone with real coding skills could do it easily hence the "child's play" comment. If the XML structure or track name changed that obviously the code would need to be updated. Doing all the things that were in your post is obviously much more challenging. And scraping a real time tote for data...well...that is waaay out of my league.

[chuckster1968]

I jumped ahead to the end of the thread because I would like to know if there is there a software out there that can import the DRF Files into a window of software whereby you can circulate through each horse as Post Time Daily does in Black Magic yet can create on top simple factors such as Bet Mix or Stat Lens whereby you the handicapper can take the figures and point out all the obvious you are looking for. I believe the most important thing Valuecapper does is point out the odds line. So I would love to make a software that can do this.. or is there a software that could do this??? I want to be able to see horses past performances the way you look at it on paper or online and to be able to have the factors at the top of the page..??

Anybody interested in doing this..

[classhandicapper]

Thanks for all the input.

This is what I was doing before.

As part of my daily run I systematically create a table with all the tracks/horses for today. I have a field in that table called "scratch indicator" that I can manually mark for any horse(s) that were scratched. Then all subsequent reports exclude those horses.

Now I am:

1. Downloading the Equibase daily XML scratch file. I'm not familiar with how to work with XML files, but I found that it's easy to import that XML file into Excel where it gets reformatted into some very neat columns.

2. I import that Excel file into another predefined table in my database.

3. I run a scratch Query that matches the 2 tables and marks all the appropriate horses as scratched. :headbanger:

There are probably some things I can do to automate it further, but this is already a great start.

Jeff, that was some great stuff, but what you are doing is well beyond my needs at this point.

I generate a series of reports for the day that are would describe as "running style report", "pace projection report", "track/distance/surface profiles report", "class ratings report", "race flow upgrades/downgrades report", and "bias upgrades/downgrades report".

A quick glance at those reports allows me to quickly jump to the tracks, races, and horses that might present an opportunity. Manually marking scratches was a pain in the neck.

[sjk]

Nice work. Still doing it by hand but that sounds like something I should try.

Not having any luck getting into Excel. I am running a very old version; don't know if that makes a difference.

[sjk]

It is easy in new Excel. Thanks for the tip.

[sjk]

Thanks again, I had no idea what an xml file was but it works very nicely. I have to dumb down the excel format and move the file to a different machine but it won't take more than a couple of minutes to do it all.

[classhandicapper]

It is easy in new Excel. Thanks for the tip.



I owe you a lot for all the help setting up my database. Glad to help.

[vegasone]

If you want to get really fancy you can use their RSS feed to also get the scratches. Would take a little work to get it into a database, etc.

[Tom]

HDW provides HTR a scratch file that we just import into the program and scratch every track at once. Certainly makes life easy.

[classhandicapper]

HDW provides HTR a scratch file that we just import into the program and scratch every track at once. Certainly makes life easy.

I'm cheap. :D

[chuckster1968]

So I have a question? I would love to be able to create a similar system to Black Magic etc. I know I will get the condescending comments etc. I am not so much interested in spitting out the top horses although I think any normal handicapper can look at Brisnet Files/Equibase Files/DRF Files/ etc. and plug in their own version of numbers and come up with consensus because numbers have crunched and crunched and keep getting crunched. So, my idea is or what I love the most about Pizzola software is the fact that you can open the past performance within his window and view it a normal mode say as drf or brisnet, whereby the running lines do not look like an excel spreadsheet all the time because to me personally it somehow cannot get used to reading past permformance in excel format. I would love to be able to be able to have that past performance like Brisnet or Equibase or drf and be able to view it within the file and be able to extract or have it extract say for example 25 variables or 10 handicapping variables. e.g. Best Pace # Best Beyer Figure Best Trainer stat. etc. and be able to click on the past performance and be able to move that to the top of your software so you take say, the old style whereby we mark up the page and scan and make notes etc. I think the user should be able to pick what he sees? or both perhaps. Does this sound stupid?. We all agree that we are always looking for something within the lines and data that shows us the obvious. I want to be able to take out a running line, take out a speed factor and place it at the top of the page or data box and compare to the rest or like Bet Mix give it my own number. Bet..Mix way to many colors for me. I use Master Magician right now.. many horses in top three, the odd longshot. Full Card Reports.. the man calls some interesting Value Horses.. something happend to him. I do not want his icons or his data.. I want to be able to have the past performance in traditional style and to be able to scroll through each horse but somehow take out the factors and place them up at the top. Similar to Pizzolla.. Is this allowed, is it possible?? Who would I contact? Any interest in designing such a product.. I know there are so many excel files... But it has to be easy to read and user friendly.. Is it possible?

[chuckster1968]

Dave does your software HSH import DRF Files and can you see the past performance in the same fashion while HSH spits out data???

[mikesal57]

Dave does your software HSH import DRF Files and can you see the past performance in the same fashion while HSH spits out data???

Before you go crazy with HSH...I dont know if Dave is selling it anymore and if he did.....you cant afford it....data files and a $1000+ program = too much for you

Mike

[chuckster1968]

What right do you have to say that me?

[chuckster1968]

and its still available on his website... I do not know who you are..but how do you know.. what kind of person says that.. Are you a jerk?

[chuckster1968]

Maybe I misread the line but I am looking for a software that can import drf files and to be able to see the past performances in the same format as it actually is or design won that allows you to scroll similar to Post Time Daily and Black Magic./Valuecapper. However, I believe the user should be in control of the factors and then decide what he can use in terms form patterns, speed figures, times, class etc. I wonder if it is possible?

[chuckster1968]

no reply wow