D2009 Exception

[EWeiss]

Mir ist kein anderen threadnamen eingefallen.

Meine Funktion welche ich hier schonmal gepostet habe verursacht in D2009 beim 2 Aufruf ein
Exception Exception in "blaaa, blaa" aufgetreten.

Delphi-Quellcode:

procedure TSkinConfig.AppendToLinkedList(nReading: Integer; sBuffer: string);
begin

  New(FPBuffer);

  if nReading = 0 then
  Begin
    New(FToPBuffer);
    LineStart := FToPBuffer;
  end;

  FPBuffer^.Nr    := nReading;
  FPBuffer^.Str   := sBuffer;
  LineStart^.Max  := nReading;
  FToPBuffer^.Ptr := FPBuffer;
  FToPBuffer      := FPBuffer;

end;

procedure TSkinConfig.FBuffin(FileName: string);
var
  sBuffer: string;

begin

  if not FExist(FileName) then
    Exit;
  try
    try
      Assignfile(ParseFile, FileName);
      reset(ParseFile);

      while not eof(ParseFile) do
      begin
        ReadLN(ParseFile, sBuffer);
        AppendToLinkedList(nReading, sBuffer);
        inc(nReading);
      end;
    except
      raise Exception.Create(SysErrorMessage(GetLastError));
    end;
  finally
    nReading := 0;
    CloseFile(ParseFile);
  end;

end;

und zwar wenn das zweitemal

Delphi-Quellcode:

New(FPBuffer);

aufgerufen wird.
Beim Awendungsfenster tritt das problem nicht auf nur beim
Modal erstellten Window.

In D2006 gibt es keine probleme diesbezüglich.
Mit Exception Exception kann ich nichts anfangen keine Nummer nix wird zurückgegeben.

gruss Emil

[WM_CLOSE]

GIbst du den speicher auch irgendwo frei? und mit Dispose? Außerdem würde ich das AssignFile über das try-finally setzen, da im Fehlerfall versucht wird eine Datei, die nicht geoffnet ist zu schließen.

[EWeiss]

Zitat:

Zitat von WM_CLOSE (Beitrag 1097720)

GIbst du den speicher auch irgendwo frei? und mit Dispose? Außerdem würde ich das AssignFile über das try-finally setzen, da im Fehlerfall versucht wird eine Datei, die nicht geoffnet ist zu schließen.

Im Fehlerfall springt er in except nicht in finally.

Nach dem erstellung des HauptFenster werden die Resourcen wieder freigegeben.

Delphi-Quellcode:

  // Resourcen Freigeben
  FPBuffer := nil;
  Result := True;

sowie das TextFile

Delphi-Quellcode:

CloseFile(ParseFile);

gruss

[mkinzler]

Zitat:

Im Fehlerfall springt er in except nicht in finally.

In finally, sollte er auf jeden Fall verzweigen

[EWeiss]

Zitat:

Zitat von mkinzler (Beitrag 1097722)

Zitat:

Im Fehlerfall springt er in except nicht in finally.

In finally, sollte er auf jeden Fall verzweigen

Habe es jetzt so umgelegt das er hineinspringt.
Und das AssignFile über try (finally gesetzt)

Ändert aber nichts an meinem problem.

Reicht ein

Delphi-Quellcode:

FPBuffer := nil;

nicht aus? Nachdem das Hauptfenster erstellt wurde?
Warum dann noch ein Dispose?

gruss

[WM_CLOSE]

Es gibt leider keinen Garbage Collector in Delphi:
Man muss den Speicher, den man allokiert (mit new) wieder Freigeben(mit Dispose). Das nilen des Pointers reicht da nicht aus, da der Wert dahinter immer noch existiert.

Normalerweise ist sowas "nur" ein Speicherleck und sollte keine Exception werfen, aber wer weiss.
Vielleicht liegt der Fehler wo ganz anders

[EWeiss]

Zitat:

Zitat von WM_CLOSE (Beitrag 1097729)

Es gibt leider keinen Garbage Collector in Delphi:
Man muss den Speicher, den man allokiert (mit new) wieder Freigeben(mit Dispose). Das nilen des Pointers reicht da nicht aus, da der Wert dahinter immer noch existiert.

Normalerweise ist sowas "nur" ein Speicherleck und sollte keine Exception werfen, aber wer weiss.
Vielleicht liegt der Fehler wo ganz anders

Also wenn ich den Buffer mit dispose freigebe dann kracht es direkt.
Warum auch immer, bekomme dann nicht mal die HauptAnwendung(Fenster geladen)

