Zwischenablage Zugriff verweigert

[haentschman]

Hallöle...8-)

Zitat:

Zwischenablage Zugriff verweigert kann nicht geöffnet werden.

...der Fehler kommt in diesem Falle aus einer Fremdkomponente. (DevExpress) Das das ein Windowsproblen ist, ist bekannt. :?
https://www.delphipraxis.net/164785-...-gesperrt.html

Mein MadExcept schließt immer die komplette Anwendung...:? Welche Möglichkeiten gibt es das anders abzufangen...:gruebel:

PS: In meinen Anwendungen habe ich immer eine Schleife mit Abbruchbedingung um den Except Block...wie kriege ich das mit der Fremdkomponente hin? :gruebel: (ich weigere mich eigentlich bei DevExpress Workarounds einzuarbeiten...mit jeder neuen Version wieder von vorn. :roll:) Oder direkt im Vcl.Clipboard?

Delphi-Quellcode:

procedure TcxCustomTextEdit.PasteFromClipboard;
var
  ANewSelStart: Integer;
  ANewText, S: string;
begin
  if Clipboard.HasFormat(CF_TEXT) then
    if Focused then
    begin
      BeginUserAction;
      try
        S := Clipboard.AsText;
        if CanChangeSelText(S, ANewText, ANewSelStart) then
          InnerEdit.CallDefWndProc(WM_PASTE, 0, 0);
      finally
        EndUserAction;
      end;
    end
    else
      SelText := Clipboard.AsText;
end;
...
procedure TClipboard.Open;
begin
  if FOpenRefCount = 0 then
  begin
    FClipboardWindow := Application.Handle;
    if FClipboardWindow = 0 then
    begin
      FClipboardWindow := AllocateHWnd(MainWndProc);
      FAllocated := True;
    end;
    if not OpenClipboard(FClipboardWindow) then
      raise EClipboardException.CreateResFmt({$IFNDEF CLR}@{$ENDIF}SCannotOpenClipboard, // <---
        [SysErrorMessage(GetLastError)]);
    FEmptied := False;
  end;
  Inc(FOpenRefCount);
end;

Was würdet ihr empfehlen? :wink:

[Sinspin]

Warum schließt MadExcept deine ganze Anwendung? Per Einstellung?
Dann solltest du sehen was das für eine Exception class ist und dafür sorgen dass die von MadExcept anders behandelt wird.

[haentschman]

:P

Die Idee ist schon mal umgesetzt...(Bild)

...das löst aber leider nicht das grundsätzliche Problem. :(

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1510176)

ich weigere mich eigentlich bei DevExpress Workarounds einzuarbeiten...mit jeder neuen Version wieder von vorn.

- Die DevExpress-Sourcen in ein Git-Repo.
- Einen eigenen Branch mit deinen Anpassungen aufmachen.
- Bei neuen Versionen diese in Main nachpflegen.
- Main in deinen Branch mergen.

[haentschman]

:P

Zitat:

Die DevExpress-Sourcen in ein Git-Repo.

...habe ich ja schon. ...mache ich schon. :zwinker: Das Problem ist aber auch, daß mit jeder neuen Version auch die Workarounds fehlerhaft sein können...hatte ich schon mal. :(

Ich fange mit jeder Version wieder an zu testen. :kotz:

Aktuell wird das Grid komplett schwarz wenn ApplicationProcessMessages aufgerufen wird. (nicht fragen :?, Control/Form.Repaint in allen Varianten funktioniert trotz Aufruf teilweise nicht nicht. Die Labels und die Progressbar einer "StatusForm" (TForm) sind manchmal eingefroren)

@Uwe:
Du hast doch einen heißen Draht zu Emba. Vieleicht können sie die Schleife in TClipboard.Open einbauen. :zwinker:

Vorschlag zum Optimieren: :wink:

Delphi-Quellcode:

procedure TClipboard.Open;
var
  OpenCount: Integer;
  OpenResult: LongBool;
begin
  OpenCount := 0;
  OpenResult := False;

  if FOpenRefCount = 0 then
  begin
    FClipboardWindow := Application.Handle;
    if FClipboardWindow = 0 then
    begin
      FClipboardWindow := AllocateHWnd(MainWndProc);
      FAllocated := True;
    end;

    repeat
      Inc(OpenCount);
      OpenResult := OpenClipboard(FClipboardWindow);
      if not OpenResult then
      begin
        Sleep(30);
      end;
    until OpenResult or (OpenCount > 50);
    if not OpenResult then
    begin
       raise EClipboardException.CreateResFmt({$IFNDEF CLR}@{$ENDIF}SCannotOpenClipboard,
          [SysErrorMessage(GetLastError)]);
    end;

    FEmptied := False;
  end;
  Inc(FOpenRefCount);
end;

[Sinspin]

Zitat:

Zitat von haentschman (Beitrag 1510184)

Aktuell wird das Grid komplett schwarz wenn ApplicationProcessMessages aufgerufen wird.

Ist bei mir auch so. Ich habe es aufgegeben nach einer Lösung zu suchen.
Laut DevExpress ist aktuell jemand dabei, sich der ganzen Fehler in den VCL Komponenten anzunehmen. Vermutlich sitzt der jemand gerade in einem Schützengraben, denn ich sehe keine Verbesserungen.

Ich habe auch ein Problem mit meinem Pluginsystem. Ich habe diverse Dll's mit Dialogen die auch Grids enthalten. Klappt soweit wunderbar...bis ich das Form mit dem Grid im Hauptform einbette. Alle Komponenten funktionieren wie immer, nur in Grids bekommt man keinen sichtbaren Focus mehr auf Records.
DevExpress stellt bei den Grids irgendwas mit der WindowProc an was es nicht überlebt wenn sich durch das einbetten das WindowHandle, etc ändert.

[haentschman]

[Luft ablassen ON]

Zitat:

Ist bei mir auch so. Ich habe es aufgegeben nach einer Lösung zu suchen.

:evil: Das kostet immer wieder Zeit...

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1510184)

