(BUG) OpenScreen() und andere Schwierigkeiten!

nco2k · Beitrag von **nco2k** » 01.12.2004 09:29

bug nummer 8.)

wenn man im folgenden code (welcher InitMouse() : ExamineMouse() beinhaltet), auf ein darüber liegendes fenster wie z.b. dem debbuger klickt und anschliessend wieder auf diese anwendung, dann wird der mousecursor auf die letzte gespeicherte position zurückversetzt. das sollte fred irgendwie beheben/ändern. bei einem ego shooter wäre sowas tödlich.

ausserdem wird beim alt+tab taskswitch oder beim rechtsklick (kontextmenü) auf die anwendung in der taskleiste, die einschränkung des mousecursors nicht aufgehoben, es sei den man öffnet das startmenü mittels der win-tasten und geht ohne umwege direkt dorthin (zur taskleiste) und rechtsklickt die anwendung.

Code: Alles auswählen

Procedure IsWindowActive()
  If GetForegroundWindow_() = WindowID()
    Result = #True
  Else
    Result = #False
  EndIf
  ProcedureReturn Result.l
EndProcedure

If InitSprite() = 0 Or InitMouse() = 0
  End
EndIf

hWnd.l = OpenWindow(0, 0, 0, 800, 600, #PB_Window_SystemMenu | #PB_Window_ScreenCentered, "Test")
If OpenWindowedScreen(hWnd, 0, 0, WindowWidth(), WindowHeight(), 0, 0, 0) = 0
  End
EndIf

Repeat
  
  Delay(10)
  
  FlipBuffers()
  ClearScreen(0, 0, 0)
  
  StartDrawing(WindowOutput())
  Circle(WindowMouseX(), WindowMouseY(), 16, RGB(255, 0, 0))
  StopDrawing()
  
  If IsWindowActive() = #True And ScreenSwitched = #False
    ExamineMouse()
  ElseIf IsWindowActive() = #True And ScreenSwitched = #True
    ScreenSwitched = #False
  Else
    ScreenSwitched = #True
  EndIf
  
  Select WindowEvent()
    Case #PB_Event_CloseWindow
      End
  EndSelect
  
ForEver

End

kann das sonst noch jemand in der form reproduzieren?? bug nummer 1.), 2.) und 3.) sind ja bestätigt worden und wie bereits erwähnt 4.) und 7.) sind keine bugs (mein fehler, sorry), aber wie sieht es mit 5.), 6.) und nun der 8.) aus?? über feedback würde ich mich freuen, damit ich, oder jemand der besser englisch bzw. französisch spricht, dann fred einen ordentlichen bugreport abliefern kann.

c ya,
nco2k

Danilo · Beitrag von **Danilo** » 01.12.2004 11:10

nco2k hat geschrieben:bug nummer 8.)

wenn man im folgenden code (welcher InitMouse() : ExamineMouse() beinhaltet), auf ein darüber liegendes fenster wie z.b. dem debbuger klickt und anschliessend wieder auf diese anwendung, dann wird der mousecursor auf die letzte gespeicherte position zurückversetzt. das sollte fred irgendwie beheben/ändern. bei einem ego shooter wäre sowas tödlich.

Wieso sollte das tödlich sein? Es macht dort weiter wo es
aufgehört hat, und ist IMO OK so.
Für viele Spiele-Arten (inkl. EGO-Shooter) nimmt man auch
nicht die Mausposition X und Y, sondern die Bewegung seit
dem letzten Check. Siehe MouseDeltaX/Y.

nco2k hat geschrieben:ausserdem wird beim alt+tab taskswitch oder beim rechtsklick (kontextmenü) auf die anwendung in der taskleiste, die einschränkung des mousecursors nicht aufgehoben, es sei den man öffnet das startmenü mittels der win-tasten und geht ohne umwege direkt dorthin (zur taskleiste) und rechtsklickt die anwendung.

Kein Wunder bei Deinem Code. Schau Dir mal den Befehl
ReleaseMouse() an:

Code: Alles auswählen

Procedure IsWindowActive()
  If GetForegroundWindow_() = WindowID()
    Result = #True
  Else
    Result = #False
  EndIf
  ProcedureReturn Result.l
EndProcedure

If InitSprite() = 0 Or InitMouse() = 0
  End
EndIf

