Fenster Vista-like schließen
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
b) OSVersion() kann XP und das zählt, auf allen anderen OS funktionierts wahrscheinlich wegen fehlender API eh nicht...
Gruß
Scarabol
Abgeschlossen Projekte:
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
- Tafkadasom2k5
- Beiträge: 1578
- Registriert: 13.08.2005 14:31
- Kontaktdaten:
Scarabol hat geschrieben:Hi Leute,
könnte man nicht den Fenster Speicher direkt manipulieren vor allem um die Größe zu ändern?

Oder verstehe ich dich da irgendwie falsch?
Davon mal ganz Abgesehen, dass ich den Sinn davon nicht wirklich verstehe.
OpenNetworkConnection() hat geschrieben:Versucht eine Verbindung mit dem angegebenen Server aufzubauen. 'ServerName$' kann eine IP-Adresse oder ein voller Name sein (z.B.: "127.0.0.1" oder "ftp.home.net").
php-freak hat geschrieben:Ich hab die IP von google auch ned rausgefunden!
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
Sagt bescheid wenn ich irgendwo falsch liege...
Gruß
Scarabol
Abgeschlossen Projekte:
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
- Tafkadasom2k5
- Beiträge: 1578
- Registriert: 13.08.2005 14:31
- Kontaktdaten:
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ürdeScarabol 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...

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 michScarabol 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...

Zudem kann die "Callback" selber nichts manipulieren- höchstens mit einem API-Call in ihr. Wodurch wir wieder bei der Frage davor wären.

Mh. Entweder, wir reden aneinander vorbei, und ich verstehe nicht, was du genau willst, oder... "Bescheid!!"Scarabol hat geschrieben:Sagt bescheid wenn ich irgendwo falsch liege...



OpenNetworkConnection() hat geschrieben:Versucht eine Verbindung mit dem angegebenen Server aufzubauen. 'ServerName$' kann eine IP-Adresse oder ein voller Name sein (z.B.: "127.0.0.1" oder "ftp.home.net").
php-freak hat geschrieben:Ich hab die IP von google auch ned rausgefunden!
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
Gruß
Scarabol
Abgeschlossen Projekte:
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
- Tafkadasom2k5
- Beiträge: 1578
- Registriert: 13.08.2005 14:31
- Kontaktdaten:
Also nochmal:
Bescheid
Bescheid

OpenNetworkConnection() hat geschrieben:Versucht eine Verbindung mit dem angegebenen Server aufzubauen. 'ServerName$' kann eine IP-Adresse oder ein voller Name sein (z.B.: "127.0.0.1" oder "ftp.home.net").
php-freak hat geschrieben:Ich hab die IP von google auch ned rausgefunden!
- Tafkadasom2k5
- Beiträge: 1578
- Registriert: 13.08.2005 14:31
- Kontaktdaten:
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.

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 aufreagierst, 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
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.
Wie es scheint, verstehst du nicht genau, was eine Callback ist, oder ich verstehe nicht was genau du damit meinst.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...

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
Code: Alles auswählen
Event.l = WaitWindowEvent()
If Event = #WM_PAINT
;Hier code- uU mit API
EndIf
Code: Alles auswählen
Procedure MyWindowCallback(WindowID, Message, wParam, lParam)
If Message = #WM_PAINT
;Hier Code- uU mit API
EndIf
EndProcedure
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
OpenNetworkConnection() hat geschrieben:Versucht eine Verbindung mit dem angegebenen Server aufzubauen. 'ServerName$' kann eine IP-Adresse oder ein voller Name sein (z.B.: "127.0.0.1" oder "ftp.home.net").
php-freak hat geschrieben:Ich hab die IP von google auch ned rausgefunden!
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
Gruß
Scarabol
Abgeschlossen Projekte:
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP
Schreibmaschine, Bildschirmlupe, Wings3DtoOgreMeshConverter
Watch: PureArea
PB-V: 4
WinXP