[delphi] verdwijnende applicatie

[Alarmnummer]

Een deadline zou een deadline niet zijn als er op het allerlaatste moment niet een enorm dikke fout naar voren komt, waardoor de gehele applicatie verdwijnt alsof ie er nooit is geweest. Aub geen commentaar over het niet beter testen, ik moet tijdelijk bij dit project assisteren om het op tijd klaar te krijgen.

Ik wil dus weten of er niet een manier is om te kunnen tracen waar het probleem zich precies voordoet. Ik weet bij welke button het verkeerd gaat, maar er wordt zoveel code uitgevoerd daaronder en het is zo`n puinzooi dat het een onmogelijke taak is om het op die manier te achterhalen. Ik krijg verder nog een grijs dialoog voor een seconde te zien, en daarna is de applicatie zonder spoor verdwenen. Zoals je ziet is het niet echt duidelijk, maar ik zou bij god niet weten waar ik anders zou moeten beginnen.

[edit]
Er is al een custom exception handler toegevoegd, maar die krijg ik dus al niet eens te zien.

[ Voor 8% gewijzigd door Alarmnummer op 17-03-2003 10:19 ]

[SWfreak]

Verdwijnt alleen het window, of verdwijnt ie ook uit de TaskManager? Dan zou je kunnen kijken of er ergens iets met het window gedaan wordt.
Verder zou ik niet veel beters weten dan alles met een debugger nalopen...

[Verwijderd]

Wat gebeurt er als je hem in de IDE loopt?

[Alarmnummer]

SWfreak schreef op 17 March 2003 @ 10:18:
Verdwijnt alleen het window, of verdwijnt ie ook uit de TaskManager? Dan zou je kunnen kijken of er ergens iets met het window gedaan wordt.
Verder zou ik niet veel beters weten dan alles met een debugger nalopen...

De gehele applicatie verdwijnt uit de taskmanager alsof het nooit heeft bestaan.

[Kappie]

Les 1: Altijd rustig blijven en proberen helder te denken

Verder wat meer informatie. Staat het programma nog wel in het geheugen of wordt het helemaal afgesloten. Gebeurt dit altijd of enkel na een aantal akties. Welke functie had deze knop. Anders moeten in het wilde weg gokken waar het aan kan liggen.

Verder zou ik die enorme berg code in stukken verdelen met breakpoints of iets degelijks om uit te vinden waar het precies fout gaat.

[Verwijderd]

Probeer zoveel mogelijk blokken code uit te sterren (commentaat van maken), totdat de applicatie weer blijft staan.
Dan weer commentaar verwijderen, misschien kom je er zo achter wat de oorzaak is.

Wat mij wel is opgevallen, is dat dit soms gebeurd als je componenten gebruikt, die weer andere software (lees dll's etc) nodig hebben. Wij hebben dit gehad met een Applicatie die interbase gebruikte, dus Interbase componenten op het Form. De applicatie verdween dan als ie gerunned werd op een machine waar geen interbaseclient op was geinstalleerd.
We maken dit soort componenten nu dan ook in runtime aan, zodat we eerst wat controles kunnen uitvoeren.

Misschien heb je een soort gelijk probleem ?

[ Voor 9% gewijzigd door Verwijderd op 17-03-2003 10:26 ]

[Alarmnummer]

Ik ben nu ook bezig om code aan een uit te schakelen om te kijken wanneer het goed gaat.

En er wordt ook een dll gebruikt waarin alle sql commando`s uitgevoerd worden. Maar deze dll is al lang in gebruik (eigen brouwsel), maar is altijd stabiel geweest, zelfs voor de dingen waar hij nu voor gebruikt wordt.

[ Voor 56% gewijzigd door Alarmnummer op 17-03-2003 10:45 ]

[killermar]

Als het steppen door de code te lang duurt, kan je ook een hele zooi breakpoints plaatsen die zoveel mogelijk van de (waarschijnlijk) gebruikte methods beslaan. En dan beginnen met steppen na de laatst 'behaalde' breakpoint.

[Alarmnummer]

Ik heb bij een unit die veel met tekst werkt de buffers allemaal met 10/100 vermenigvuldigd en ik heb de fout tot nu toe niet meer gekregen.

ik vind het in ieder geval goed genoeg

[LordLarry]

Ik zou een logger gebruiken om te achterhalen wat de flow is van je programma, maar dat is pas echt nuttig als je tenminste een beetje idee hebt waar je moet zoeken. Lijkt er op het voorstel van killermar, maar veroorzaakt iets minder RSI

[killermar]

LordLarry schreef op 17 maart 2003 @ 11:43:
maar veroorzaakt iets minder RSI

heheh idd en LordLarry's idee is nog reuseable ook!

[Alarmnummer]

Leuk stukje code.

code:

procedure PCharToItems(buffer:PChar;Lijst:TStrings);
var
  i    : integer;
  s,z : string;
  bron: boolean;
 // brongevonden: boolean;
begin
  i:= 0;
  s:= '';
  z:='';
  bron:=false;
  brongevonden:=false;

  while (buffer[i] <> #0) and (bron=false) do
  begin
    if s= 'BRON' then brongevonden:=true;
    if (buffer[i-1] <#32) then begin
      if (buffer[i]<#32) then  bron:=true;
      end;
    if (buffer[i] > #32) or (buffer[i] = tab) then
    s:= s + buffer[i]
    else
      if (buffer[i] = #32) and (Length(s) < 150)  then
        s:= s + buffer[i]
      else
      begin
       Lijst.Add(s);
       s:= '';
      end;
    Inc(i);
  end;
  Lijst.Add(s);
//  if not brongevonden then Lijst.clear; //belangrijk voor oplossing
end;

Oja, die brongevonden een een globale variable voor het oplossingen scherm en verder is dit een algemene routine.

[ Voor 7% gewijzigd door Alarmnummer op 17-03-2003 12:24 ]

[Reptile209]

Alarmnummer schreef op 17 March 2003 @ 12:21:
Leuk stukje code.

code:

[...]
  i:= 0;
[...]
  if (buffer[i-1] <#32) then begin

Errr, als je dus de eerste keer deze if doorloopt (i = 0), zit je met element buffer[-1] te werken? Dat vraagt (schreeuwt?!) om problemen .
Dus of i anders laten beginnen, of voor deze test een andere if die checkt dat i>=1 is.

[Alarmnummer]

Reptile209 schreef op 17 maart 2003 @ 15:34:
[...]
Errr, als je dus de eerste keer deze if doorloopt (i = 0), zit je met element buffer[-1] te werken? Dat vraagt (schreeuwt?!) om problemen .
Dus of i anders laten beginnen, of voor deze test een andere if die checkt dat i>=1 is.

Ik heb het niet geschreven hoor