hWnd.l = OpenWindow(0, 0, 0, 800, 600, #PB_Window_SystemMenu | #PB_Window_ScreenCentered, "Test")
If OpenWindowedScreen(hWnd, 0, 0, WindowWidth(), WindowHeight(), 0, 0, 0) = 0
  End
EndIf

Repeat
 
  Delay(10)
 
  FlipBuffers()
  ClearScreen(0, 0, 0)
 
  StartDrawing(ScreenOutput())
    Circle(MouseX(),MouseY(), 16, RGB(255, 0, 0))
  StopDrawing()

  If IsWindowActive() = #True And ScreenSwitched = #False
    ExamineMouse()
  ElseIf IsWindowActive() = #True And ScreenSwitched = #True
    ScreenSwitched = #False
    ReleaseMouse(0)
  Else
    ScreenSwitched = #True
    ReleaseMouse(1)
  EndIf
 
  Select WindowEvent()
    Case #PB_Event_CloseWindow
      End
  EndSelect
 
ForEver

End

nco2k hat geschrieben:aber wie sieht es mit 5.), 6.) und nun der 8.) aus?? über
feedback würde ich mich freuen,

Entschuldige bitte wenn ich das so direkt sagen muß, aber
es sieht irgendwie so aus als wenn Du nicht richtig weißt
was Du da machst. Bist Du gerade auf einem Bug-Suche-Trip?

Das mit der ALT-Taste habe ich Dir schon gesagt. Das ein
ALT+Return mit SystemMenu nicht funktioniert, ist somit
auch sehr wahrscheinlich.
Bei Deinen letzten Codes verwendest Du überall das ALT
und hast Probleme damit.

Aber schau doch nur mal Deinen letzten Code an: Du öffnest
einen windowed Screen, zeichnest aber dann mit WindowOutput()
auf das Fenster, und nicht auf den Screen.

Weiterhin nimmst Du WindowMouseX() und WindowMouseY().
Diese beiden Befehle haben aber absolut nichts mit DX und
ExamineMouse() zu tun. ExamineMouse() fragt die aktuellen
Koordinaten für MouseX/Y und MouseDeltaX/Y ab.

In Deinen ganzen "Bug-Reports" mixt Du API und PB-Befehle
auf eine komische Art.

Was sollen denn dauernd die vielen GetAsyncKeyState_()
ohne den Rückgabewert zu verwenden?
Bei Beispiel 5 ist es ganz schlimm:

