Fejlsoegning ved Access Violation?

1. http://www.eurekalog.com/index_delphi.php
et af de bedste fejlsønings programmer

Det program har jeg proevet foer, men da jeg ikke er informatiker (hedder det saadan paa dansk??), kommer jeg til kort.

Hvad siger du til 2 og 3??
Det maa da vaere noget, alle overvejer, naar de programmerer.

forstår nu ikke helt hvad du mener, det program fortæller dig 100% hvilken linie, hvilken unit og hvilken Class fejlen sker

hvorfor vil du sortere i en unit?
delphi ved  jo hvor de er
brug evt. [CTRL]+ venstre klik

jeg har f.eks. en function vare: string;

den kalder jeg med vare;  hold CTRL nede flyt musen hen på navnet og klik

Ad. 1: AV er dødbesværlige for de kan opstå helt andre steder end der de materialiserer sig. Forestil dig et editor-dialog der skriver i en del af programmets hukommelse som først senere udføres. Fejlen viser sig der men er et helt andet sted. Her hjælper hverken Madshi eller Eurikalog.

Du må prøve at koble funktionalitet fra. Enten bottom-up eller top-down (hvis ellers man kan bruge de udtryk her). Enten tage nuværende status og fjern funktionalitet en efter en, eller prøve at fjerne alt og tilføje en efter en.

Hvis nogen har en nemmere tilgang (udover gennemlæsning af al programkode), så lytter jeg også!

Ad. 2: Delphi 2006+ sorterer alfabetisk og det bør du lade den gøre. Jeg tror godt du kan justere via eksempelvis GExperts. Jeg flytter lidt rundt på mine metoder, så de der funktionsmæssigt er tæt på hinanden også kommer til at stå tæt.

Ad. 3: Den rigtige måde her er, at flytte den fælles part over i en tredje unit som de to andre refererer til. Om det så enten er "utility" funktioner eller klasser du udskiller, det er her programmørens fantasi spiller ind.

Hvis der er fælles kode i flere klasser så kan man også lave en baseklasse som indeholder den fælles del. Det er meget hensigtsmæssigt at flytte til en separat fil - og sådan OOP er tiltænkt.

Endelig kan du, men det er ikke kønt, lave includefiler. Det kan jeg ikke anbefale

(lige en kommentar til min kommentar 3). Da jeg er en krakiler mht. navngivning af komponenter og klasser så plejer metoderne at placere sig pænt i pas-filen. Det hænder dog jeg "refaktorerer" et navn (skift-ctrl-e) og så er det jeg nogle gange også flytter funktionen. Hvis jeg har tre knapper der bruger samme event (metode), så omdøber jeg den f.eks.

Ad 1. glem det der debug program, det får du ikke noget ud af, den vil sikkert bare sige der ikke er debug-info og så er du lige langt :-)
Du kan evt. lure på om du har nogle com-objecter du bruger som vindows frigiver og du derfor ikke skal, det lyder somom der er noget du Free'er som "nogle" andre ryder op :-)

ad2. Gør som du synes er bedst, delphi er lige glad :-)

ad3. hold selve klasse koden i samme pas-fil, og drop inc-filer, og gør som hrc skiver, du kan evt. også kigge på om du skal bruge nedarvning, hvis din klasse er meget stor, kunne det måske være en fordel. :-)

Saa kom der da feedback for pengene :-)

Uddybning af spoergsmaal 3:
Jeg har f.eks. en Form1 med flere Edits, ComboBoxe etc.
Naar der trykkes paa en knap, ligeledes paa Form1, genereres en Excel fil med info fra naevnte komponenter.
Denne Excel funktion hoerer aldeles kun til Form1, og skal aldrig bruges andre steder.
Da funktionen kan anses for en separat lille program-stump, vil jeg gerne laegge den i en separat fil, for at goere min Form1-unit mere overskuelig.
Da funktionen skriver direkte til andre komponenter paa Form1 (hvilket jeg ikke vil betegne som fusk, da funktionen normalt er en direkte del a Form1's Unit), er jeg jo noed til at lave en cirkulaer referance mellem den eksterne Unit, jeg laegger den i, og Form1's Unit.
Og det vil jeg betegne som fusk.

Hvad soeren goer jeg saa, naar jeg oensker at beholde min Excel funktion som den er?

Ps.: med cirkulaer referance mener jeg:

Form1:
uses
  MinEksterneUnit;

MinEksterneUnit:
uses
  ...
implementation
uses
  UnitMain;

Du kunne også lave din Excel-klasse så generisk at den blev fodret med de komponenter/lister den skal aflevere resultatet i, via constructoren.

Eks.


eller


Jeg laver altid mine klasser så de ikke ved andet end det de bliver fortalt. Det kan jeg kun anbefale.

hrc har altid ret :-)

og du har selv helt ret i at det er snavn med cirkulare uses, det vil også gi problemmer hvis du en gang skulle få lyst til at lægge dit program i runtime pakages, så siger delphi FY SKAMME :-)

Du kan evt. en anden gang gøre brug af FindComponent, så kan du finde comp, på en form du ikke user.

Tak Martin, tak. Jeg labber det i mig (og glemmer helt der er noget der hedder ironi og sarkasme) - og nej. Jeg har ikke altid ret, men der nogle simple regler jeg har forbedret over tid. En er at undgå cirkulære referencer. En anden at isolere klasserne.

I er mange herude som er meget mere alsidige. Vidste ikke det med runtimepakkerne.

Hvis js_delphis program skal plukke detaljer ud af excel-filen og placere dem i et hav af komponenter så kunne man lave en constructor som fik fik formen over og en TStrings som indeholdt komponentnavn og celle. Så kunne FindComponent placere det hele hvor det skal, uden at excel-klassen aner det mindste om hvordan formen er opbygget.

dyrt købt erfaring fra tidligere arb. vi havde 30+ units med problemet:-(

Har jeg forstaaet det rigtigt, hvis jeg siger:

efter jeres mening findes der ikke en fornuftig maade at opdele kode i flere filer, uden at denne kode laves som separate funktioner/metoder/klasser, der kaldes vha. overgivne parametre?

noget i den retning :-)

Ja, det er vist essensen. Nu hvor logikken er tæt koblet til din form, så er det i alt fald en mulighed.
Jeg synes egentlig godt om ideen med at mappe data til en (eller flere) komponent(er) (via TStringlisten) og lade FindComponent'en kigge efter den. Ulempen er, at man skal holde huske at rette alle steder hvis komponenten skifter navn. Alternativt kan du bruge komponenternes tag til at styre hvor data skal puttes: Komponenterne med tag = 1 får datoen indsat. Tag = 2 er navn osv.

OK, tak for jeres inputs.
Laeg svar alle.

Åk

:-)

vallemanden, hvad med dig??