Übersetzung Class MagneticWindow

[Muetze1]

Zitat:

Zitat von EWeiss

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

Ich kann kein VB und werde mich nie mit beschäftigen. Und um hier Delphi spezifische Hilfe anzubieten, werde ich keine VB Spezialitäten lernen. Und wenn du dir die Hilfe hier so wünscht, dann bringe sie bei denjenigen an, die in Zukunft eine solche VB/Delphi Frage haben. Dafür kann ich dann hier mit Delphi, Assembler (auf mehreren Systemen), Matlab/Simulink und anderen Dingen helfen.

Zitat:

Zitat von xaromz

Aber was ObjPtr soll, hab ich in meiner abendlichen Bierseligkeit nicht begriffen.

Das sind die normalen Instanzen in Delphi. In Delphi sind die normalen Instanzenvariablen Zeiger, somit könnte man auch Objektpointer dazu sagen.

Zitat:

Zitat von EWeiss

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

Falsch. Wie eben geschrieben sind Instanzenvariablen und sonstige Instanzenablagen Zeiger, somit ist Self schon ein Zeiger auf die eigentliche Instanz im Speicher. Somit wäre es nicht @Self sondern Self.

Zitat:

Zitat von EWeiss

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.

Das ist grundsätzlich so, da es zwar gewissen OOP Aufbau Standards gibt von den Internas her, aber trotzdem jeder Hersteller die OOP Funktionalität in den Objekten bzw. besser gesagt im Maschinencode anders implementiert. Und das genau darum dieser Hack zwar rein befehlstechnisch portierbar ist, aber trotzdem unnütz und nicht machbar in Delphi, habe ich die zig Posts zuvor schon oft genug zum Ausdruck gebracht.

Zitat:

Zitat von EWeiss

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

Das sagt der Satz schon aus, ohne seinen Inhalt verstehen zu müssen. Das wäre genauso als wenn ich sagen würde: "Ein Apfelstiel gehört zu einem Apfel." ...

Zitat:

Zitat von EWeiss

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

Klasse. Erinnert mich an meine alten Posts in diesem Thread...

Ok, genug den Blutdruck beruhigt...

Gute Nacht!

[EWeiss]

@Muetze1

Hat dich jemand aufgefordert dein Kommentar abzugeben?
Ich habe dich jetzt nicht drum gebeten.

Also immer locker bleiben
Wenn du probs mit deinen Blutdruck hast ist das nicht das richtige Umfeld für dicht.
Das ist nicht böse gemeint, ich denk halt an deine Gesundheit. :-D

Zitat:

Ich kann kein VB und werde mich nie mit beschäftigen.

Kann ich mir denken dazu gehört schon etwas mehr als in eine fertige Windows.pas zu schaun
Da muss man noch arbeiten.

Zitat:

"Ein Apfelstiel gehört zu einem Apfel." ...

Was für ein Zitat im wahrsten sinne.
Als Hochtitulierter, Studierter ? bestimmt! Hätte ich dir etwas mehr zugetraut.

Zitat:

Klasse. Erinnert mich an meine alten Posts in diesem Thread...
habe ich die zig Posts zuvor schon oft genug zum Ausdruck gebracht.

Kann nichts von finden.. hast doch nur drumrum geredet. Halt Studierten-Latein

Na gut habe jetzt wie du siehst jemand anderen gefunden mit einer weniger aufreibenden Ausdrucksweise.

Benötige deine Hilfe für die zukunft auch nicht mehr ;) wenn überhaupt was rüberkam, was halbwegs Hilfreich gewesen wäre.
Ja,ja ich war zu dumm dazu dich zu verstehen.

Aber egal ! So kannst deinen ach so argen Blutdruck schonen.
Für mich ist das Thema abgehakt .. könnt euch jetzt über diese Post noch etwas auslassen.

ABER ! Denkt an euren Blutdruck :lol:

Guen Morgen.

EDIT: @Webmaster.. Sorry aber das mußte mal raus bin nicht auf streit aus .. aber solche Leute nerven !!!!

[alzaimar]

@EWeiss: Stänker hier nicht so rum! Deine Ausführungen lassen darauf schließen, das Du deinem Alter nicht würdig bist. Setzen, sechs! :twisted:
Immerhin pöbelst Du hier rum, beschwerst Dich wegen der ach so unqualifizierten Hilfe und meinst Dann auch, noch, das "selbst" wir "noch was lernen" können. Ich empfinde das als unverschämt. Weiterhin beschwerst Du dich, das Muetze1 einen (fundierten) Kommentar abgibt. Hmmm...
Und dann, NACH den Pöbeleien, sich auch noch scheinheilig beim webmaster zu entschuldigen, ist schon mehr als :oops: peinlich: Entweder Dampf ablassen, oder nicht. Aber erst pöbeln und dann entschuldigen, nee, also...