Code: Alles auswählen

      GetAsyncKeyState_(#VK_TAB)
      GetAsyncKeyState_(#VK_F4)
      GetAsyncKeyState_(#VK_MENU)
      GetAsyncKeyState_(#VK_LWIN)
      GetAsyncKeyState_(#VK_RWIN)

Zu dem minimieren des Screens: Ein Screen hat kein SystemMenu.
Deshalb hat der Screen auch kein Fenster-Menu bei Rechtsklick
in der Taskbar.
Probier es mit einem Fenster ohne SystemMenu aus:
Da funktioniert es genauso. Da kein SystemMenu vorhanden
ist, wird nur das Fenster aktiviert.

Wenn Du im obigen Code zu einer anderen Anwendung wechselst
und danach in der Taskbar das Rechtsklick-Menu von "Test"
aufrufst, dann verschwindet der MouseCursor.
Warum? Ganz einfach: Bei diesem Rechtsklick wird das Fenster
schon aktiviert und nach vorne geholt, so daß sofort ExamineMouse()
aufgerufen wird, und den Cursor verschwinden lässt.
Mach nach dem ExamineMouse() ein Beep_(800,100) rein
und probier es aus.

Wenn Du die Windows-Tasten drückst und danach ESC, dann
geht das StartMenu wieder zu. Der Focus geht nicht zu Deinem
Fenster zurück, weil er noch immer auf dem StartMenu-Button
liegt. Wenn Du dann Return drückst, öffnet sich das StartMenu
wieder.

Zu Deinem:

Code: Alles auswählen

PostMessage_(GetWindow_(FindWindow_("Shell_TrayWnd", 0), #GW_CHILD), #WM_LBUTTONDOWN, 0, 0)

Nicht gerade die feine Art. Vor allem sendest Du nur das der
Button gedrückt wurde, nicht aber das loslassen danach.
Wenn man auf die Taskbar klickt und danach die Maus bewegt,
dann kann man die Taskbar in eine andere Ecke ziehen, solange
der MouseButton gedrückt ist.

Alles in allem sehe ich hier eigentlich keine Bugs. Du codest
einfach irgendwas zusammen wie es Dir gefällt, beachtest
aber dabei nicht wie Windows funktioniert (z.B. ALT-Taste,
StartMenu-Fokus usw.).
Es funktioniert dann nicht so wie Du es Dir wünschst, und Du
meinst jedesmal es ist ein PB-Bug.

Ich hab auch echt keine Lust alle paar Tage diese Codes
auszuprobieren, um Dir dann zu erklären wie Windows
funktioniert.
IMHO ist hier alles logisch erklärbar, und ich kann keine
Bugs sehen.

nco2k · Beitrag von **nco2k** » 01.12.2004 21:38

@Danilo

Entschuldige bitte wenn ich das so direkt sagen muß, aber
es sieht irgendwie so aus als wenn Du nicht richtig weißt
was Du da machst. Bist Du gerade auf einem Bug-Suche-Trip?

naja, eigentlich nicht... will halt nur sicher gehen.

Aber schau doch nur mal Deinen letzten Code an: Du öffnest
einen windowed Screen, zeichnest aber dann mit WindowOutput()
auf das Fenster, und nicht auf den Screen.

ich weiss, hätte aber auch nichts geändert. war nur ein beispiel.

Weiterhin nimmst Du WindowMouseX() und WindowMouseY().
Diese beiden Befehle haben aber absolut nichts mit DX und
ExamineMouse() zu tun. ExamineMouse() fragt die aktuellen
Koordinaten für MouseX/Y und MouseDeltaX/Y ab.

ich weiss, ich denke nur, daß wie du ja sagtest: " fragt die aktuellen
Koordinaten für MouseX/Y und MouseDeltaX/Y ab" und diese eben auch nur abfragt, aber selber nicht setzt. egal ob man MousX/Y verwendet oder WindowMouseX/Y oder sogar garnichts. war nur ein beispiel.

In Deinen ganzen "Bug-Reports" mixt Du API und PB-Befehle
auf eine komische Art.

das mach ich bewusst so, damit man dann nicht sagen kann, vielleicht liegt es an was anderem. deswegen hab ich es aufs minimum reduziert, auch wenns unschön aussieht, kein mensch codet so, ist schon klar.

Was sollen denn dauernd die vielen GetAsyncKeyState_()
ohne den Rückgabewert zu verwenden?
Bei Beispiel 5 ist es ganz schlimm:

ist nicht mein code, hab ich aus dem forum hier. das letztere soll angeblich dazu dienen, den tastaturpuffer zu leeren.

Wenn Du die Windows-Tasten drückst und danach ESC, dann
geht das StartMenu wieder zu. Der Focus geht nicht zu Deinem
Fenster zurück, weil er noch immer auf dem StartMenu-Button
liegt. Wenn Du dann Return drückst, öffnet sich das StartMenu
wieder.

hab ich auch aus dem alten forum, mehr stand da eben auch nicht drin. hab auch hier nochmal zweimal nachgefragt, aber keiner wusste/wollte helfen. ich weiss eben nicht, wie ich das machen soll.

Alles in allem sehe ich hier eigentlich keine Bugs. Du codest
einfach irgendwas zusammen wie es Dir gefällt, beachtest
aber dabei nicht wie Windows funktioniert (z.B. ALT-Taste,
StartMenu-Fokus usw.).
Es funktioniert dann nicht so wie Du es Dir wünschst, und Du
meinst jedesmal es ist ein PB-Bug.

deswegen ist das forum da, um nachzufragen was da nun schiefgelaufen ist. ich kann auch nicht alles wissen, was ich nun selber manuell machen muss und was pb automatisch für mich übernimmt.

Ich hab auch echt keine Lust alle paar Tage diese Codes
auszuprobieren, um Dir dann zu erklären wie Windows
funktioniert.

musst du doch auch nicht.

c ya,
nco2k

Andre · Beitrag von **Andre** » 02.12.2004 01:34

@nco2k: Danilo hat es schon angesprochen und Du hast es schon (teilweise?) eingesehen. => Täglich erscheinende + durchnummerierte Bug-Reports (die Du dann teilweise nach kurzer Zeit wieder zurücknimmst) mit nahezu gleichem (+ fraglichem) Code bringen nicht viel, denn dafür Bug-Reports an Fred zu schreiben und diesen nachsehen zu lassen kann dann nicht Sinn und Zweck der Sache sein.

Wirklich relevante Dinge lassen sich in einem kurzen Beispielcode klar + präzise auch von anderen Usern nachvollziehen, und ein evtl. Bug wird dann auch nach Möglichkeit kurzfristig bereinigt.

Jsut my 2 cents.

nco2k · Beitrag von **nco2k** » 03.12.2004 07:56

vielleicht hätte ich mich auch nur einfach anders ausdrücken und den thread "Feature Requests" nennen sollen?!

ich möchte noch folgendes loswerden bzw. umformulieren und sorry falls ich mich wiederhole, aber ich habe es stark verkürzt:

ExamineKeyboard() funktioniert nur in zusammenhang mit einem OpenScreen oder OpenWindowedScreen() was auch lögisch ist, aber bei einem screenswitch, wo ein screen geschlossen und ein anderer geöffnet wird, funktioniert ExamineKeyboard() nicht da ja der screen fehlt. wenn man nun eine taste oder eine tastenkombination in der zwischenzeit gehalten hat, muss man diese erst loslassen und wieder drücken um ein erneutes ereignis zurück zu bekommen. das sollte imho geändert werden. ist eben nur meine meinung gewesen.

ExamineMouse() setzt den cursor auf die letzte bekannte position. wenn ich mich z.b. jetzt im hauptmenü meines spieles befinde (wo unten ein exit button und oben ein spiel starten button steht) mit dem cursor auf den exit button gehe, diesen aber nicht drücke sondern einen taskswitch mache und anschließend auf den spiel starten button gehe und den mouse button drücke, springt mein cursor auf die letzte position (exit button) und führt diesen dann auch ggf. aus. auch das sollte imho geändert werden. ist aber eben auch nur meine meinung gewesen.

so ziemlich jedes spiel welches mir bekannt ist, lässt sich minimieren, in der taskswitch-liste auswählen und im kontextmenü schließen bzw. wiederherstellen. warum ist es bei pb spielen nicht so?? mir ist schon klar, dass ein screen kein systemmenü hat, aber wieso haben es die anderen spiele dann?? benützen die dort etwa immer ein pseudo-fenster oder was ist das geheimnis?! sollte pb das dann auch nicht so automatisch machen??

warum das mit dem startmenü und fokus so ist, wie es ist, weiß ich auch. ich habe jedoch, schon mehrmals im forum um hilfe gebeten, jedoch konnte oder wollte wohl keiner helfen. ich weiß einfach nicht wie ich das machen soll, vor allem da ich mich mit WinAPI sehr sehr wenig auskenne.

sorry, falls ich mich in einigen punkten geirrt hab, wenigstens gebe ich es offen und ehrlich zu und entschuldige mich auch dafür und vielleicht war es auch wirklich egoistisch von mir, aber ich fand nun mal dass sich eine programmiersprache, automatisch um das hier genannte kümmern sollte. ich wollte auch nicht den anschein erwecken, dass ich pb die ganze schuld geben will, für alles was nicht so läuft wie ich es gerne hätte. deswegen habe ich ja auch hier im forum gepostet um zu hören, was andere user dazu sagen und anschließend, sofern wirklich ein bug vorliegt (und erst dann), diesen an fred weiter zu leiten. aber gut, dann lasse ich das einfach in zukunft und nerv euch nicht mehr.

ich verwende meistens codes aus dem forum oder aus dem archiv und vertraue darauf, dass der coder wusste was er da tut und dann werde ich dafür verantwortlich gemacht, wenn es schlecht oder unvollständig gecodet wurde. es gibt eben doch noch anfänger (wie meine wenigkeit) die noch nie im leben programmiert haben, es gerne lernen würden und sich nun an pb versuchen.

falls jemand weiß wie man das hier genannte, manuell lösen kann, dann möge er oder sie, es mir bitte bitte verraten. ich will doch wirklich nicht viel, sondern eben nur die "basics" und ich weiß auch nicht wo ich sonst nachfragen soll, außer in diesem forum hier. leider ist die pb community sehr klein. vielleicht ändert sich das ganze nächstes jahr, hoffen wirs zumindest.

p.s.: könnte einer von den mods diesen thread in den mülleimer verschieben?? danke.

c ya,
nco2k