RSBasic hat geschrieben:
N00B hat geschrieben:Code [...] verwendet WinAPI Zeug
N00B hat geschrieben:Mein Code braucht keine WinAPI
Ich wiederhole mich zwar ungern, aber was ist denn so schlimm an WinAPI, wenn deine Anwendung eh nur auf Windows laufen kann, weil du MDIGadget() benutzt? Wenn du plattformunabhängig programmieren möchtest, dann darfst du erst gar nicht MDIGadget() verwenden oder du musst was eigenes bauen oder eine Lösung für Linux und/oder MacOS finden, wenn du diese Betriebssysteme ebenfalls unterstützen möchtest.
Weil etwas in einer Version von Windows funzen kann, und in der nächsten schon nicht mehr.
z.B GetKeyAsyncState, oder ne Anwendung per Sendmessage (oder war es Postmessage ?) zu beenden.
Wegen Vista/W7 (ist für mich das selbe) hab ich API Code zum beenden einer Anwendung (nicht abschiessen, sondern sauberes beenden) an die Methode die ab Vista >ausschliesslich< verwendet wird (XP kann auch ne andere)
anpassen müssen.
Wenn es PB interne Befehle sind, dann kann ich mich auf die Funktionalität auch in Zukunft verlassen.
Wieso wurde wohl in all den Jahren nicht die Möglichkeit eingebaut, daß einem Editor Gadget ohne
API ein Kontextmenü hinzugefügt werden kann ? (es ist doch so banal und so nützlich ! Ich habe noch
nie irgendwas gesehen das in C oder sonst was geschrieben ist, wo es keine Copy und Select in nem Editor Gadget gibt)
Bestimmt weil die eine Windows Version es so braucht, die andere wieder so usw
Ausserdem sollte doch Code geposted werden im Anfänger Forum der Einfach zu verstehen ist, aber die API und vor allem
Pointer sind am Anfang nicht so einfach zu verstehen.
RSBasic hat geschrieben:
N00B hat geschrieben:versuch mal nenn Prozess per API ab Vista so zu beenden wie unter XP, geht nicht mehr, da braucht mann Code der für beides geht. (kann es bei Gelegenheit rauskrammen)
Was heißt für dich beenden? Ich kenn zwar dein Code nicht, aber du meinst sicherlich nicht killen/abschießen oder? Deinen Code möchte ich gerne sehen. Vielleicht kann ich dir ja helfen, falls du mit dem Code, den du hast, nicht zufrieden bist.
Ne ich meinse nicht abschießen, ich meinte sauberes beenden, ich hab ne Gui für JohnTheRipper (JtR) geschrieben, die JtR steuert, und bei Bedarf das Shell Fenster automatisch schliesst (kein Taskkill, sondern ein Close Event)
Und unter XP ging es hervoragend, und unter Vista b.z.w W7 ging es nicht, musste erst ewig auf MSDN rumsuchen und rumprobieren und entsprechend anpassen.
RSBasic hat geschrieben:
N00B hat geschrieben:flackern tut es nur deswegen, weil der 0815 User nicht diese dämmlichen Animationen beim Maximieren & Minimieren abstellt.
Das Problem liegt nicht bei der Animation von Windows, sondern es hat eher was mit deiner Vorgehensweise zu tun. Du kannst deswegen nicht von jedem User verlangen, dass er diese Animationseinstellung fürs Minimieren und Maximieren deaktiviert, wenn er flackerfrei deine Anwendung nutzen möchte. Es ist eher die Aufgabe der Anwendung. Wenn die Anwendung ein Problem damit hat, dann musst du es so machen, damit das Problem nicht erst entsteht, aber auf eine externe Lösung zuzugreifen, die außerhalb deines Anwendungsbereichs liegt, ist eine schlechte Idee.
Ich hab den Code in ca 10 Min geschrieben, und dafür ist er ganz ok.
Und für mich liegt das Prob an Windows, den der Code tut was er soll.
Verlangt wurde etwas das die >Größe immer anpasst, unter gewissen Umständen< und das hab ich geliefert (ohne API, kann sein das es mit der API ohne flimmern geht, aber ich setz mich bestimmt keine 50000000 Stunden dran, rauszufinden wie !)
es hies nicht >nachdem die Größe durch Autosize angepasst wurde muss schon der blose Versuch vom User unterbunden werden (also den #PB_Window_SizeGadget Flag entfernen nach dem Resize, was natürlich viel schlauer und eleganter ist)
RSBasic hat geschrieben:
N00B hat geschrieben:So und jetzt muss ich los in meine Spätschicht.
Viel Spaß beim Arbeiten. Oh apropos Arbeit, ich muss auch mal wieder, Pause vorbei.

Danke aber Spass war das bestimmt nicht, eher ne Tortur, hab jeden Tag woanders schmerzen, mal Nacken, mal Schultern, mal Rücken, mal Steisbein.
---------------
NicTheQuick hat geschrieben:
N00B hat geschrieben:1. Mein Code ist viiiiiiiiiiiiiiiiiiel kompakter und verständlicher, und sieht 100000 x besser aus, wenn ich das Case Zeugs schon sehe wird mir ganz schlecht.
Du hast echt Probleme. Jeder hat da seinen eigenen Geschmack. Ich mag z.B. Select-Case lieber, wenn eine Variable auf mehrere Werte überprüft werden soll. Deswegen behalte deine Meckerei doch einfach für dich. Zweitens ist das hier kein Wettbewerb bezüglich kompakten oder kurzen Codes, sondern wenn überhaupt sollen hier 100% korrekte Code erstellt werden, und wie lang die sind, hängt einfach davon ab, was eben nötig ist um ihn korrekt zu machen.
Ist kein Wettbewerb das stimmt, aber wenn es um Verständlichkeit geht, ist mein Code gut, und er funzt auch 100% korrekt
er tut genau das was er tun soll, alldergings so agressiv das es halt flimmern kann !
Und wenn Bisonte nicht so'n provozierendes Kommentar in seinem Code geposted hätte, währe ich auch nicht an die Decke !
NOOB's Beispiel mal etwas anders und ohne flackern inkl. 64Bit Test
Ich weiss : Bei 5.21 gehts doch mit Bind.... , bewusst drauf verzichtet, damit NOOB es auch testen kann
;:- Da kein OS genannt wurde, auf dem es lauffähig sein sollte,
;:- und N00B ein Beispiel gepostet hat, das eigentlich nur auf
;:- Windows läuft, hier eine Windows Variante, die nicht flackert.
;:- PB Version : 5.21 (sollte aber auch mit 4.6 funktionieren)
Mein's wurde unter 64Bit gestestet, aber nicht von mir (TS-Soft) aber beim ersten Code war das GetAsyncKeyState das Prob, und das hab ich rausgenommen und durch, AddKeyboardShortcut() ersetzt, und er meinte das GetAsyncKeyState ist das
Prob gewesen, daß es total gesponnen hat, da ich den Code angepasst habe ohne API, muss er jetzt auch unter 64Bit Windows laufen, ohne abkacken oder Towuwabohu !
Aber nein, da wird behauptet es wurde kein OS genannt auf dem es lauffähig ist, ich hab über dem Code
geschrieben, daß es ohne Probleme ab Windows NT4 laufen sollte.
Schliesslich hab ich keine API Befehle drin, und in keinem der Befehle die ich verwende, heist es
"geht unter der und der Windows Version nicht"
NicTheQuick hat geschrieben:
N00B hat geschrieben:3. Mein Code funzt, und macht genau das was er machen soll, und flackern tut es nur deswegen, weil der 0815 User nicht diese dämmlichen Animationen beim Maximieren & Minimieren abstellt.
Und du findest wirklich immer noch, dass es darauf ankommt, dass ein Code bei dir läuft und alle anderen nur ihr Windows nicht nach deinem Geschmack eingerichtet haben? Es hat sich niemand nach dir zu richten. Und wenn du deine Programme so schreibst, dass sie nur bei dir korrekt und ohne Flackern oder ähnliches laufen, dann darfst du dich nicht wundern, wenn dir hier bestimmte User sagen, was du lieber an deinem Code ändern solltest, damit es auch bei anderen läuft.
Ich wiederhole mich noch mal.
Ich hab den Code in ca 10 Min geschrieben, und dafür ist er ganz ok.
Und für mich liegt das Prob an Windows, den der Code tut was er soll.
Verlangt wurde etwas das die >Größe immer anpasst, unter gewissen Umständen< und das hab ich geliefert (ohne API, kann sein das es mit der API ohne flimmern geht, aber ich setz mich bestimmt keine 50000000 Stunden dran, rauszufinden wie !)
es hies nicht >nachdem die Größe durch Autosize angepasst wurde muss schon der blose Versuch vom User unterbunden werden (also den #PB_Window_SizeGadget Flag entfernen nach dem Resize, was natürlich viel schlauer und eleganter ist)
--------------------
Bisonte hat geschrieben:
N00B hat geschrieben:Ja aber dein vermeintlicher Super Code der besser als meiner laufen soll, verwendet WinAPI Zeug, und da redest du von das sie besser auf jeder Variante laufen soll ?
So ein Schwachsinn !
Moment. Ich sagte nix von besser, höher oder Super... Einfach nur anders. Bezüglich deines ersten Codes... Da stand API drin. Also Windows.
Und wenn ich Windows nutze dann kann ich auch die API rauskramen und dann halt ohne flackern.
Ja desshalb haste auch in deinen Code diesen provozierenden Kommentar rein.
NOOB's Beispiel mal etwas anders und ohne flackern inkl. 64Bit Test
Ich weiss : Bei 5.21 gehts doch mit Bind.... , bewusst drauf verzichtet, damit NOOB es auch testen kann
;:- Da kein OS genannt wurde, auf dem es lauffähig sein sollte,
;:- und N00B ein Beispiel gepostet hat, das eigentlich nur auf
;:- Windows läuft, hier eine Windows Variante, die nicht flackert.
;:- PB Version : 5.21 (sollte aber auch mit 4.6 funktionieren)
Dein Kommentar erweckt den Anschein, als würde mein Code nicht machen was gefordert wurde, und würde nicht korrekt funzen, und auf jeglichem Windows ungestestet sein. Was einfach nicht stimmt !
Da brauchst dich nicht zu wundern wenn ich an die Decke gehe !
Der Code >muss< ab NT4 funzen. Keine API Befehle, keine Befehle wo es im Handbuch heist >erst ab Windows so und so<
Bisonte hat geschrieben:
N00B hat geschrieben:1. Mein Code ist viiiiiiiiiiiiiiiiiiel kompakter und verständlicher, und sieht 100000 x besser aus, wenn ich das Case Zeugs schon sehe wird mir ganz schlecht.
Geschmackssache.
Stimmt, aber er ist nun mal verständlicher für den Anfänger, und leichter zu integrieren in bestehenden Code.
Bisonte hat geschrieben:
N00B hat geschrieben:2. Mein Code braucht keine WinAPI, versuch mal nenn Prozess per API ab Vista so zu beenden wie unter XP, geht nicht mehr, da braucht mann Code der für beides geht. (kann es bei Gelegenheit rauskrammen)
GetAsync.... ist API, und das weitere wird in diesem Beispiel nicht gebraucht.
Und genau GetAsync hab ich ausgebaut ! Echt guck doch mal den Code an, den hab ich gestern Nacht modifieziert, ich hab
mir sogar die Mühe gemacht, Enable Explicit einzubauen, und das hat mich 5 Min meines Lebens gekostet -.-
Bisonte hat geschrieben:
N00B hat geschrieben:3. Mein Code funzt, und macht genau das was er machen soll, und flackern tut es nur deswegen, weil der 0815 User nicht diese dämmlichen Animationen beim Maximieren & Minimieren abstellt.
So und jetzt muss ich los in meine Spätschicht.
Und Du erwartest allen Ernstes, das ein User für dein Programm seine Windowseinstellungen ändert ???
Das ist definitiv nicht mein Kino...
Nein, er >kann< ihn ändern !
Es wurde ein Code gefordert, der sobald der User keine eigene Größe angibt, immer die Größe dynamisch anpasst, bei Größen Änderungsversuch ! Es hies >nicht< sobald er nicht ne Größe angegeben hat, wird bei dem Versuch, das #PB_Window_SizeGadget Flag entfernt, und >danach< angepasst !
So sollte es auch ohne Flimmern, und API krimskrams gehen. Die API ist was feines, aber sie hat auch ihre Nachteile, und kann ganz schön verwirrend sein für Anfänger.
EDIT:
Da jetzt flimmert nichts mehr ! Jetzt endlich zufrieden ? Na was gibt es jetzt noch dran auszusetzen ?

ich warte !
Hab nur ne lächerliche Kleinigkeit verändert, also war der Code an sich schon gut.
114 Zeilen Code, keine API, und getestet unter XP SP2, XP SP3 (in VirtualBox)
Code: Alles auswählen
EnableExplicit
Define MainWinH, MainWinW, Event, Menu, MenuEntry
Global AutoSize
; WIN
Enumeration
#MainWin
#MDI_Win
EndEnumeration
; GADGET
Enumeration
#Button
#MDI_GD
EndEnumeration
; MENU
Enumeration
#GDI_MENU
EndEnumeration
Procedure GetAndRunMenuEvents(Menu,MenuEntry)
; Menüs in der Titelleiste starten immer bei MenuEntry 0 das ist ganz normal
; Bei Kontextmenüs hingegen bei Menuentry 1
If Menu = #GDI_MENU
If MenuEntry = 1 : Debug "MenuEntry=1"
;KEINE AHNUNG WARUM ABER GetMenuItemState & SetMenuItemState brauchen
;MenuEntry=0 zum funzen, obwohl MenuEntry=1 abgefangen und an diese Procedure übergeben wird
If GetMenuItemState(#GDI_MENU,0)
Debug "DISABLE"
AutoSize = 0
SetMenuItemState(#GDI_MENU,0,0)
SetWindowTitle(#MainWin,"Autosize = OFF")
Else
Debug "ENABLE"
AutoSize = 1
SetMenuItemState(#GDI_MENU,0,1)
SetWindowTitle(#MainWin,"Autosize = ON")
EndIf
EndIf
EndIf
EndProcedure
MainWinW=600 : MainWinH=470
#FirstIDForGDI_Entry=70
OpenWindow(#MainWin,0,0,MainWinW,MainWinH,"Autosize = On",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
ButtonGadget(#Button,10,10,100,20,"Bla")
If CreateMenu(#MainWin,WindowID(#MainWin))
MenuTitle("Menu index 0")
MenuTitle("MDI windows menu")
MenuItem(0,"Autosize")
MDIGadget(#MDI_GD,10,40, MainWinW - 20, MainWinH - 70,1,#FirstIDForGDI_Entry)
AddGadgetItem(#MDI_GD,#MDI_Win,"child window")
UseGadgetList(WindowID(#MainWin))
EndIf
AddKeyboardShortcut(#MainWin,#PB_Shortcut_F1,1)
Menu = #GDI_MENU
SetMenuItemState(#GDI_MENU,0,1)
AutoSize = 1
; HideMenu(0,1) ; Würde ich benutzen, da Fenster Menüs hässlich sind :D
; Falls das Child Win Maximiert wird, landen die Buttons zum Minimieren,Maximieren & Schliessen
; auf die Titelleiste vom MainWindow, daß ist anscheinend normal.
; Macht nichts, denn durch Doppelklick auf die Fensterleiste vom MDI Window wird das MDI Fenster wieder
; auf seine normale Größe gebracht (oder halt maximiert je nachdem was gerade aktiv ist)
; und die Minimieren,Maximieren & Schliessen Buttons sind wieder beim MDI Window
Repeat
Event = WaitWindowEvent()
If Event = #PB_Event_SizeWindow
If AutoSize = 1
Debug "AUTOSIZE"
DisableWindow(#MDI_Win,1) : ResizeWindow(#MDI_Win,2,0,MainWinW - 37, MainWinH - 110) : DisableWindow(#MDI_Win,0)
EndIf
EndIf
If Event = #PB_Event_Gadget
Event = EventGadget()
If Event = #Button
Debug "Button"
EndIf
EndIf
If Event = #PB_Event_Menu
Debug "" : Debug "Menu ID="+Str(Menu)
MenuEntry = EventMenu()
Debug "Menu Entry="+Str(MenuEntry) : Debug "--------"
GetAndRunMenuEvents(Menu,MenuEntry)
Menu = #GDI_MENU ; Muss danach auf die ID des Titelleisten Menus vom jeweiligen Fenster (in diesem Fall ID1)
; zurückgestellt werden sonst wird permanent (aber nur für Menu Keyboard Events) die letzte benutze
; Menu ID eines Kontext Menü Events ausgegeben und der jeweilige
; Keyboard Shortcut führt das falsche Menü aus ! Da die Menu ID nicht stimmt.
EndIf
If Event = #PB_Event_CloseWindow
Break
EndIf
ForEver
EDIT2: Ich habe gerade nenn Fehler entdeckt in dem Code von einem Profi, und ich reite jetzt auch mal drauf rum, damit mann mal sieht wie das ist ! :p :p :p (normalerweise würde ich das nicht)
Einer der Codes der von den Profis hier, macht nicht das was er machen soll, wenn mann das Fenster Maximiert und Autosize on ist.
Mein Noob Code an dem ständig was ausgesetzt wird hingegen hält die Abstände auch beim maximieren ein, da wird nicht einfach das Fenster so maximiert, daß ein riesen Teil von, ausserhalb vom MDI landet, und das immer im selben Ausmass, egal wo das Fenster grade ist, und egal wie groß es zu dem Zeitpunkt war.