Dessenungeachtet: So eine MagneticWindow-Klasse ist doch einfach zu implementieren. Wieso machst Du das nicht selbst? Ich habe eine, und wollte Sie Dir zur Verfügung stellen, aber so lasse ich das wohl (Werde es aber bei Gelegenheit an anderer Stelle nachholen). Kleiner Tipp: SharedMemory, ein Masterfenster und im SharedMemory melden sich alle Kindfenster an (mit ihrem Handle sowie den aktuellen Abmessungen). Bewegt sich das Masterfenster, kann es dann einfach alle Kindfenster mitbewegen. "Magnetisch" sind sie auch, denn da sie wissen, wo die anderen Fenster sind, kleben sie ab einem Abstand von <3pxl einfach am Nachbarn. Dann auf die Fenster noch eine Skinengine und fertig.

Krieg dich mal wieder ein und :cheers: auf VB :wall:

Von renomierten Programmierern stammt übrigens die Aussage, das mit VB programmierte Anwendungen per se nicht laufen. Ob das so ist, weiss ich nicht, aber ich weiss, das VB vor allen Dingen in IT-Abteilungen eingesetzt werden, die von Amateuren durchsetzt sind. Insofern hat es auch etwas mit Etikette zu tun, ein VB-Mist *nicht* in Delphi zu übersetzen. Vor allen Dingen diese 'Hacks'. Sowas bescheuertes: Eine Routine, die soetwas implementiert, kommt in den Mülleimer: Wer richtig programmieren kann, braucht so etwas nicht.

[xaromz]

Hallo,

@Muetze: Danke für die Erklärung. Ich hatte den oben verlinkten Code nur überflogen, weil mir gleich schlecht wurde. Bin ich froh, dass der Kelch VB an mir vorüberging :mrgreen: .

@EWeiss: Ich kann mich alzaimar nur anschließen.

Gruß
xaromz

[mschaefer]

Moin, moin zusammen,
etwas tiefer die Bälle bitte, es regnet schon fast..

Hier kommen zwei Programmierichtungen auffeinander wo offentischtlich das gegenseitige Einarbeitungskapital etwas niedrig ausgefallen ist. Da ist ein VB-Programmierer der etwas auf Delphi versucht umsznusetzen. Prima, er hätte ja auch C# nehmen können. Das man mit VB auch Assembler nutzen muß fasziniert mich sogar etwas!

Etwas mehr Toleranz gegenüber dem Delphi-Slang muß da allerdings investiert werden, den die Progracmmierkonzepte unterscheiden sich doch reichlich. Jeder der sich mal mit Office-Automation beschäftigt hat, kommt um VB nicht herum, das sind auch etliche Delphi Entwickler! Das dürfte wohl auch auf der DelphIseite abgehakt sein.

-------------------------------------------------------------------------------------------------------------------------
Das Delphi Vorteile bietet ist offensichtlich also Konsens! Damit kann man arbeiten.
-------------------------------------------------------------------------------------------------------------------------

Zurück in die Zukunft, zum Thema:
-------------------------------------------------------------------------------------------------------------------------
Was macht der Assemblercode? Welche Aufgabe hat das? Welchen Variablenwert ändert das Ding?
-------------------------------------------------------------------------------------------------------------------------
Ohne eine allgemeine Beschreibung ist das nicht in das Objektmodell von Delphi umzusetzen. Welcher Befehl fehlt dem VB, dass man hier auf Assembler umsteigen muß?


Viele Grüße in die Runde // Martin

[Union]

Wieso dafür eigentlich eine eigene Klasse? Um die Funktionlität generell zu ermöglichen, sollte doch so was ausreichen:

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure OnMove(var Msg: TWMMove); message WM_MOVE;
    procedure OnMoving(var Msg: TWMMoving); message WM_MOVING;
  private
    { Private declarations }
    FTopLeft : TPoint;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

uses unit2;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
   TForm2.Create(self).Show;
end;

procedure TForm1.OnMove(var Msg: TWMMove);
var
   i : integer;
begin
   inherited;
   for i := 0 to Screen.FormCount -1 do
   begin
      if Screen.Forms[i] is TForm2 then
      begin
         // Differenz zwischen alter und neuer Position ebenfalls 
         // auf die anderen Fenster anwenden
         Screen.Forms[i].Top  := Screen.Forms[i].Top+Top-FTopLeft.X;
         Screen.Forms[i].Left := Screen.Forms[i].Left+Left-FTopLeft.Y;
      end;
   end;
end;

procedure TForm1.OnMoving(var Msg: TWMMoving);
begin
   // Alte Postion merken
   FTopLeft := Point(Top, Left);
end;

[alzaimar]

Zitat:

Zitat von Union

Wieso dafür eigentlich eine eigene Klasse?....

Delphi-Quellcode:

type
  TForm1 = class(TForm)
...

Äh... was ist TForm1 dann? :P
Egal, prinzipiell hast Du Recht, die Implementierung ist wirklich relativ simpel. Es sollen aber auch andere Applikationen magnetisch sein, denn es könnte sein, das ein 'Childfenster' in C++ oder -ja :zwinker: das geht- in VB implementiert wird (Stichwort: Plugins). Und dann sollte man schon zu etwas generischen Methoden greifen.

Ich habe Windows-Messages und Shared Memory verwendet. Weiterhin ist meine Klasse skinfähig und wenn ein neuer Skin geladen wird, sollte das schon irgendwie mitgeteilt werden. Ergo kapselt man diese Funktionalität dann doch in eine eigene Klasse. Bei mir war das ein 'MagneticManager', der sich um die Visualisierung und das Management gekümmert hat.

Delphi-Quellcode:

...
Screen.Forms[i].Top  := Screen.Forms[i].Top+Top-FTopLeft.X;
Screen.Forms[i].Left := Screen.Forms[i].Left+Left-FTopLeft.Y;
...

Wusste gar nicht, das das geht... Aber zappeln da die Fenster nicht?

[Union]

Zitat:

Äh... was ist TForm1 dann?

Sicherlich ist das eine Klasse, aber hier stellvertretend für ein beliebiges Form. Ich wollte auch nur zeigen, dass man mit 10 Zeilen Code in Delphi das Problem im Grunde relativ elegant mit Bordmitteln lösen kann.

Zitat:

Aber zappeln da die Fenster nicht?

Na klar zappeln die - wenn es mehr als fünf oder so sind und die Anzahl der Controls spielkt natürlich auch eine Rolle. Das liegt aber nicht unbedingt daran, ob man jetzt eine Klasse benutzt - auch da werden ja dann wohl hoffentlich die Fenster ganz normal über API verschoben. Oder greifst Du direkt auf die Blitting-Engine Deiner Grafikkarte zu ... :shock:

[Muetze1]

Zitat:

Zitat von EWeiss

Als Hochtitulierter, Studierter ? bestimmt! Hätte ich dir etwas mehr zugetraut.

Zu allem anderen Äusserungen wurde schon was gesagt, wobei ich mich der Meinung anschliesse. Ich werde mich demnächst auch nicht mehr bemühen Leuten zu helfen, weil es am Ende so endet (ausserdem besser für meine Gesundheit). Zum dem oberen Zitat möchte ich noch anmerken, dass ich keine Studium habe und auch nichts in der Richtung betreibe. Ich habe mich selber nie "hochtituliert" - siehe Signatur.

[mschaefer]

Union hat das fatal einfach gelöst. Mir fällt dazu nur ein, dass man auch mit einer Komponente auf die Messages eines Forms zugreifen kann. Man muß nur die Parents durchlaufen bis man am Form angekommen ist und klinkt sich dann ein.

Ach so, so ein Ingenieur- oder Informatiikstudium hat aus gutem Grund einen Titel. Das wird einem nicht geschenkt und ist einfach der Nachweiss, für Biss und Ausdauer und (Prüfungs-)(Sresstoleranz auf einem Arbeitsgebiet. Es gibt natürlich auch andere Nachweismöglichkeiten, z.B. die Bill Gates-Variante.

Grüße // Martin

[Elvis]

Habe gerade den Tab hier im FF entdeckt.
Unions code lässt sich ziemlich easy in eine Komponente werfen, die man dan auf ein Form ziehen kann.
Habe das eben mal durchprobiert und es geht eigentlich...

Delphi-Quellcode:

unit uFormMagnet;

interface

uses
  Classes, Forms, Messages, Windows;

type
  TFormMagnet = class(TComponent)
  private
    fPreviousLocation  : TPoint;
    fParentsOldWinProc : TWndMethod;
    fParent            : TCustomForm;
  protected
    procedure WindowProcHandler(var message: TMessage); virtual;

    procedure OnMove(var msg: TWMMove); message WM_MOVE;
  public
    property Parent : TCustomForm read fParent;
    procedure AfterConstruction; override;
    procedure BeforeDestruction; override;
  end;

implementation
uses
  Types;

{ TFormMagnet }

procedure TFormMagnet.AfterConstruction;
begin
  inherited;

  if Owner is TCustomForm then
  begin
    fParent := TCustomForm(Owner);
    fParentsOldWinProc := Parent.WindowProc;
    Parent.WindowProc  := WindowProcHandler;
    
    fPreviousLocation  := Point(Parent.Left, Parent.Top);
  end;
end;

procedure TFormMagnet.BeforeDestruction;
begin
  inherited;

  if Assigned(fParentsOldWinProc) then
    Parent.WindowProc := fParentsOldWinProc;
end;

procedure TFormMagnet.WindowProcHandler(var message: TMessage);
begin
  if message.Msg = WM_MOVE then
    OnMove(TWMMove(message));

  if Assigned(fParentsOldWinProc) then
    fParentsOldWinProc(TMessage(message));
end;

procedure TFormMagnet.OnMove(var msg: TWMMove);
var
   i    : Integer;
   form : TCustomForm;
begin
  for i := 0 to Screen.FormCount - 1 do
  begin
    form := Screen.Forms[i];

    if form <> Parent then
    begin
      // Differenz zwischen alter und neuer Position ebenfalls
      // auf die anderen Fenster anwenden

      form.Top  := form.Top  + (Parent.Top  - fPreviousLocation.y);
      form.Left := form.Left + (Parent.Left - fPreviousLocation.x);
    end;
  end;

  fPreviousLocation := Point(Parent.Left, Parent.Top);
end;

end.

Natürlich ist es Blödsinn das ganze von der Seite aufzuwickeln.
Eigentlich sollte derjenige, der sich an ein Fenster gedockt hat, sich in dessen MessageLoop klinken und mitbewegen und beim Abdocken wieder herausklinken.
Die simple Lösung oben würde schon bei einem 2. Form mit der Komponente drauf oder eine weitere auf der gleichen Form aus den Fugen geraten. ;)

[EWeiss]

Zitat:

Zitat von mschaefer

Union hat das fatal einfach gelöst. Mir fällt dazu nur ein, dass man auch mit einer Komponente auf die Messages eines Forms zugreifen kann. Man muß nur die Parents durchlaufen bis man am Form angekommen ist und klinkt sich dann ein.

Ach so, so ein Ingenieur- oder Informatiikstudium hat aus gutem Grund einen Titel. Das wird einem nicht geschenkt und ist einfach der Nachweiss, für Biss und Ausdauer und (Prüfungs-)(Sresstoleranz auf einem Arbeitsgebiet. Es gibt natürlich auch andere Nachweismöglichkeiten, z.B. die Bill Gates-Variante.

Grüße // Martin

Der Effekt dieser lösung ist gleich 0
1 Prüfung zu den Screenrändern fehlt
2 Taskbar wurde nicht mit einbezogen
3 spätstens mit der 3 Form bricht das Gerüst zusammen
4 Sobald von der Masterform getrennt ist der magnetismus der anderen Formen nicht mehr gegeben
5 die ausmaße der parent Formen wurde nicht berücksichtigt
6 Kein TRECT Array
7 Kein HWND Array

usw...

über performance müssen wir gar nicht erst reden.

Zitat:

Man muß nur die Parents durchlaufen bis man am Form angekommen ist und klinkt sich dann ein.

Schlechteste Lösung überhaupt!

Die Parents sollten bei der Übergabe von vorn herein schon
zu einer HWND Collection addiert werden.
Dann muss man nix suchen, da vorhanden.
Davon sehe ich in seiner Lösung auch nichts.

gruß

[Elvis]

Zitat:

1 Prüfung zu den Screenrändern fehlt
2 Taskbar wurde nicht mit einbezogen

Öhm, es ging hier nicht darum dir fertigen Code zu liefern.
Es ging nur um ein Beispiel wie man a) simpel die Nachrichten eines Fensters abfangen kann
b) andere Fenster mitbebewegen kann.

Zitat:

3 spätestens mit der 3 Form bricht das Gerüst zusammen

Wie gesagt, der Code oben gibt dir alle Forms deiner App zur Hand und lässt dich dann entscheiden was zu tun ist.
Herauszufinden ob ein Form an die Hauptform gedockt ist wirst du doch noch hinkriegen, oder? :roll:

Zitat:

4 Sobald von der Masterform getrennt ist der magnetismus der anderen Formen nicht mehr gegeben
5 die ausmaße der parent Formen wurde nicht berücksichtigt

ach ne... :roll:

Zitat:

6 Kein TRECT Array
7 Kein HWND Array

6, setzen. Was will man mit einem Rect/Handle-Array wenn man bereits eine objektorientierte Abstraktion über die WinAPI benutzt?
Nix? Richtig!

Zitat:

Schlechteste Lösung überhaupt!

Du wirst lachen, im Normalfall verfügen die Leser in diesem Forum über genügend Fähigkeiten in Sachen Abstraktion und Assoziation, dass sie erkannt hätten, dass es ein Beispiel ist was grundlegende Dinge erklären soll. Natürlich hatten weder Union noch ich vor fertigen Code zu liefern. :wall:

Es ist übrigens enorm schwierig Argumente zu suchen, meine Meinung darüber zu ändern, warum ich Benutzer einer gewissen "Programmier"-sprache nicht ausstehen kann.
Vor allem wenn sie sich alle Mühe geben, jedem Detail des herrschenden Klischees zu entsprechen. :?

[EWeiss]

Zu deinen Antworten.
Einfach Genial hast dich selbst übertroffen.

Zitat:

Öhm, es ging hier nicht darum dir fertigen Code zu liefern.
Es ging nur um ein Beispiel wie man a) simpel die Nachrichten eines Fensters abfangen kann

Was ist ein Beispiel wert das nicht annährend funktional ist.
Verzichte Dankend auf fertigen Code wenn er so .. eine zeile höher.

Zitat:

Wie gesagt, der Code oben gibt dir alle Forms deiner App zur Hand und lässt dich dann entscheiden was zu tun ist.
Herauszufinden ob ein Form an die Hauptform gedockt ist wirst du doch noch hinkriegen, oder?

Ich will gar nichts hinkriegen.
Nur dokumentieren wie schlecht die Codeansätze sind..
Kein Hand kein Fuss.

Man übergibt das Handle seiner anwendung
AddMainWindow(MasterHandle)
Mit jeder neu aufgerufenen Form wird das Handle dieser Form mit
AddMainWindow(Form, MasterHandle) zum ParentWindow(MasterHandle) als Collection addiert.

Was ist da so schwer ?
Ist ein leichtes abgeleitet davon Records und andere benötigte funktionen
aus der Collection zu übergeben/zu vergleichen.

Zitat:

Was will man mit einem Rect/Handle-Array wenn man bereits eine objektorientierte Abstraktion über die WinAPI benutzt?

Hast du selbst schon sehr genial beantwortet. :roll: :wall:
Ich wiederhole mich !!! :-D

Zitat:

Natürlich hatten weder Union noch ich vor fertigen Code zu liefern.

Du wiederholst dich gerne kann das sein :wall:

Zitat:

Es ist übrigens enorm schwierig Argumente zu suchen, meine Meinung darüber zu ändern, warum ich Benutzer einer gewissen "Programmier"-sprache nicht ausstehen kann.
Vor allem wenn sie sich alle Mühe geben, jedem Detail des herrschenden Klischees zu entsprechen.

Zugegeben Delphi ist eine feine Sprache.
Du solltest aber mal von deinen Egotripp runterkommen .. Delphi über alles. :mrgreen:

gruß

[Union]

Zitat:

über performance müssen wir gar nicht erst reden

Der Code war nur ein POC wie man so etwas generell lösen kann und innerhalb von ein paar Minuten hingehackt um evtl. Denkanstöße zu liefern. Es sollte nicht heissen, dass es die komplette Klasse TMagnetic auch abbildet - es sollte vielmehr zeigen, was für Möglichkeiten Delphi in dem Bereich bietet ohne große Verrenkungen bietet.

Es ist im Übrigen generell nicht sehr performant, wenn man mehrere Fenster gleichzeitig verschiebt. Letztendlich mündet alles, ob Delphi oder VB, in einem Sendmessage(WM_WINDOWPOSCHANGED...) und das löst wieder eine unendliche Kette von Folgenachrichten aus.

Eine Lösung, wie das peformanter vonstatten gehen kann, würde mich aber sehr interessieren.

[Daniel]

Emil, kommt mal wieder ein wenig runter. Dein Interesse an einer sachlichen Diskussion ist nicht mehr erkennbar.

Wenn es nur noch um hohles Geblöke geht oder die Frage, nun doch noch irgendwie Recht zu behalten, dann bitte ich darum, diese Diskussion woanders fortzusetzen. Aktuell ist dieses Thema in einer Situation festgefahren, in der wir lediglich primitivem Herumgetrolle beiwohnen können und dafür zahle ich den Server nicht. Also: Reißt Euch allesamt (!) am Riemen und hievt diese Diskussion wieder auf ein ordentliches Level. Wer daran kein Interesse hat, möge diesem Thema fern bleiben.


Union hat dankenswerterweise die Frage nach der Performanz aufgegriffen. Vielleicht ist das ja ein netter Punkt zum Anknüpfen.

[EWeiss]

Zitat:

Zitat von Union

Zitat:

über performance müssen wir gar nicht erst reden

Der Code war nur ein POC wie man so etwas generell lösen kann und innerhalb von ein paar Minuten hingehackt um evtl. Denkanstöße zu liefern. Es sollte nicht heissen, dass es die komplette Klasse TMagnetic auch abbildet - es sollte vielmehr zeigen, was für Möglichkeiten Delphi in dem Bereich bietet ohne große Verrenkungen bietet.

Es ist im Übrigen generell nicht sehr performant, wenn man mehrere Fenster gleichzeitig verschiebt. Letztendlich mündet alles, ob Delphi oder VB, in einem Sendmessage(WM_WINDOWPOSCHANGED...) und das löst wieder eine unendliche Kette von Folgenachrichten aus.

Eine Lösung, wie das peformanter vonstatten gehen kann, würde mich aber sehr interessieren.

Ich habs geprüft mit Winspector Spy kann deine Meinung nicht bestätigen.
Es löst gerade mal 1 nachfolgende Nachrichten aus.

WM_GETMINMAXINFO
Danach wird WM_WINDOWPOSCHANGED continue processing false ausgeführt.

gruß

[mschaefer]

Moin, moin,

THEMA Eigenformsuche durch Komponente:

Es gibt da zwei Fälle:

1. Die Komponente ist von TComponent abgeleitet.
Diese kann sie auf Panels liegen, die wieder auf Panels liegen... Da kann man sich zur Form hochhangeln. Das ist aber im Create der Komponente ein einmaliger Vorgang. Dann hat man den Pointer auf das Form in einer Variable.

2. Die Komponente ist von TObjekt abgeleitet.
Dann ist ihr Parent automatisch das Form.

Zitat:

Zitat von EWeiss

