PureBoard

a) Ich bin nicht von Vista überzeugt ich bleib lieber bei XP, aber dazu mehr in der Laberecke...

b) OSVersion() kann XP und das zählt, auf allen anderen OS funktionierts wahrscheinlich wegen fehlender API eh nicht...

Gruß
Scarabol

>OSVersion() kann schon vista?

Schon lange.

Scarabol hat geschrieben:Hi Leute,

könnte man nicht den Fenster Speicher direkt manipulieren vor allem um die Größe zu ändern?

Wie meinen? In Windows direkt? Bei Win98 und Konsorten würde das unter Umständen sogar gehen, aber bei einem NT-Kernel?

Oder verstehe ich dich da irgendwie falsch?
Davon mal ganz Abgesehen, dass ich den Sinn davon nicht wirklich verstehe.

Jut also, ich nehm mal an das die Eigenschaften des Fensters irgendwo im Speicher abgelegt sind...Diese kann man ja nun auslesen und direkt die Größe ändern...Das hat den Vorteil das man nicht den API Call SetWindowPos_() machen muss, sodass man die oben beschriebene Methode in ein WindowCallback packen könnte und während der AnimateWindow_() arbeitet würde der Callback die Größe manipulieren...

Sagt bescheid wenn ich irgendwo falsch liege...

Gruß
Scarabol

Scarabol hat geschrieben:Jut also, ich nehm mal an das die Eigenschaften des Fensters irgendwo im Speicher abgelegt sind...Diese kann man ja nun auslesen und direkt die Größe ändern...

Soweit ja, aber das geht normalerweise nur mit API-Calls. Was Anderes wäre im Normalfall "brutal" bzw dumm- da es nicht auf jedem System laufen würde. Fensterklassen sind ja von System zu System anders, und es wäre nicht wirklich gut, das nur auf eine bestimmte Plattform zu beschneiden. Sofern das mit dem Speicher auslesen überhaupt geht-> schließlich ist der Speicher normalerweise geschützt. IMAs sind da vorprogrammiert- wenn es denn überhaupt irgendwie "direkt" funktionieren wird. (Wasauchimmer das für einen Vorteil bringen würde )

Scarabol hat geschrieben:Das hat den Vorteil das man nicht den API Call SetWindowPos_() machen muss, sodass man die oben beschriebene Methode in ein WindowCallback packen könnte und während der AnimateWindow_() arbeitet würde der Callback die Größe manipulieren...

Häh?! Wo ist denn der "Vorteil" an der ganzen Geschichte? Was ist so schlimm an API-Calls? Und warum kann man in einer Callback keine API-Calls benutzen? Du verwirrst mich
Zudem kann die "Callback" selber nichts manipulieren- höchstens mit einem API-Call in ihr. Wodurch wir wieder bei der Frage davor wären.

Scarabol hat geschrieben:Sagt bescheid wenn ich irgendwo falsch liege...

Mh. Entweder, wir reden aneinander vorbei, und ich verstehe nicht, was du genau willst, oder... "Bescheid!!"

Also im Prinzip kann man ja das Fenster animieren und dabei einen Callback verwenden. Aber nun geht das aus irgendeinem Grund nicht gut, es kommt zu Anzeigefehlern...daher meine Idee auf den API Call im Callback des Windows verzichten und auf brutalste Art und Weise direkt den Speicher manipulieren...

Gruß
Scarabol

Also nochmal:
Bescheid

@Tafkadasom
6! Setzen!
Danach war diesmal nicht gefragt

Gruß
Scarabol

PS
Bischen konkreter bitte...

Was meinst du, was die WinAPI macht? Und was es für einen relevanten Unterschied macht, ob man es direkt verändern würde, oder über API? Wenn es tatsächlich einen Unterschied gibt- dann hat sie bestimmt einen relevanten Hintergrund- nur eben ne Variable verändern heißt nicht, dass das Nachrichtensystem da direkt drauf greift und es verarbeitet.

Das, was die WinAPI macht, ist in den meisten Fällen absolut notwendig- weil: An den Speicher kommst du nicht "einfach so", weil dieser AFAIK dem Betriebssystem gehört. Zudem kenne ich keine Möglichkeit, da jetzt so heranzukommen. Selbst wenn das möglich wäre- du müsstest vorher noch die anderen Funktionen, die dieser API-Call macht, nachbauen.

Scarabol hat geschrieben:daher meine Idee auf den API Call im Callback des Windows verzichten und auf brutalste Art und Weise direkt den Speicher manipulieren...

Wie es scheint, verstehst du nicht genau, was eine Callback ist, oder ich verstehe nicht was genau du damit meinst.

Die Standardcallback des Systems wird im immer angesprochen. Sofern man keine "eigene" im Code definiert, werden einfach diverse Nachrichten von PureBasic-System kopiert (aus der Callback, die immer existiert), und über "WindowEvent" und "EventWParam()"/"EvemtLParam()" ausgespuckt. Das heiß, dass eigentlich IMMER eine Callback im Spiel ist.

Jetzt bleibt- so wie ich das verstehe- nur der Unterschied ob du
-> über das Purebasic System auf die Nachrichten zugreifst
-> über eine definierte Callback auf die Nachrichten zugreifst.
Im Endeffekt kommt es aber aufs Selbe hinaus- sofern die Nachrichten vom PB-System unterstützt werden.
Bedeutet also folgerichtig: Ob du nun auf reagierst, oder auf reagierst, ist im Endeffekt egal. Nur, dass Callbacks Low-Level sind (lt. PB-Hilfe). Um das Flackern zu reduzieren käme es in Frage, manche Nachrichten unter bestimmten Bedingungen abzufangen, sodass sie nicht von Windows abgefangen werden. So könnte man einen Overhead beim Verarbeiten vermeiden, und sich nur auf die reduzierten Nachrichten konzentrieren (und Windows auch).

Von daher schließen sich API-Calls im Zusammenhang mit Callbacks nicht aus! Wie gesagt: Es wäre total widersinnig (noch möglich) "direkt im Speicher" was zu machen, weil die API schon ihren Zweck hat, und man den nicht 100% von Außen sehen kann (sofern du keine Lust auf Disassemblieren und Auseinandernehmen hast).

Wenn du das Flackern ändern willst, musst du komplett in einer Callback arbeiten, und diese eben dementsprechend anpassen. Ob das dann "überall" ohne Flackern funktioniert ist zwar fraglich (weil wegen Hardware/Treiber-Unterschiede, unter Umständen Windowsversions-Unterschiede im API-Call etc), aber man kann einiges damit optimieren.

Gr33tz
Tafkadasom2k5

Problem ist und bleibt aber das das Flackern durch ein Löschen des Fensterinhalts passiert der aber nicht durch eine WindowsMessage ausgelöst wird sondern durch den API Call selber...

Gruß
Scarabol