Delphi-Quellcode:

      while not eof(ParseFile) do
      begin
        ReadLN(ParseFile, sBuffer);
        AppendToLinkedList(nReading, sBuffer);
        inc(nReading);
        Dispose(FPBuffer);
      end;

wie gesagt das problem habe ich nur mit D2009

gruss

[EWeiss]

Jetzt sagt mir doch mal bitte was ist mein Problem
Das ein und die gleiche Funktion in D2006 funktioniert und in D2009 probleme verursacht.

Habe alle relevanten Code Teile gepostet.

gruss

[WM_CLOSE]

Könntest du den Code vielleicht etwas erklären?
Und vielleicht den kompletten Exception-Text posten (Strg-C auf das Exception-Fenster)

Das Dispose muss man dann aufführen wenn man das den Record nicht mehr braucht.
Wird das FPBuffer an der Stelle nicht mehr gebraucht? Wenn ja, warum ist es dann ein Feld des Objektes und keine Varaible in der Procedure?

Sorry, aber ich bin nicht den ganzen Tag im Forum:oops:.

[EWeiss]

Zitat:

Sorry, aber ich bin nicht den ganzen Tag im Forum

Deshalb ein Extra Danke schön das du dich mit meinem Problem beschäftigst.

Zitat:

Das Dispose muss man dann aufführen wenn man das den Record nicht mehr braucht.

Habe es geändert.

Delphi-Quellcode:

  // Resourcen Freigeben
  Dispose(FPBuffer);
  FPBuffer := nil;
  Result := True;

Zitat:

Könntest du den Code vielleicht etwas erklären?

Schau bitte das Bild 3 an wie sich der Record bzw.. der buffer gefüllt wird.

Delphi-Quellcode:

  PParseFile = ^TParseFile;
  TParseFile = record
    Nr    :Integer;
    Str   : string;
    Ptr   : PParseFile;
    Max   : Integer;
  end;

Delphi-Quellcode:

  TSkinConfig = class
  private
    ParseFile            : TextFile;
    LineStart            : PParseFile;
    FPBuffer             : PParseFile;
    FToPBuffer           : PParseFile;

ParseFile.. erklärt sich von selbst (die TextDatei halt)
LineStart.. hier wird der Maximale Counter (Zeilen in der Textdatei festgehalten)
da sich beim einlesen der nächsten Zeile der letzte FPBuffer leert benötige ich LineStart als Platzhalter für den letzten (aller) Counter.

FPBuffer.. wird initialisiert indem ich den Pointer auf LineStart setze
FToPBuffer.. enthält die Pointer der Records von PParseFile abhängig vom Counter LineStart 0 to max Zeilen.
LineStart erhält dann den kompletten Record von FToPBuffer in dem alle Daten von FPBuffer enthalten sind.
Siehe!

Delphi-Quellcode:

FToPBuffer := FPBuffer;

Hoffe meine Erklärung ist ausreichend.

Danke.

gruss Emil

[WM_CLOSE]

Hast du zufällig den FastMM zur Hand? im FullDebugMode?
Der könnte wichtige Infos zeigen.

vielleicht auch mal den String rauslassen (->temporär in ein Char umwandeln).
Vielleicht könnte auch ein Finalize helfen.

Ansonsten weiß ich auch keinen guten Rat:cry:

[EWeiss]

Zitat:

Zitat von WM_CLOSE (Beitrag 1097967)

Hast du zufällig den FastMM zur Hand? im FullDebugMode?
Der könnte wichtige Infos zeigen.

vielleicht auch mal den String rauslassen (->temporär in ein Char umwandeln).
Vielleicht könnte auch ein Finalize helfen.

Ansonsten weiß ich auch keinen guten Rat:cry:

Sorry wie meinst du Finalize ?

gruss

[WM_CLOSE]

ICh weiß nicht ob finalize das richtige ist. das hab ich nur grad beim googlen gelesen. Ist sowas ähnliches wie Dispose (bitte nicht hauen wenn falsch)
ist vielleicht das das richtige wonach du suchst: http://www.delphipraxis.net/149061-e...te-listen.html

Sorry ich muss jetzt auch passen.

Probier mal den FastMM, vielleicht zeigt der an was schief läuft.

[EWeiss]

Zitat:

Zitat von WM_CLOSE (Beitrag 1097970)

ICh weiß nicht ob finalize das richtige ist. das hab ich nur grad beim googlen gelesen. Ist sowas ähnliches wie Dispose (bitte nicht hauen wenn falsch)
ist vielleicht das das richtige wonach du suchst: http://www.delphipraxis.net/149061-e...te-listen.html

Sorry ich muss jetzt auch passen.

Probier mal den FastMM, vielleicht zeigt der an was schief läuft.