Vieleicht können sie die Schleife in TClipboard.Open einbauen.

Das wird aus Kompatibilitätsgründen wohl nicht passieren. Ich könnte mir eher eine Lösung dieser Art vorstellen (später mal direkt in TClipboard):

Delphi-Quellcode:

type
  TClipboardHelper = class helper for TClipboard
    function TryOpen(MaxTries: Integer = 50; Delay: Integer = 20): Boolean;
  end;

function TClipboardHelper.TryOpen(MaxTries: Integer = 50; Delay: Integer = 20): Boolean;
begin
  var cnt := 0;
  while True do begin
    try
      Open;
      Exit(True);
    except
      on EClipboardException do begin
        Inc(cnt);
        if cnt < MaxTries then
          Sleep(Delay)
        else
          Exit(False);
      end;
    end;
  end;
end;

Das erfordert aber eine Anpassung aller Open-Aufrufe.

[haentschman]

...ich habe das mal im TcxCustomTextEdit.PasteFromClipboard integriert :wink:

Delphi-Quellcode:

procedure TcxCustomTextEdit.PasteFromClipboard;
var
  ANewSelStart: Integer;
  ANewText, S: string;

  function GetClipboardText: string;
  var
    RetryCount: Integer;
    Success: Boolean;
  begin
    RetryCount := 0;
    Success := False;
    while not Success do
    begin
      try
        Result := Clipboard.AsText;
        Success := True;
      except
        on EClipboardException do
        begin
          Inc(RetryCount);
          if RetryCount < 50 then
          begin
            Sleep(20)
          end
          else
          begin
            raise Exception.Create('Cannot read clipboard after fifty attempts');
            // Exit(''); // Alternativ statt raise
          end;
        end
        else
          raise;
      end;
    end;
  end;

begin
  if Clipboard.HasFormat(CF_TEXT) then
  begin
    if Focused then
    begin
      BeginUserAction;
      try
        S := GetClipboardText;
        if CanChangeSelText(S, ANewText, ANewSelStart) then
          InnerEdit.CallDefWndProc(WM_PASTE, 0, 0);
      finally
        EndUserAction;
      end;
    end
    else
      SelText := GetClipboardText;
  end;
end;

[Uwe Raabe]

Man sollte eigentlich nie eine simple

Delphi-Quellcode:

Exception

werfen, da man damit dem Aufrufer die Möglichkeit nimmt, selektiv auf diese zu reagieren. Besser wäre hier wieder eine

Delphi-Quellcode:

EClipboardException

oder ein schlichtes

Delphi-Quellcode:

raise;

[Sinspin]

Gerade in dem Fall das bereits eine Exception ausgelößt worden ist, ist

Delphi-Quellcode:

raise;

wirklich am besten.
Du würdest sonst ja die anderen Exception Informationen verbergen.

[himitsu]

In diesem Fall ist es ja einfach, denn es gibt bereits eine "andere" Exception-Klasse.

Delphi-Quellcode:

else
begin
  raise EClipboardException.Create('Cannot read clipboard after fifty attempts');

Aber es ist ebenfalls extrem unschön, wenn man die eigentliche Exception sinnlos vernichtet.

Delphi-Quellcode:

