tat. und form. Var-Param. - fuzzt aufeinmal nicht mehr? D2K9

[oki]

Mal ne doofe Frage, wo und wie definierst du ptrResult?

[Alter Mann]

@oki

siehe Link im ersten Beitrag.

[oki]

Zitat von Alter Mann:

@oki

siehe Link im ersten Beitrag.

Ah klar, hatte ich übersehen.
Wie steht es mit der lokalen Variable PWideChar?

Vielleicht so?

Delphi-Quellcode:

...
var PProps : PWideChar;
...
  PProps := PWideChar(@Properties[0]);
  hr := search.ExecuteSearch(StringToOleStr('(objectCategory=' + Category + ')'), PProps, dwCount, ptrResult);

[Alter Mann]

Hi oki

Ich kann nicht erkennen worauf du hinaus willst.

Wie schon geschrieben, das Problem taucht erstmalig mit Delphi 2009 auf,
alle anderen Versionen(D5, D7, D2005, D2007) compilieren den Code 1a.

Oh, dazwischen gefunkt.

Habe es probiert; Ergebnis: "Zugriffsverletzung im Modul 'msvcrt.sll'".

Es scheint ein reines Delphi 2009 - Problem zu sein.

[oki]

Jo, dann bin ich am Ende. Kann das auch nicht überprüfen, da D2007. Macht mir aber etwas sorgen das Problem. Hab solche Konstrukte nie als Problem gesehen und relativ oft verwendet. Sollte mich dann erst mal mit D2009 zurückhalten

Gruß oki

[Alter Mann]

Mir ist da noch etwas aufgefallen.

Beim setzen der SearchPreference werden zu Abfangen eines Fehlers statische 'Array of WideChar' verwendet

Delphi-Quellcode:

var
...
  szErr     : array[0..255] of WideChar;
  szName    : array[0..255] of WideChar;
  idx       : Integer;
  found     : Boolean;
begin
  if SUCCEEDED(ADsGetObject(edtADsPath.Text, IDirectorySearch, Search)) then
  begin
    try
      opt.dwSearchPref   := ADS_SEARCHPREF_SEARCH_SCOPE;
      opt.vValue.dwType  := ADSTYPE_INTEGER;
      opt.vValue.__MIDL_0010.Integer := ADS_SCOPE_SUBTREE;
      if not SUCCEEDED(search.SetSearchPreference(opt, 1)) then
      begin
        ADsGetLastError(dwErr, @szErr[0], 254, @szName[0], 254);  // <- hier klappt es
        ShowMessage(WideCharToString(szErr));
        Result := False;
        Exit;
      end;
...

liegt es hier
hr := search.ExecuteSearch(StringToOleStr('(objectCategory=' + Category + ')'), @Properties[0], dwCount, ptrResult); nun daran, das ein dynamisches Array ist, oder aber ein PWideChar?

[Klaus01]

.. ist es nicht so,
dass bei einem statischen Array @Array[0] die Adresse des
ersten Elementes liefert.

Ein dynamisches Array wird aber schon durch seine Adresse
repräsentiert.

Sollte es dann nicht reichen, es so zu übergeben?
hr := search.ExecuteSearch(StringToOleStr('(objectCategory=' + Category + ')'), Properties, dwCount, ptrResult); Grüße
Klaus

[oki]

Nun ja,

mir ist nicht alles klar was du gepostet hast. Das liegt aber wohl eher daran, dass ich mit diesem Konstrukt noch nicht gearbeitet habe.

Grundsätzlich bin ich aber der Meinung, dass du einen Zeiger auf WideChars übergeben musst. Imho gestaltet sich das bei dynamischen Arrays so:
  Propertes[0] Bei statischen so:
  @Propertys[0] Ich glaube mich duster daran erinnern zu können, dass dynamische Arrays Zeiger beinhalten. Irgentwie bin ich mir jetzt aber auch nicht mehr sicher.

Ein Array of WideChar sollte aber wie in deinem Fall nur 256 WideChar-Zeichen enthalten. Somit zeigt imho Properties[1] nicht auf den zweiten Namen, sondern auf das zweite Zeichen.

Das sollte aber alles in Bezug auf den Aufruf egal sein. Entscheidend ist, dass ein Zeiger auf WideChars übergeben wird. Das sollte in deinem Fall mit @Properties[0] korrekt sein.

Wieviele Namen übergibst du denn? Vielleicht fehlt die #0 hinter jedem Namen wenn es mehrere sind oder die Länge stimmt nicht? Ich denke mal, es klappt bei ADsGetLastError, weil szName lokal als Variable definiert ist und die Funktion szName füllt.
Ist denn der Rückgabewert von szName dein Properties?

Was steht denn in Properties drin? Vielleicht kämpfst du ja auch mit zwei Problemen,
1. Richtige Übergabe des Parameters,
2. fehlerhafter Eintrag im Parameter.

Was steht bei dir in dwNumberAttributes für ein Wert? Passt der zur Anzahl der Atribute? Nicht dass hier versehentlich die Anzahl der Zeichen übergeben wird?

Gruß oki

[Alter Mann]

Hi @oki

Wenn ich dieses Problem hätte, wäre es keins.

Der Compiler bleibt an der Stelle @Properties[0] stehen und mault rum:
'Die tatsächlichen und formalen Parameter stimmen nicht überein'.

Das mit den 'Array[0..255] of WideChar' war nur ein Gedankengang, da diese Stelle klaglos
durchgeht.

OK?

[oki]

Ja klar,

der Punkt ist aber, dass Delphi 2009 nicht damit klar kommt, dass ein PWideChar erwartet wird und du den @-Operator verwendest. Somit sehe ich das so, dass du hier wohl zwingend den Typ benutzen musst der angegeben ist. Warum das bei deinem letzten Beispiel klappt ignoriere ich jetzt mal geflissentlich .

Ich sehe da auf dieses Problem bezogen zwei Wege.
1. Ein Type-Caste
2. Verwendung einer lokalen Variable

Der Type-Caste scheint ja nicht zu funzen. Die Verwendung einer lokalen Variable führt zu einer Exception. Damit kommt aber der Compiler klar. Also muss was mit dem Inhalt nicht stimmen. Entweder das einfache Casten auf PWideChar liefert Müll oder der Inhalt ist von Vornherein Müll (oder die Anzahl der Elemente passt nicht oder ...).

Deshalb meine Frage, was in Properties denn drin steht.

Leg doch mal eine lokale Variable wie in deinem letzten Beispiel an und kopiere die Properties dort rein.

Delphi-Quellcode:

var szPropertys : Array [0..255] of WideChar;

...
  szProperties := Properties;
  hr := search.ExecuteSearch(StringToOleStr('(objectCategory=' + Category + ')'), @szProperties[0], dwCount, ptrResult);

Wie gesagt, da mein Beispiel mit PWideChar als lokale Variable vom Compiler geschluckt wurde kann die nachfolgende Exzeption auch daran liegen, dass der Inhalt von Properties danach nicht wirklich übergeben wurde.

Was ist eigentlich, wenn du deinen Funktionskopf so veränderst, dass Properties als var-Parameter oder gleich als PWideChar übergeben wird?

Gruß Oki