[Die Parents sollten bei der Übergabe von vorne herein schon zu einer HWND Collection addiert werden.

Bei beiden Varianten habe ich dann einen Pointer des Typs TForm. Weiterhin hat jedes MDI eine Childs-Liste. Zusätzliche Arrays braucht man unter Delphi nicht, da man Aufbaubedingt nichts suchen muß, soweit man den Effekt nur innerhalb der eigenen Applikation haben möchte. Wenn er Applikationsübergreifend stattfinden soll, dann muß geklärt werden, welche Applikation Master ist und welche sich nur neu positioniert.


THEMA Perfomance:
Innerhalb einener MDI Applikation kann man auch ohne Windows-Messages auskommen, denn in der MDI-ChildListe hat man die anderen Childfenster. Über ihre Position und Größe lassen sich dann die Fensterabstände berechnen und das Verschieben direkt ohne Message erreichen.

So long // Martin

[Union]

Hi,

welche Aktion hat diese (und nur diese?) Nachricht ausgelöst? Die VB-Klasse oder ein Delphi-Programm? Oder einfach das manuelle Verschieben eine bleibigen Fensters?

[EWeiss]

Zitat:

Zitat von Union

Hi,

welche Aktion hat diese (und nur diese?) Nachricht ausgelöst? Die VB-Klasse oder ein Delphi-Programm? Oder einfach das manuelle Verschieben eine bleibigen Fensters?

Das verschieben meines Fensters(Player) incl.. der angedockten Fenster.
Winspector Spy überprüft nur meine Fenster andere Fenster werden nicht berücksichtigt.

gruß

[Union]

Also bei mir löst es immer folgendes aus (in den "angedockten" Fenstern):

• WM_WINDOWPOSCHANGING
• WM_GETMINMAXINFO
• WM_WINDOWPOSCHANGING
• WM_WINDOWPOSCHANGED
• WM_MOVE

Ermittelt habe ich das mit WinSpector

[EWeiss]

Zitat:

Zitat von Union

Also bei mir löst es immer folgendes aus (in den "angedockten" Fenstern):

• WM_WINDOWPOSCHANGING
• WM_GETMINMAXINFO
• WM_WINDOWPOSCHANGING
• WM_WINDOWPOSCHANGED
• WM_MOVE

Ermittelt habe ich das mit WinSpector

Dürfte aber nicht das Performance problem auslösen.

Man hätte ja auch noch die möglichkeit

• BeginDeferWindowPos
  DeferWindowPos
  EndDeferWindowPos

anstelle von MoveWindow zu verwenden.

Dürfte die performance wieder etwas verbessern.
Aber das ist ja allgemein bekannt.

gruß

[Union]

Ja, darüber strieten sich die Experten. Wenn ich mein altes Beispiel wie folgt ändere:

Delphi-Quellcode:

procedure TForm1.OnMove(var Msg: TWMMove);
var
   i, NumWindows : integer;
   hWinPosInfo : Cardinal;
   OldPos : TRect;
begin
   inherited;
   NumWindows := 0;
   for i := 0 to Screen.FormCount -1 do
   begin
      if Screen.Forms[i] is TForm2 then
      begin
         inc(NumWindows);
      end;
   end;

   hWinPosInfo := BeginDeferWindowPos(NumWindows);

   for i := 0 to Screen.FormCount -1 do
   begin
      if Screen.Forms[i] is TForm2 then
      begin
         // Differenz zwischen alter und neuer Position ebenfalls
         // auf die anderen Fenster anwenden
         GetWindowRect(Screen.Forms[i].handle, OldPos);
         hWinPosInfo := DeferWindowPos(hWinPosInfo,
                           Screen.Forms[i].Handle,
                           0,
                           OldPos.Left+Left-FTopLeft.Y,
                           OldPos.Top+Top-FTopLeft.X,
                           OldPos.Right-OldPos.Left,
                           OldPos.Bottom-OldPos.Top,
                           SWP_NOZORDER or SWP_NOACTIVATE);
      end;
   end;

   EndDeferWindowPos(hWinPosInfo);
end;

... dann verbessert sich die Performance nicht merklich. Und es werden immer noch die selben Nachrichten ausgeführt, nur eben in geringerem zeitlichen Abstand. Vielleicht elimiert der Aufwand für den Aufbau der Liste den dadruch entstehenden Performancegewinn ?

[EWeiss]

Zitat:

Zitat von Union

Ja, darüber strieten sich die Experten. Wenn ich mein altes Beispiel wie folgt ändere:

Delphi-Quellcode:

procedure TForm1.OnMove(var Msg: TWMMove);
var
   i, NumWindows : integer;
   hWinPosInfo : Cardinal;
   OldPos : TRect;
begin
   inherited;
   NumWindows := 0;
   for i := 0 to Screen.FormCount -1 do
   begin
      if Screen.Forms[i] is TForm2 then
      begin
         inc(NumWindows);
      end;
   end;

   hWinPosInfo := BeginDeferWindowPos(NumWindows);

   for i := 0 to Screen.FormCount -1 do
   begin
      if Screen.Forms[i] is TForm2 then
      begin
         // Differenz zwischen alter und neuer Position ebenfalls
         // auf die anderen Fenster anwenden
         GetWindowRect(Screen.Forms[i].handle, OldPos);
         hWinPosInfo := DeferWindowPos(hWinPosInfo,
                           Screen.Forms[i].Handle,
                           0,
                           OldPos.Left+Left-FTopLeft.Y,
                           OldPos.Top+Top-FTopLeft.X,
                           OldPos.Right-OldPos.Left,
                           OldPos.Bottom-OldPos.Top,
                           SWP_NOZORDER or SWP_NOACTIVATE);
      end;
   end;

   EndDeferWindowPos(hWinPosInfo);
end;

... dann verbessert sich die Performance nicht merklich. Und es werden immer noch die selben Nachrichten ausgeführt, nur eben in geringerem zeitlichen Abstand. Vielleicht elimiert der Aufwand für den Aufbau der Liste den dadruch entstehenden Performancegewinn ?

Deshalb ist meine Vorstellung gewesen!

Die handles und Recs in einen array einzubinden.
Jeder zugriff auf die Form (bei VB zumindest so) setzt eine neue Initialisierung dieser vorraus.
das geht auf die performance.

Der Vorteil es wird keine Form mehr abgefragt sondern nur noch
über die API IsWindow(handle) or IsWindow(hParent) die handles selbst überprüft.

Gruß

[Muetze1]

Zitat:

Zitat von EWeiss

Deshalb ist meine Vorstellung gewesen!

?? Hab ich nicht verstanden.

Zitat:

Zitat von EWeiss

Die handles und Recs in einen array einzubinden.
Jeder zugriff auf die Form (bei VB zumindest so) setzt eine neue Initialisierung dieser vorraus.
das geht auf die performance.

In VB mag das so sein, in Delphi ist dies nicht der Fall. Daher auch von den Vorrednern das Unverständnis eine extra Rect/Window Handle Liste zu führen.

[Daniel G]

@EWeis: Evtl. solltest du dir doch mal ein gutes Buch über Delphi holen und mal von Null anfangen? :duck:

[EWeiss]

Zitat:

In VB mag das so sein, in Delphi ist dies nicht der Fall. Daher auch von den Vorrednern
das Unverständnis eine extra Rect/Window Handle Liste zu führen.

Danke hab's verstanden !

gruß

[EWeiss]

Zitat:

Zitat von Daniel G

@EWeis: Evtl. solltest du dir doch mal ein gutes Buch über Delphi holen und mal von Null anfangen? :duck:

Na ja mußt dich nicht verstecken.
Denke wenn man zu einer anderen Sprache wechselt kann man
nicht vorraussetzen das die gepflogenheiten der neuen Sprache direkt bekannt sind.

Delphianer machen das mit ihren Boardmitteln weil bekannt ich über die API
was bitte schön ist da verkehrt ?
Wie schon gesagt es führt zum gleichen ziel, wenn auch von euch mit unverständnis ausgelegt!

Übrigends habe ich festgestellt das einige hier mit API überhaupt nichts anzufangen wissen.
Weil sie 'nur' mit Boardmitteln arbeiten.

Und fragen zu stellen davor habe ich mich noch nie gefürchtet.
Dumme Fragen gibt es nicht ... nur dumme Antworten.

In dem Sinne .


Gruß

[Elvis]

Zitat:

Zitat von EWeiss

Übrigends habe ich festgestellt das einige hier mit API überhaupt nichts anzufangen wissen.
Weil sie 'nur' mit Boardmitteln arbeiten.

In diesem Thread? Wer? :gruebel:
Es macht halt nur dann Sinn wenn man es von der VCL nicht vorgesetzt bekommt.
Denn redundanter Code ist nicht wirklich das Gelbe vom Ei. Irgendwann in den nächsten 2 Jahren wird die VCL von ANSI auf Unicode umgestellt. Code, der daran vorbeigeht könnte dann schnell Ärger machen.

[sailxia]

hi:
i found a better Class for make magnet form, please look at:

http://codecentral.borland.com/Item.aspx?id=18654

http://www.bcp-software.nl/artikelen/magnets.html

you can download it here:

[alias5000]

This one seems to be ingenious! :bounce1: :bounce1:
Thank you very much!

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Programmieren allgemein" nach "VCL / WinForms / Controls" verschoben.
Falsche Sparte, da delphispezifisch

[EWeiss]

Zitat:

i found a better Class for make magnet form, please look at:

Ist voll müll das teil führt nicht annährend das aus was die von
mir verwendete Classe zu leisten vermag.

gruß

[alzaimar]

Zitat:

Zitat von EWeiss

Zitat:

i found a better Class for make magnet form, please look at:

Ist voll müll das teil führt nicht annährend das aus was die von
mir verwendete Classe zu leisten vermag.

gruß

So hart würde ich das nicht sehen, zumal ich deine Klasse nicht kenne. Aber eine AV produziert das Teil (das so "ingenious" ist) sehr wohl. Wie wohl so oft die Teile von CodeCentral über ein Frickelstadium nicht hinaus gehen.

Zitat:

Zitat von EWeiss

Man hätte ja auch noch die möglichkeit

• BeginDeferWindowPos
  DeferWindowPos
  EndDeferWindowPos

anstelle von MoveWindow zu verwenden.

Dürfte die performance wieder etwas verbessern.
Aber das ist ja allgemein bekannt.

Mir nicht. Meine 'Magnetic Window' Klasse war mit dem DeferWindowPos wesentlich langsamer als mit separaten 'MoveWindow' Aufrufen. Ich hab die Klasse vor ca. 6-7 Jahren mal entwickelt, als die PC (und insbesondere die Grafik) noch nicht so performant waren. Heute ist das vermutlich bedeutungslos, aber da ihr hier scheinbar Erbsen zählt, würde ich Deine o.g. Aussage hinsichtlich einer Performanceoptimierung vorsichtig behandeln: Für eine eventuell flüssigere Darstellung der bewegenden Fenster hast Du aber sicherlich Recht.

Wie weit bist Du eigentlich mit deinen Bemühungen? Willst Du uns Deine Ergebnisse nicht einmal präsentieren?

[EWeiss]

Zitat:

So hart würde ich das nicht sehen, zumal ich deine Klasse nicht kenne. Aber eine AV produziert das Teil (das so "ingenious" ist) sehr wohl. Wie wohl so oft die Teile von CodeCentral über ein Frickelstadium nicht hinaus gehen.

Ja stimmt schon :zwinker:

Aber !
Die ´Klasse sollte schon alles beinhalten und das ohne AV.
Damit meine ich ..

Die Screenränder beachten, die Form darf nicht drüber hinaus gehen.
Eine Snap funktion vorweisen welche bei eingestellter Pixelanzahl automatisch am screenrand oder
bei anderen Formen des gleichen Projekts andocken.
Unabhängig davon ob die Hauptform im verbund mit einer anderen Form ist.
Alle Formen(Fenster) sollten untereinander andockbar sein auch unabhängig von der Masterform.
screenrand,snap muss dabei ebenfalls funktionieren.
Das ganze sollte ganz einfach aus einer Plugin Schnittstelle (So wie bei mir) verwendet werden können.
Hat den vorteil das man diese Funktionen nicht extra in den plugins einbinden muss.
aus dem Plugin übergeben .. dann merkt die Hauptanwendung das, also nur das Hwnd des Fensters aus dem Plugin.
Zusätzlich Mit und ohne Titelleiste.. zu verschieben sein.

So.. und das wichtigste alles nur mit einer zeile Code.
So wie in der von mir benutzen OpenSourceVb-Classe.

Ich selbst habe leider im moment nicht viel zeit was das proggen angeht.
Deshalb habe ich diese Classe(Übersetzumg) erst mal zurseite gelegt.

Mache weiter wenn ich wieder bock dazu habe. :mrgreen:

gruß

EDIT:
Aber wir hatten ja schon das vergnügen. :zwinker:
Noch mal zum besseren verständnis!

Was du als Hack bezeichnet hast ist keiner.
Bei VB ist halt das problem das man mit Subclassing in der IDE nicht arbeiten kann wenn es darum geht Fehler aufzuspüren.
Die IDE schmiert dann einfach ab ohne irgendeine Meldung.(MS-Mist!)
Die ASM Routine beinhaltet nichts anderes als die 'Subclass, Winproc' stellt diese VB also als Maschinencode
zur verfügung damit bei der Fehlersuche innerhalb der IDE (sollte man einen Breakpoint) in
der Winproc setzen es nicht zum Absturz kommt.
In Delphi ist dieser ASM-Code nicht nötig!!!

Wollte das nur nochmal gesagt haben.

M

Zitat:

ir nicht. Meine 'Magnetic Window' Klasse war mit dem DeferWindowPos wesentlich langsamer als mit separaten 'MoveWindow' Aufrufen.

Kommt darauf an wie du es getestet hast.
Ohne fremde Fenster im Hintergrund macht es sich bemerkbar.
Wenn andere Fenster dahinter sind bringt es keinen Vorteil da beim ziehen die Fenster dahinter
auch neu gezeichnet werden müssen. Das geht dann auf die performance.

[QuickAndDirty]

Wozu über Perfomance sprechen?
Kann nicht egal sein wieviel CPU Zeit das
verschieben von Fenstern in Anspruch nimmt, solange die
CPU nicht bei 100% landet? *provozier*
Und wie schnell das Fenster wieder bereit für Ereignisse ist
ist wohl auch egal wenn es unter 500 ms dauert, oder?

Kann man da nicht einfach doppelt gepufferte Fenster nehmen so das
die Bewegungen flackerfrei ablaufen?

(Unqualifizierte Meinung von jemandem der für sowas die Dock Eigenschaften benutzt)

[EWeiss]

Zitat:

Zitat von QuickAndDirty

Wozu über Perfomance sprechen?
Kann nicht egal sein wieviel CPU Zeit das
verschieben von Fenstern in Anspruch nimmt, solange die
CPU nicht bei 100% landet? *provozier*
Und wie schnell das Fenster wieder bereit für Ereignisse ist
ist wohl auch egal wenn es unter 500 ms dauert, oder?

Kann man da nicht einfach doppelt gepufferte Fenster nehmen so das
die Bewegungen flackerfrei ablaufen?

(Unqualifizierte Meinung von jemandem der für sowas die Dock Eigenschaften benutzt)

KA was du meinst.
Die Zeit kann schon sehr lang sein.
Könnte ja meine Form in zeitlupentempo über den Desktop ziehen dann dauert es unter umständen Minuten.
Solange wie das Mousedown ereignis nicht aufgelößt wird befindest du dich immer noch
in der releasecapture methode und solange lastest du deine CPU aus.
Unabhängig davon ob du das Fenster nun schiebst oder nicht.

Hat aber nix mit der doppelpufferung des fensters zu tun.

gruß

[alzaimar]

Zitat:

Zitat von QuickAndDirty

Wozu über Perfomance sprechen?

Weil es nervt, wenn Fenster ruckelig über den Bildschirm fleuchen, wenn man sie zieht.

Zitat:

Zitat von QuickAndDirty

Kann nicht egal sein wieviel CPU Zeit das
verschieben von Fenstern in Anspruch nimmt, solange die
CPU nicht bei 100% landet? *provozier*

DAS widerum ist wirklich egal.

Schnöde Windows-Fenster zu bewegen ist keine Kunst, aber mit Bitmaps, Alpha-Blending (wegen der weischen Ränder) und sonstigem Schnickschnack wird das schon haarig.