Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Crash and Burn
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Divers
Thread ID:
00043077
Message ID:
00044541
Vues:
33
>< snippage>
>Thanks for the kind words. But I think you've shown me what the problem is: CAD works ok (an application that does massive interaction with the video) but a DATABASE application craps out...Doesn't make any sense to me. It's pretty obvious that VFP is un-necessarily fussy about the video drivers, maybe it's the one stepping all over everbody else??? Oh, well, I guess I'll drop back ten and punt. <g>
>
>-RW-

In this video dilema scenario I had determined the exact problem using good ol' DOS Debug to see what was up in memory. I kept getting GPF's in the same general address range... a part of upper memory where video was not "supposed" to be. The exact addresses varied from machine-to-machine but they were close enough to smell fishy. Well regardless of what the vendor said each day when I made my bright & early disgruntled customer call, that driver was hanging onto this memory area and nothing else knew it. Now for some reason CAD had no problem with this memory area in question, but seems FOX likes to just go grab any memory it sees as available. So until they finally got me a driver that was cohabitable with FPW here's what I did to keep the CAD guys happy with their hig-dollar video and make my app useable... beware, its what I call a "Classic Fudge Job"

I modified the CONFIG.SYS so that the whole range of memory causing conflicts with the driver was excluded when EMS manager was loaded. My app worked fine then, the CAD guys took a memory hit but I convinced them it was because they played DOOM at lunch :) (shuffle-hop-step)
Roxanne M. Seibert
Independent Consultant, VFP MCP

Code Monkey Like Fritos
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform