[CBuilder] AccesViolation

[Verwijderd]

Ik word helemaal gek hiero! Ik had me voorgenomen om niet zoveel meer te vragen maar het wat meer zelf uit te zoeken maar bij dit probleem heb ik echt geen enkel idee dus daarom wil ik het toch aan jullie vragen.

Ik doe het volgende: ik open een form(smartform)selecteer een file en druk op een knop. Zodra ik op deze knop druk wordt een ander programma opgestart.
dit programma is een simulatieprogramma van een scopemeter.
Wanneer dit programma is opgestart worden er doormiddel van windowmessaging rij/kolom regels naar dat simulatieprogramma geschreven.
Dit werkt allemaal perfect!
Wanneer ik nu dit alles stopzet en het scherm afsluit waarop alles bijgehouden is en weer terug keer naar het form(smartform) gaat ook nog alles goed..

MAAR: zodra ik smartform af wil sluiten (doormiddel van kruisje of exit button) krijg ik een accesviolation.

de code voor het afsluiten is als volgt:

code:

        ClearTheForm(); //maakt alle edit velden in het form leeg

        StressTestForm->Visible=true; // zet "Visible" van het form waarmee 
                                                        //smartform geopend kan worden op true
        SmartForm->Visible = false;    // zet "Visible van smartform op false
        Overview->Clear();                 // niet belangrijk
        Overview->Visible = false;     // niet belangrijk

alles lukt tot de regel: SmartForm->Visible = false;
vanaf dat moment krijg ik dus de acces violation.

heeft iemand enkel idee waarom?
Ik ben er al achter dat zodra de eerste rij/kolom via windowmessaging gestuurd wordt het sluiten al fout gaat.

Ik doe hetzelfde ook in een andere situatie alleen gaat het daar wel goed! maar waarom bij dit form nou niet??

heel erg bedankt

greetz

[ Voor 0% gewijzigd door D2k op 18-11-2002 09:08 . Reden: code tag gefixt ]

[LordLarry]

Ik snap even niet waar die code precies staat die je gepost hebt.

Heb je toevallig code in de OnClose, OnCloseQuery, OnDeativate of OnDestroy van het smartform?

[Verwijderd]

De code in de openingspost staat in twee methodes die het zelfde moeten doen
namelijk in:
void __fastcall TSmartForm::Exit1Click(TObject *Sender)
// een button waarmee je het form kan sluiten

en:

void __fastcall TSmartForm::FormClose(TObject *Sender, TCloseAction &Action)
// de methode voor het drukken van het kruisje
// dit is dus een OnClose in de objectinspector

[LordLarry]

Waarom zou je je form onzichtbaar willen maken en daarna weer tonen? En al je velden leeg maken als je toch verdwijnt? Maar ok, dat moet je zelf weten. Kan opzich geen kwaad als je daar maar geen bugs in gemaakt hebt.

En waarom maak je dan niet 1 functie die door beide events wordt aangeroepen?

Als je in Exit1Click gewoon
Close;
zet hoef wordt FormClose automatisch aangroepen en hoef je niet eens op 2 plaatsen die code aan te roepen.

Heb je naast de OnClose ook toevallig nog code in de OnCloseQuery, OnDeativate, OnActivate, OnShow, OnHide, of OnDestroy van het smartform?

Probeer anders ook eens mijn tips op te volgen, misschien lost dat de bug al op.

[Verwijderd]

owke ben ik weer zorry dat het zo lang duurde!
even de hierachie:

stressform
heeft: open smart button

smartform
heeft: start replay

start replay open een groot memo waarop alle loginformatie gegeven wordt

Op de een of andere manier wordt nu mijn smartform afgesloten. nu doormiddel van een Close();

dan kom ik weer heel mooi in mijn stressform maar wanneer ik dan weer terug wil naar mijn smartform krijg ik WEER een accesviolation.
waarom is dat?

Bedenk me net iets:
Er is dus een andere situatie waarin in een instellingen scherm eerst alles ingesteld wordt. dat scherm daarna wordt afgesloten en dan in de stressform op een knop gedrukt kan worden om te beginnen.

het verschil met smartform is nu dat in de smartform alle gegevens opgehaald worden. en vervolgens vanuit het smartform gestart wordt. Misschien dat dat er iets mee te maken heeft?

ik weet het echt niet meer?!?!

[LordLarry]

Hoezo 'WEER een accesviolation'? Tis pas de eerste keer in je voorbeeld dat het gebeurd.
Van je 'Bedenk me net iets' verhaal snap ik geen bal.

Do je iets van Action := caFree; in de OnClose van je SmartForm? Of SmartForm.Free ergens? Of TSmartForm.Create?

[Verwijderd]

nope nergens!

Ondertussen heb ik hetzelfde probleem in een andere situatie ontdekt dus zal de nieuwe situatie weergeven dat is makkelijker te begrijpen.

Het is echt een vaag probleem maar zal proberen de situatie nog beter weer te geven.
twee forms:
StressTestForm(startknop, knop om settingsform te openen, knop om smartform te openen)
SmartForm.

1. Met de StressTestForm kan ik de applicatie laten starten. Dan wordt een child programma geopend en die wordt dan aangestuurd via windowsmessaging.

2. Wanneer ik dit beeindig. wil ik vervolgens naar mijn smartform. Wanneer ik dus mijn smartform probeer te openen krijg ik een acces violation.

3. Wanneer ik in plaats van smartform het settingsform wil openen werkt dit wel! dus krijg ik geen acces violation.

Ik heb de situatie's genummerd en als iemand iets niet snapt dan moet ie ff nummer erbij zetten dan kan die situatie proberen nog helderder weer te geven

[curry684]

Heb je al gedebugged, en dan vooral step INTO op die crashende regel? Daarmee zou je alle events moeten raken die er op dat moment afgaan.

Mail het projectje anders maar ff door.

[Verwijderd]

Het projectje is 4MB en je kunt niet step into doen want de regel waar het mis gaat is als volgt:
StresstestForm->Visible = false;
SmartForm->Visible = true;

en dat kun je niet step INTO gebruiken

Waarschijnlijk mag ik het projectje niet eens vrijgeven in verband met geheimhouding!

sorry!

[whoami]

Als je op die knop drukt om die Smartform te openen, heb je dan wel een instantie van SmartForm?
Ik denk dat je ervan uitgaat dat SmartForm autocreated moet zijn (kijk dat eens na in Project/options).
Normaal gezien is het het beste om enkel je mainform als autocreated te definieren (en evt. enkele datamodules). Dan ga je, als er op die knop geklikt wordt, zelf een object van TSmartForm instantieren en tonen:

code:

void Button1::OnClick (TObjet* Sender)
{

   TSmartForm*  frmSmartForm;
   frmSmartForm = new TSmartForm (this);
   frmSmartForm->Show();
  
}

[Verwijderd]

Volgens mij heb ik het opgelost!! dit ga je gewoon niet geloven!

iemand bekend met: Application->ProcessMessages(); ????

ik heb dus de methode gevonden waar het mis in ging. Ervoor kon nog alles en erna niet meer. Daar ben ik de code van gaan strippen doormiddel van commentaar.
Vervolgens kwam ik in de oude situatie terug en het werkte weer gewoon.

Nu was het zo dat ik ondertussen wel in die code af en toe de regel:

Application->ProcessMessages();

ertussen geplaatst heb zodat ik ook kan beeindigen tijdens deze methode.
en om de een of andere vage reden werkt het nu allemaal wel!

En ondertussen heb ik ook weer veel van deze regeltjes weggehaald en werkt het nog steeds. Ikzelf denk dat 1 zo;n regeltje genoeg is geweest om een conflict te voorkomen met bepaalde variabelen of iets dergelijks

Misschien dat iemand een andere reden heeft waarom het nu wel werkt en eerder niet! het enige wat ik dus veranderd heb is wat meer van die regels toegevoegd aan de code! dit kan toch geen kwaad he???

[LordLarry]

Jawel, want je hebt het probleem nog niet opgelost, maar alleen de symptomen verwijderd.

ProcessMessages forceerd dat de windows message queue van je app volledig afgehandeld wordt. Ergens zal wel een message staan die anders pas na je functie behandeld was. Dat zou een close message kunnen zijn.

Ik denk niet dat we je kunnen helpen op deze manier. Kan je anders geen minimaal projectje maken waarin het gebeurd? Dan heb je ook niets met geheimhouding te maken.

[curry684]

Verwijderd schreef op 18 november 2002 @ 12:24:
iemand bekend met: Application->ProcessMessages(); ????

Je bedoelt die functie die intern geimplementeerd is als:

C++:

void TApplication::ProcessMessages()
{
MSG    l_Message;
while(PeekMessage(&l_Message, NULL, 0, 0, PM_REMOVE))
  {
  TranslateMessage(&l_Message);
  DispatchMessage(&l_Message);
  }
}

Neej, die ken ik niet En zoals LordLarry idd al aangeeft, bestrijdt je hiermee alleen de symptomen op een heel vieze manier. Je dient het structureel te vinden waar het fout gaat, bijvoorbeeld door Step Into te gebruiken op de plek waar het fout gaat:

en je kunt niet step into doen want de regel waar het mis gaat is als volgt:
StresstestForm->Visible = false;
SmartForm->Visible = true;

en dat kun je niet step INTO gebruiken

Nonsens. Het hiden van een form kan een OnHide event e.d veroorzaken, en als je die geimplementeerd hebt ga je die met Step Into wel degelijk raken. Step Into betekent voor de debugger niets anders als 'stop op de volgende beschikbare code-regel van deze thread', en stoort zich er dus niet aan dat ie wellicht eerst langs 100.000 non-debuggable coderegels komt.

Je zou er wellicht goed aan doen om advies van ervaren mensen op te volgen ipv lichtzinnig weg te wuiven, ik herinner me je nu niet echt als een expert. Bovendien ben *jij* degene die hulp vraagt.

Waarschijnlijk mag ik het projectje niet eens vrijgeven in verband met geheimhouding!

Lijkt me sterk dat een projectje waar 'StressTestForms' in voorkomen echt commercieel exploiteerbare code bevat, en dus onder geheimhouding valt.

sorry!

Sja hoeft je niet aan mij te verontschuldigen, ik vind het echt niet hopeloos jammer dat ik je niet kan helpen...

[Verwijderd]

Allereerst wil ik zeggen dat ik jullie hulp zeker waardeer!

Maar waar de fout vandaan kwam weet ik niet en daar zal ik nu dus nooit achter komen want ik kan de fout niet meer naar voren halen!
En mijn methodes gaan niet in een OnHide Event. Heb alle files gecontroleerd maar dat gebeurd niet alleen de property wordt wel of niet visible gezet en daar gebeurd verder niks mee!

Wat betreft de geheimhouding! het is mijn stage dus ik ben niet van plan om dingen te doen waardoor ik straks een half jaar stage mag gaan inhalen. ik weet niet of het wel of niet mag maar ik ga het niet uitproberen. vraag hiervoor toch een beetje begrip!

En ik ben inderdaad geen expert in programmeren!

Nogmaals bedankt voor de hulp en wat mij betreft kan hier een slotje op

[curry684]

Verwijderd schreef op 18 november 2002 @ 14:22:
Wat betreft de geheimhouding! het is mijn stage dus ik ben niet van plan om dingen te doen waardoor ik straks een half jaar stage mag gaan inhalen. ik weet niet of het wel of niet mag maar ik ga het niet uitproberen. vraag hiervoor toch een beetje begrip!

Ik heb ondertussen genoeg stagiaires begeleid, en bij mij heb je wat je eindcijfer betreft toch echt een probleem als je er onverklaarbare regels troep in je code rondslingeren... ik hoop dus voor jou dat ze alleen naar de EXE kijken en niet naar je sources.

[Verwijderd]

Ik zal je laten weten wat mijn eindcijfer geworden is

en Application->Processmessage(); vind ikzelf geen onverklaarbare regel.

Het programma waar ik mee werk is gemaakt door iemand anders en die heeft deze regel heel vaak gebruikt ik had dat niet gedaan maar merkte dat dat toch wel een handige regel is die windows dingen laat afhandelen, terwijl jou applicatie druk bezig is. dus daarom heb ik hem zelf ook op een aantal plaatsten toegevoegd. geen onbekende regels dus en al helemaal geen troep! Deze regel hoort gewoon af en toe in een groot programma en ben blij dat daarmee het probleem opgelost is! ik kan het probleem nu niet meer achterhalen maar wanneer blijkt dat het weer terugkomt heb ik dus inderdaad een probleem! Maar dat zien we dan wel weer!

Greetz!

[LordLarry]

Hehe, die regel hoort dus bijna nooit in een goed opgezet programma. Als je programma dat benodigt is het meestal tijd voor een multi threaded app...

En het mag zeker niet de problemen oplossen die jij hebt. Das namelijk niet structureel oplossen, maar verdoezelen...

[curry684]

LordLarry schreef op 18 November 2002 @ 15:32:
Hehe, die regel hoort dus bijna nooit in een goed opgezet programma. Als je programma dat benodigt is het meestal tijd voor een multi threaded app...

Da's niet waar... als je expliciet de applicatie lam wil leggen tijdens een langdurige operatie (ik heb load-routines geschreven die 5 minuten duurden op een P3-500 ) wil je dat soms absoluut niet in de achtergrond doen, maar je moet wel blijven repainten tussendoor. In sommige gevallen is ProcessMessages heel acceptabel.

En het mag zeker niet de problemen oplossen die jij hebt. Das namelijk niet structureel oplossen, maar verdoezelen...

Agreed

[LordLarry]

curry684 schreef op 18 November 2002 @ 16:03:
Da's niet waar... als je expliciet de applicatie lam wil leggen tijdens een langdurige operatie (ik heb load-routines geschreven die 5 minuten duurden op een P3-500 ) wil je dat soms absoluut niet in de achtergrond doen, maar je moet wel blijven repainten tussendoor. In sommige gevallen is ProcessMessages heel acceptabel.

Dat is 1 van de uitzonderingen inderdaad

[Verwijderd]

Hallo! Daar ben ik weer! ben blij dat er nog geen slotje op zit!

Even een vraag! ik heb de regel gevonden die zorgt voor de acces violation. dat is de volgende regel:

viOpenDefaultRM(&defaultRM);

Deze regel opent de communicatie met een matrix apparaat. En is alleen nodig voor het aansturen van een matrix. in de situatie waar ik nu mee bezig ben stuur ik een simulatie programma aan en heb ik dus niks met die matrix te maken.

Het soort test type is bekend (gebruik van matrix of pc)
twee vragen:
mag ik die ene regel omzeilen wanneer ik de pc simulatie gebruik.
moet ik daarvoor een andere methode maken die hetzelfde doet behalve de onnodige dingen!? (er staat nog meer code in die methode die alleen nodig is voor matrix en niet voor PC)

ik heb gezocht en gevonden en nu kan ik het eindelijk netjes oplossen, hoe zouden jullie dit doen?

misschien dat jullie tevens een idee hebben waarom deze regel voor mijn acces violation zorgt?

[farlane]

Omdat defaultRM geen geldige waarde meer heeft ?