else
begin
  raise EClipboardException.Create('Cannot read clipboard after fifty attempts'#10#10 + E.Message);

Delphi-Quellcode:

// hier bleibt im nächsten E.InnerException die ursprüngliche Exception erhalten
else
begin
  Exception.RaiseOuterException(EClipboardException.Create('Cannot read clipboard after fifty attempts');

Schade ist nur, dass hauseigenen im ShowException von Delphi so Eingies einfach grob fahrlässig vergessen wurde,
aber zumindestens innerhalb des Programms kommt man dennoch an InnerException ran.

[haentschman]

Boah-ey...8-)

...ihr findet immer ein Haar in der Suppe. :stupid: :zwinker:

Besser so?

Delphi-Quellcode:

except
  on E: EClipboardException do
  begin
    Inc(RetryCount);
    if RetryCount < 50 then
    begin
      Sleep(20)
    end
    else
    begin
      raise EClipboardException.Create('Cannot read clipboard after fifty attempts.' + sLineBreak + 'Originalmessage: (' +  E.Message + ')');
      // Exit(''); // Alternativ statt raise
    end;
  end
  else
    raise;
end;

:wink:

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1510228)

...ihr findet immer ein Haar in der Suppe.

Das

Delphi-Quellcode:

else raise

ist überflüssig, da alle nicht durch

Delphi-Quellcode:

on

abgefragten Exceptions automatisch durchgeleitet werden 8-)

[haentschman]

Zitat:

da alle nicht durch on abgefragten Exceptions automatisch durchgeleitet werden

...ist das neu? :gruebel: Ich habe "gelernt", soweit das möglich ist, daß im Exception Block die Exception nicht weitergeleitet wird. Warum machen dann manche leere Exception Blöcke? ...um die Exception zu blocken. :gruebel:

[Delphi.Narium]

Nein, das ist nicht neu, in Delphi 7 ist das Verhalten auch so.

Delphi-Quellcode:

Try
  i := 0;
  k := 1;
  x := k / i;
except
  on EZeroDivide do begin
    MessageDLG('Wer teilt denn hier durch 0?',mtError,[mbOk],0);
  end;
  on EMathError do begin
    MessageDLG('Irgendein mathematischer Fehler!' + sLinebreak + e.Message,mtError,[mbOk],0);
  end;
  // ... weitere on EIrgendwas-Blöcke
  // Wenn das vorhanden, landen hier alle übrigen Fehler.
  on e : Exception
    // Das macht man nicht ohne sinnvollen Inhalt, weil dann alle (übrigen) Fehler ignoriert werden.
  end;
end;

Try
  i := 0;
  k := 1;
  x := k / i;
except
  on EZeroDivide do begin
    MessageDLG('Wer teilt denn hier durch 0?',mtError,[mbOk],0);
  end;
  on EMathError do begin
    MessageDLG('Irgendein mathematischer Fehler!' + sLinebreak + e.Message,mtError,[mbOk],0);
  end;
  // ... weitere on EIrgendwas-Blöcke
  on e : Exception
    MessageDLG('Es ist ein (beliebiger) Fehler (außer den davor behandelten) aufgetreten!' + sLinebreak + e.Message,mtError,[mbOk],0);
  end;
end;

Try
  i := 0;
  k := 1;
  x := k / i;
except
  on EZeroDivide do begin
    MessageDLG('Wer teilt denn hier durch 0?',mtError,[mbOk],0);
  end;
  on EMathError do begin
    MessageDLG('Irgendein mathematischer Fehler!' + sLinebreak + e.Message,mtError,[mbOk],0);
  end;
  // Alle bis hier nicht "abgearbeiteten Fehler" werden weitergereicht.
  // Das Programmverhalten ist dann so, als gäbe es keine Fehlernbehandlung.
end;

Die übelste Variante ist:

Delphi-Quellcode:

try
  i := 0;
  k := 1;
  x := k / i;
except
end;

Hier wird einfach alles, was so an Fehlern auftreten kann, schlicht und einfach ignoriert.

[Uwe Raabe]

Es ist in der Tat so, dass ein leerer Exception-Block alle Exceptions abfängt. Sobald aber mindestens eine on-Bedingung da steht, werden alle nicht so abgefangenen Exceptions durchgelassen.

[haentschman]

Zitat:

Sobald aber mindestens eine on-Bedingung da steht, werden alle nicht so abgefangenen Exceptions durchgelassen.

...again what learned. (Loddar) :stupid:

[himitsu]

Ist zwar irgendwie nicht ganz verständlich/konsequent,
aber ein ELSE ohne ON IF gibt es eh nicht.

