Übersetzung Class MagneticWindow

[alias5000]

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

[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 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 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

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.

gruß

EDIT:
Aber wir hatten ja schon das vergnügen.
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 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 von QuickAndDirty:

Wozu über Perfomance sprechen?

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

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.