Übersetzung Class MagneticWindow

**Elvis**

Zitat von Muetze1:

Zitat von EWeiss:

Alle oben aufgeführte funktionen selbst die Winproc existieren nicht als code in der Classe sondern als MaschinenCode im speicher.
Lediglich die Messagen werden im Code verwaltet.

Wozu brauchst du dies? Wozu legst du Maschinencode hier in diesem Array ab und patcht die Instanzenadressen. Die Messagebehandlung und überschreiben der WndProc geht bei Delphi mit einfachsten OOP Mitteln, da brauchen wir sowas nicht.

Weshalb ich ihm empfahl sich erst mit der Sprache vertraut zu machen, bevor er ein VB Projekt portiert.

Zitat:

Ich möchte daher im ganz allgemeinen Worten wissen, was der Code bewirken soll. Was er macht und wie und wo er irgendwelche Daten hin- und herschreibt, das sehe ich am VB Code. Die Frage ist, wozu du den Code brauchst. Warum ist es nötig gewesen diesen Code bei deinem VB Programm einzufügen?

Weil er ihn vllt. von irgendwo kopiert hat?
Oder weil die Pastamaschine VB tatsächlich solchen Krempel benötigt um irgendetwas hinzukriegen, das komplexer als eine Hello-world-MsgBox hinter einem ButtonClick ist?
Keine Ahnung ich sehe da nur kryptische Hieroglyphen und da vergeht mir ganz schnell die Lust weiter zu lesen, bin hier ganz xaromz' Meinung.

Zitat von Muetze1:

Zitat von EWeiss:

Alle oben aufgeführte funktionen selbst die Winproc existieren nicht als code
in der Classe sondern als MaschinenCode im speicher.
Lediglich die Messagen werden im Code verwaltet.

Wozu brauchst du dies? Wozu legst du Maschinencode hier in diesem Array ab und patcht die Instanzenadressen. Die Messagebehandlung und überschreiben der WndProc geht bei Delphi mit einfachsten OOP Mitteln, da brauchen wir sowas nicht. Ich möchte daher im ganz allgemeinen Worten wissen, was der Code bewirken soll. Was er macht und wie und wo er irgendwelche Daten hin- und herschreibt, das sehe ich am VB Code. Die Frage ist, wozu du den Code brauchst. Warum ist es nötig gewesen diesen Code bei deinem VB Programm einzufügen?

Weil es in Vb mit Konventionellen mitteln in der IDE nicht möglich ist sein
Programm zu debuggen wenn sich eine solche Funktion 'Subclass' im Code befindet.
Deshalb der umweg über Maschinensprache damit man weiterhin an seinen Programm innerhalb
der IDE arbeiten kann... ohne sich mit abstürzen rumplagen zu müssen.

Er emuliert das Subclasing(Address of @WinProc) im Speicher das einzigste
was im Code ausgeführt wird ist die überprüfugn der Messagen.
Deshalb kommt es auch nicht mehr zu Abstürzen.

Delphi braucht das nicht da die Winproc in der IDE während des Programmierens
Debuggen nicht zum Absturz von Delphi führt.

gruß

Zitat:

Weil er ihn vllt. von irgendwo kopiert hat?
Oder weil die Pastamaschine VB tatsächlich solchen Krempel benötigt um irgendetwas hinzukriegen, das komplexer als eine Hello-world-MsgBox hinter einem ButtonClick ist?
Keine Ahnung ich sehe da nur kryptische Hieroglyphen und da vergeht mir ganz schnell die Lust weiter zu lesen, bin hier ganz xaromz' Meinung.

Klar habe ich den MaschinenCode String kopiert!
Woher soll er denn sonst kommen

Du machst nur unterstellungen..
Lästerst über etwas wovon du nichts verstehst.
Hast noch nichts kreatives zum Thema beigetragen.

Deshalb PLONK.!
Keine weiteren Kommentare.

gruß

Zitat von EWeiss:

Delphi braucht das nicht da die Winproc in der IDE während des Programmierens
Debuggen nicht zum Absturz von Delphi führt.

Ok, mit anderen Worten: Delphi braucht es nicht, es muss nicht portiert werden und es funktioniert mit den Delphi Hausmitteln. Ok, dann sollte sich das Problem somit in Luft aufgelöst haben.

Zitat von Muetze1:

Zitat von EWeiss:

Delphi braucht das nicht da die Winproc in der IDE während des Programmierens
Debuggen nicht zum Absturz von Delphi führt.

Ok, mit anderen Worten: Delphi braucht es nicht, es muss nicht portiert werden und es funktioniert mit den Delphi Hausmitteln. Ok, dann sollte sich das Problem somit in Luft aufgelöst haben.

Diese Hinterfragungen waren doch nur auf dieses Ergebnis deinerseits aus oder ?

Habe das Projekt jemanden geschickt der beide Sprachen beherrscht.
Denke das sich ein weg finden wird es trotzdem auf die art weiterzuführen.

Auch Delphi arbeitet schneller mit MachinenCode als mit seiner Scriptsprache
welche vom compiler auch erst mal in Mc übersetzt werden muss.

Warum sonst verwendet Borland ASM innerhalb seiner bereitgestellten Units.

Trotzdem Danke für deine Hilfe.

Gruß

Zitat von EWeiss:

Diese Hinterfragungen waren doch nur auf dieses Ergebnis deinerseits aus oder ?

Ja

Zitat von EWeiss:

Denke das sich ein weg finden wird es trotzdem auf die art weiterzuführen.

Wie haben gerade festgestellt, dass es nicht mehr nötig ist.

Zitat von EWeiss:

Auch Delphi arbeitet schneller mit MachinenCode als mit seiner Scriptsprache

Delphi ist keine Interpretersprache. Alles wird in Maschinensprache übersetzt vor der Ausführung. Es wird kein "Script" mehr interpretiert zur Laufzeit (so lange du es nicht explizit mit der .NET Technik machst).

Zitat von EWeiss:

welche vom compiler auch erst mal in Mc übersetzt werden muss.

Dies geschieht vor der Ausführung deines Programmes - da ist dies schon alles erledigt. Wenn dein Programm startet, dann liegt es nur noch in Maschinencode vor.

Zitat von EWeiss:

Warum sonst verwendet Borland ASM innerhalb seiner bereitgestellten Units.

Weil es an manchen Stellen Vorteile bringt - ABER: Borland weiss um die Umgebung und wie die Internas aufgebaut ist.

**sailxia**

in delphi, SXMagnet is a very goog VCL component about MagneticWindow like winamp. but it's a share-ware.(

http://www.spoonworx.com/Main.htm)

in VB, cMagneticWnd is very good class about MagneticWindow like winamp. and it's open source.

Muss trotzdem noch was loswerden.
An die welche etwas mehr von Delphi verstehen wie meinereins.

Warum funktioniert denn nun der VBHack nicht unter Delphi ?
Ich weiss es

Ihr auch ?

Es wurde mir mit einen Super Beispiel dokumentiert.
Schaut es euch selber an!

VarPtrObjPtrInDelphi

Könnt selbst ihr noch etwas von lernen.
So hätte ich mir die Hilfe hier gern gewünscht.

Will aber nicht undankbar sein!
War schon in Ordnung so ..

gruß

**xaromz**

Hallo,

Zitat von EWeiss:

Könnt selbst ihr noch etwas von lernen.

Ich habe mir den Link mal angesehen.
So ganz hab' ich aber immer noch nicht verstanden, wozu ich das brauchen soll. VarPtr gibt also die Adresse einer Variablen zurück, also Addr() bzw @ in Delphi. Aber was ObjPtr soll, hab ich in meiner abendlichen Bierseligkeit nicht begriffen. Kann mich da jemand aufklären?

Gruß
xaromz

Zitat von xaromz:

Hallo,

Zitat von EWeiss:

Könnt selbst ihr noch etwas von lernen.

Ich habe mir den Link mal angesehen.
So ganz hab' ich aber immer noch nicht verstanden, wozu ich das brauchen soll. VarPtr gibt also die Adresse einer Variablen zurück, also Addr() bzw @ in Delphi. Aber was ObjPtr soll, hab ich in meiner abendlichen Bierseligkeit nicht begriffen. Kann mich da jemand aufklären?

Gruß
xaromz

Es hat niemand gesagt das du es brauchen sollst!
Sondern in dem Beispiel wird am Objekt(Sample) erklärt das auch
mit Pointern unter VB gearbeitet werden kann.

Zitat:

Dieses Tutorial soll klären wie man mit Hilfe der Funktionen VarPtr und ObjPtr aus VB6
die gleiche Funktionalität bekommt wie in anderen Programmiersprachen,
hier am Beispiel von Delphi.

Auszug aus meiner Mail!

Zitat:

Deine Frage war:
Wie man das in VB gebräuchliche ObjPtr(Me) nach Delphi übersetzt.
dabei hast du es eigentlich schon fast richtig gemacht
"Me" ist in Delphi einfach "Self"

Das Object ist die Instanz deiner Klasse, Quasi 'Self'
Obj ist deine Klasse 'Self' + ptr wäre quasi '@' ergebnis müßte dieses sein '@Self'

Warum die übersetzung von der Classe nicht funktioniert ist diese.

die Private Variable mValue im Delphi Beispiel ist 4 Bytes über dem Objekt
die Private Variable mValue im VBasic Beispiel ist 52Bytes über dem Objekt
damit wird klar, daß die Objekte in VB und Delphi unterschiedlich aufgebaut
sind.

Der VisualBasic-Hack ist also nur für VB zu gebrauchen.

Ich muss diesen nur weglassen lenke um auf eine Standard
WinProc und schon läuft die Classe.

Gruß