Danke ..
Kein problem wenn du nicht weiter weist.
Stehe ja selber auf den Schlauch glaube das die D2009 einfach zu verbuggt ist :) hehehhe

Mit den ganzen Unicode Kram.

Beispiel:
Nehme ich PAnsiChar dann meckert der compiler..
Ersetze ich es mit PChar meckert er nicht übersetzt aber in der System.pas PChar automatisch wieder zurück nach PAnsiChar. (Was für ein Quatch)
Verwende ich anstelle von PChar(System.PAnsiChar) PWideChar dann aktzeptiert der Compiler das auch ohne zu meckern beläßt es dann aber so wie es ist.
Das ist die einzigste möglichkeit warum es bei D2009 kracht weil irgendwelche Übersetzungen wieder mal nicht korrekt sind.
Aber wie den Fehler feststellen wenn der eigene Compiler nicht dazu in der lage ist die richtigen UNcode Variablen zu zuweisen.

PS:
Noch ein kleines Beispiel zum anschauen.

Delphi-Quellcode:

constructor TSkinTrackBar.Create(hOwner: HWND; FullpathImageName: string;
  x, y, tW, tH, ButID: integer; tMin, tMax: Integer; tVal: Integer;
  ARGBcolor: COLORREF; PROGRESScolor: COLORREF);
var
  wc:     TWndClassEx;
  myClass: PWideChar;

begin

  inherited Create;

  //with SkinEngine do
  //begin
    if tMin = tMax then
      Exit;

    myClass := 'SKTRACKBAR';
    wc.cbSize := SIZEOF(wc);
    IsInitialized := GetClassInfoEx(SkinEngine.skInstance, myClass, wc);
    if IsInitialized = False then
    begin
      wc.cbSize     := SIZEOF(wc);
      wc.style      := CS_HREDRAW or CS_VREDRAW or CS_DBLCLKS or CS_PARENTDC;
      wc.lpfnWndProc := @TrackProc;
      wc.cbClsExtra := 0;
      wc.cbWndExtra := EXTEND_EXTRA * 4;
      wc.hInstance  := SkinEngine.skInstance;
      wc.hIcon      := 0;
      wc.hCursor    := 0;
      wc.hbrBackground := 0;
      wc.lpszMenuName := nil;
      wc.lpszClassName := myClass;
      wc.hIconSm    := wc.hIcon;
      if RegisterClassEx(wc) <> 0 then
        IsInitialized := True;
    end;

Delphi-Quellcode:

myClass: PWideChar;

laut GetClassInfoEx richtig definiert.
Funktioniert nicht mit PAnsiChar aber mit PChar
welches dann von der System.pas wieder in PAnsiChar zurück definiert wird.
Was für ein Blödsinn.


gruss

[EWeiss]

WM_CLOSE:
Danke nochmal für deine Hilfe.
Habe meinen Code dank deiner Hilfe verbessert.. siehe Dispose ;)

Das problem lag aber nicht an meiner Parser Function sondern
daran das ich vorher

Delphi-Quellcode:

  DrawTextToDC(DC, GetCTLText(ParentHandle), x, y, gColorCaption, SK_CAPTIONFONT,
    SK_CAPTIONFONTHEIGHT, -1, 0);

den Text mit string anstelle von WideString übergeben habe.
Das hatte zur folge das der Pointer "strFormat" in der GDI+ einen Fehler verursachte
da dieser nicht gültig war.

GELÖSST!

gruss

[brechi]

Naja ich versteh nicht warum du nicht einfach:

Delphi-Quellcode:

GetClassInfoEx(SkinEngine.skInstance, 'bla', wc);

machst. Bzw. einen WideString deklarierst und als PWideChar castest (wie AnsiString/String mit PChar).
Im übrigen verwendet du eine objektorientierte Sprache, warum der Umstand mit den verketteten Listen und Pointern, wenn eine TObjectList und eine Klasse um einiges eleganter und weniger fehleranfällig wäre?

[EWeiss]

Zitat:

Zitat von brechi (Beitrag 1098447)

Naja ich versteh nicht warum du nicht einfach:

Delphi-Quellcode:

GetClassInfoEx(SkinEngine.skInstance, 'bla', wc);

machst. Bzw. einen WideString deklarierst und als PWideChar castest (wie AnsiString/String mit PChar).
Im übrigen verwendet du eine objektorientierte Sprache, warum der Umstand mit den verketteten Listen und Pointern, wenn eine TObjectList und eine Klasse um einiges eleganter und weniger fehleranfällig wäre?

Und wie nennst das ?
TSkinTrackBar

keine klasse?

na ja hab schon geschrieben gelösst.

gruss