Also mit ON gibt es, falls kein ELSE vorhanden, ein implizites

Delphi-Quellcode:

else raise;

. :shock:





OMG, ein

Delphi-Quellcode:

raise TObject.Create;

würde also durch alle Try-Except durchrauchen, welche ein ON ohne ELSE enthalten, was in der RTL/VCL praktisch fast immer so ist,

mit wenigen Ausnahmen, weswegen aus einem TButton-Click doch nicht die ganze Anwendung komplett verreckt.

Delphi-Quellcode:

procedure TWinControl.MainWndProc(var Message: TMessage);
begin
  try
    ...
  except
    Application.HandleException(Self);
  end;

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1510247)

OMG, ein

Delphi-Quellcode:

raise TObject.Create;

würde also durch alle Try-Except durchrauchen, welche ein ON ohne ELSE enthalten

Das würde ein

Delphi-Quellcode:

raise EProgrammmerNotFound.Create('Hurz')

aber vermutlich auch. Aber vielleicht hat ja einer ein

Delphi-Quellcode:

on E: TObject do

da stehen.

[himitsu]

EProgrammerNotFound und ENotImplemented normal nicht, da sie eine "Exception" sind und nicht vor EAbort erben, werden sie behandelt und auch angezeigt.
(nutze ich gern für Marker "nicht eingebaut, weil war bisher nicht nötig" und "nicht eingebaut, weil hatte noch niemnand Lust/Zeit")



Per se ist in Pascal/Delphi die Exception-Behandlung so ausgelegt, dass "Exceptions" nicht von Exception erben müssen,
auch wenn es blöd ist, da die Standard-ExceptionBenahndlung in SysUtils und Co. mindestens "Exception" verlangt, z.B. die beiden ShowExceptions und da bei ON normal überall eigentlich immer mindestens Exception-Typen angegeben werden.

ABER, kommt die Exception z.B. aus eine DLL (ohne Laufzeitpackages), dann hat die DLL andere Exception-Classes, als wie die EXE. ... die beiden Seiten sind nicht nur nicht vom selben "Exception" geerbt ... nichtmal vom selben TObject. :stupid:

[haentschman]

Moin...8-)

...inzwischen hatte ich 2 Arbeitsstationen mit:

Zitat:

Cannot read clipboard after fifty attempts.

...nichtmal mehrmaliges Öffnen bringt das. :?

Clipboard.AsText macht intern ein Open/Close...:roll:

Was kann ich sonst machen? :gruebel:

Statt dem raise ein Exit bringt mir keinen Fehler, aber auch kein Paste...:roll:

[Rollo62]

Vielleicht lohnt es mal zu schauen wo die Unterschiede VCL zu FMX sind:

FMX:

Delphi-Quellcode:

function TWindowsClipboardService.GetText: string;
var
  Data: THandle;
  TextData: string;
begin
  Result := string.Empty;
  OpenClipboard(0);
  try
    Data := GetClipboardData(CF_UNICODETEXT);
    if Data <> 0 then
    begin
      TextData := PChar(GlobalLock(Data));
      try
        Result := TextData;
      finally
        GlobalUnlock(Data);
      end;
    end;
  finally
    CloseClipboard;
  end;
end;

VCL:

Delphi-Quellcode:

procedure TClipboard.Open;
begin
  if FOpenRefCount = 0 then
  begin
    FClipboardWindow := Application.Handle;
    if FClipboardWindow = 0 then
    begin
      FClipboardWindow := AllocateHWnd(MainWndProc);
      FAllocated := True;
    end;
    if not OpenClipboard(FClipboardWindow) then
      raise EClipboardException.CreateResFmt({$IFNDEF CLR}@{$ENDIF}SCannotOpenClipboard,
        [SysErrorMessage(GetLastError)]);
    FEmptied := False;
  end;
  Inc(FOpenRefCount);
end;

function TClipboard.GetAsText: string;
var
  Data: THandle;
begin
  Open;
  Data := GetClipboardData(CTextFormat);
  try
    if Data <> 0 then
{$IF DEFINED(CLR)}
      Result := Marshal.PtrToStringUni(GlobalLock(Data))
{$ELSE}
      Result := PChar(GlobalLock(Data))
{$ENDIF}
    else
      Result := '';
  finally
    if Data <> 0 then
      GlobalUnlock(Data);
    Close;
  end;
end;

Mir fällt da auf das FMX einfach immer mit Handle OpenClipboard(0), während VCL ein Handle übergibt OpenClipboard(FClipboardWindow);
Könnte das einen Unterschied bei den Exceptions machen ?

[haentschman]

Danke...:P

...ich schau mir das an.