C++ Code in Delphi

[xZise]

Hallo DP,
ich habe mal ein paar Fragen zu C++. Bzw. wessen sie in Delphi entsprächen:

• Klasse CMenu => TMenu?
• Klasse CPoint => Wahrscheinlich TPoint?
• IShellFolder
• LPITEMIDLIST
• CString => Wahrscheinlich "string"?
• CStringArray => TStringList?
• UINT => Cardinal wurde mir gesagt...
• CWnd => Handle? (Also Cardinal)
• LPCONTEXTMENU
• LPCITEMIDLIST
• REFIID
• LPBYTE => Wahrscheinlich Byte
• HRESULT

Und was bedeutet folgends:

Code:

BOOL GetContextMenu (void ** ppContextMenu, int & iMenuType);

Also Was soll ppContextMenu sein? Pointer?

Code:

LRESULT CALLBACK HookWndProc (HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);

Und das ist die Messageschleife oder?
Wenn ich das aber als Klasse eines Fensters programmiere, benötige ist denn die Messageschleife?

MfG
xZise

[Apollonius]

ppContextmenu muss in Delphi PPointer sein und iMenuType var integer.
Die Funktion ist nicht die Messageschleige sondern die Nachrichtenfunktion. Das ist ein Unterschied. Ob du die in Delphi brauchst, lässt sich ohne Code schlecht sagen.
Zu den Typen kann man sagen, das LP in Delphi am normalerweise nur mit p übersetzt wird. UInt ist kurz für unsigned int, also wirklich Cardinal. Zu den Klassen lässt sich schlecht sagen, ob es direkte Delphi-Äquivalente gibt.

[xZise]

Naja, es geht um das Kontextmenü des Explorers. Ich habe letzte Woche, ein C++ Code gefunden, welcher diese Funktionalität hat, und ich wollte den eigentlich in Delphi übersetzen.

DP-Thread

MfG
xZise

[Der_Unwissende]

Hi,
Du musst etwas aufpassen, sobald Du C++ Code hast, der wirklich Klassen verlangt hast Du mit Delphi ein Problem. Selbst wenn Delphi Dir eine Klasse zur Verfügung stellt, die die gleichen Felder und Methoden bereitstellt, so kannst Du die keineswegs einfach an ein C++-Programm übergeben. Das klappt (afaik) nicht mal ohne Probleme, wenn Du unterschiedliche C++-Compiler verwendet hast.

Beim Kontextmenü des Explorers wird deshalb (wie so ziemlich überall bei den Windows-Schnittstellen) sicherlich nicht C++ sondern C verwendet. Natürlich kannst Du unter C++ sehr leicht verbergen, welche Stellen jetzt reines C und der API geschuldet sind, denn auch das ist gültiger C++ Code, aber die Jungs von MS haben natürlich schon ganz gut mitgedacht! Anders als C++ ist bei C alles sehr einfach (darin liegen sowohl die Stärken, als auch die Schwächen der Sprache). C kennt eben keine Indirektion, verwendet einfache Strukturen und auch Felder sind nur ein großer Speicherblock in dem alle Daten am Stück hintereinander liegen. Das ist nicht kompliziert, also kann auch fast jede Sprache auf diese Art und Weise Daten erzeugen bzw. auf diese zugreifen. Einige Sprachen tun das in Form einer speziellen Schnittstelle (z.B. Haskell mit dem FFI, Java über JNI), andere untersützen das sehr viel direkter (C++).
In Delphi gibt es eigentlich zwei Möglichkeiten:
a) Es gibt schon eine VCL - Kapselung, brauche ich denke ich nicht näher erläutern
b) Man greift auf eine DLL zu. DLLs liegen in einem bekannten Format vor, dass unabhängig von der Programmiersprache ist (und eben auch aus allen genutzt werden kann). In Delphi gibt es dazu dann halt die external Direktive.

Ja, lange Rede, kurzer Sinn. Willst Du ein Windows Mittel nutzen, ist es eigentlich immer C. C kennt keine Klassen, nur Strukturen (und die können leicht in ein Record überführt werden). Die Windowsfunktionen sind zudem häufig schon gekapselt (also die Signatur gibt es schon und Du musst nur die richtige Unit einbinden, die wiederum fast immer wie die Header Datei heißt).

Gruß Der Unwissende

[xZise]

Zitat von Der_Unwissende:

[...]
a) Es gibt schon eine VCL - Kapselung, brauche ich denke ich nicht näher erläutern
[...]

Was meinst du damit? Sozusagen eine TShellContextMenu Klasse?

MfG
xZise

[wicht]

Suchst du sowas?

[xZise]

hmm tatsächlich...

Danke

MfG
xZise

[OldGrumpy]

Zitat von xZise:

Hallo DP,
ich habe mal ein paar Fragen zu C++. Bzw. wessen sie in Delphi entsprächen:

• CString => Wahrscheinlich "string"?
• CStringArray => TStringList?
• CWnd => Handle? (Also Cardinal)
• LPCONTEXTMENU
• LPCITEMIDLIST
• REFIID
• LPBYTE => Wahrscheinlich Byte
• HRESULT

[...]
MfG
xZise

Einiges davon sind MFC-Klassen (MFC ist in etwa das was die VCL bei Borland ist) die keine direkte Entsprechung haben.

CString ist eine recht umfangreiche Stringklasse, mit fast allem was man so an Stringmanipulationen und -operationen brauchen kann. Einen Teil der Features gibts als Stringfunktionen ohne Klasse in Delphi, den Rest muss man sich dazuprogrammieren, je nachdem was da in deinem Beispielsource so verwendet wird.

CWnd ist die Kapselungsklasse für alles Fensterhandling. Grobe Entsprechung wäre wohl noch TForm (wobei die beiden natürlich durchaus Unterschiede in Einsatzzweck und Fähigkeiten haben), wie das zu übersetzen ist, hängt vollständig davon ab, was da genau wie implementiert wird.

LPCONTEXTMENU ist ein Pointer auf eine Struktur namens CONTEXTMENU, deren Beschreibung müsste in der MSDN zu finden sein, dito für LPCITEMIDLIST und REFIID.

LPBYTE ist ein Byte-Pointer (PByte).

HRESULT ist je nach Context unterschiedlich zu behandeln, kommt auf den Code an. Vom Datentyp her ists ein Cardinal, in dem allerdings jedes Bit eine festgelegte Bedeutung hat. Daher auch die manchmal seltsamen Rückgabewerte. Details findet man in der MSDN library.

[xZise]

Zitat von xZise:

hmm tatsächlich...

Danke

MfG
xZise

Hmmm kann es sein, dass es sich eher um einen Kontextmenüeintrag als um ein Kontextmenü handelt?

Ich würde nämlich sehr gerne, dass ich rechts auf eine Datei klicke (in MEINEM Browser), und dann das Kontextmenü erscheint.

MfG
xZise