Konstanten in PB?

[Falko]

- Die OnError Konstanten sind für x64 und PPC CPUs und desshalb nicht in der x86-Version

Da viele x64 und x86 von einer IDE aus kompilieren, wäre es IMHO wünschenswert, wenn beide Varianten
im Strukture-Viewer vorhanden wären. Auch für das "Autovervollständigen".

Gruß
Thomas

Ich denke auch, das es so sein sollte, darum wäre es vielleicht besser das es hier auch ankommt
http://www.purebasic.fr/english/viewtop ... =4&t=44751

@all, probiert mal im Bezug Jens sein Codeschnipsel aus. Es geht hier speziell um das

#PB_EventType_Focus

Hier nochmal der Link zum Code:
http://www.jhc-software.de/Programme/Pu ... 8122010.pb

Früher hat ein Messagerequester diesen Focus-Event vernichtet. Aber in PB 4.51 geht das nun nicht mehr.
Als Notbremse ginge dann als Beispiel: SetActiveGadget(...), auf ein anderes Gadget, wo kein Focus abgefragt wird, zu setzen,
was eigentlich nicht die Lösung sein sollte.

Gruß Falko

[ts-soft]

Als Notbremse ginge dann als Beispiel: SetActiveGadget(...), auf ein anderes Gadget, wo kein Focus abgefragt wird, zu setzen,
was eigentlich nicht die Lösung sein sollte.

Gruß Falko

Warum nicht?

Ich würde das Gadget allerdings disablen und das Datum automatisch einfügen, warum soll man
den Knopf drücken, wenn man nichts ändern kann?

// edit: sehe gerade, da sind ja noch mehr solch komische Requester eingabaut.

[sharkpeter]

Hallo Thomas,

genau über so einen Kommentar hatte ich mit Falko gestern schon diskutiert.
Der beantwortet nämlich die Frage ganz und gar nicht. Es kann ja durchaus
auch sein, das ich einen Denkfehler habe und das in den "alten" PB Versionen
falsch gelöst war und jetzt korrigiert wurde. Als nächstes kommt dann gewiß,
dann lass doch den Quellcode in der PB-Version, mit der er erstellt wurde ...

Und genau deshalb habe ich oben hingeschrieben, das die Requester nicht
das Thema sind um die es geht, sondern der/die nur da sind damit man sieht
was passiert und eigentlich nicht passieren soll. Ich habe inzwischen ein
zweites Programm, bei dem ein ähnliches Problem auftritt, dort Färbe ich
diverse Sachen ein bzw. setze Rahmen, und auch da bleibt der dämliche
Focus drauf, so daß ich mir erst wieder was einfallen lassen muß, damit es
wieder so geht wie es soll respektive ich es mir vorstelle das es geht.

Wenn grundsätzliche Sachen geändert werden, also was weiß ich, irgendein
Parameter neu zu einer Funktion hinzukommt, merkt man es beim Start. Aber
so ein Kack, der bringt einen schier zur Verzweifelung, denn manchmal wirkt
sich sowas auch ganz anders aus, sprich das Programm schmiert ab ... Mit
anderen Worten: Man sollte doch einmal funktionierendes so lassen wie es
ist. Und wie gesagt, ich meine die dunkle Erinnerung sagt mir, ein ganz
ähnlich geartetes Problem gab es schon einmal ...

Gruß Jens

[ts-soft]

Wenn der Focus nach dem Requester wieder zum vorherigem Gadget geht, kann dies kein Bug sein.
Wenn es sich früher anders verhielt, dann war das vorherige Verhalten ein Bug, der wohl gefixt wurde.

Gruß
Thomas

[Falko]

Wenn der Focus nach dem Requester wieder zum vorherigem Gadget geht, kann dies kein Bug sein.
Wenn es sich früher anders verhielt, dann war das vorherige Verhalten ein Bug, der wohl gefixt wurde.

Gruß
Thomas

Bist du dir da so sicher?
Denn vorher war #PB_EventType_Focus = 256
und in der aktuellen PB-Version ist der 14000.

Also ich habe keine Bugmeldung darüber finden können. Ebenso steht auch nichts
darüber in der Historie das die Konstanten geändert wurden.

Ärgerlich, der mit den damals bugfreien PB-Releases plötzlich erfahren muss, da dieses
ein Bug war und evtl. sehr viele Zeilen dann ändern müsste. Denn ein Messagerequester ist eigentlich
auch nur ein Fenster und der Focus sollte dann verschwinden, dort auf das OK klickt.

Gruß Falko

[ts-soft]

Wenn A den Fokus hat, der MessageRequester beendet wird, hat selbstverständlich A immer noch den
Fokus. Wer oder was sollte das denn ändern?

Die Nummern sind mir z.B. egal, deshalb gibts ja Konstanten, damit sie einem egal sein können.

Ansonsten ist der Code von Peter einfach ein Design-Fehler. Wenn bestimmte Felder es erforderlich
machen, das bestimmte Felder bereits ausgefüllt sind, deaktiviert man diese Felder, bis dies geschehen
ist. Schon gibt es die ganze Problematik nicht. Ich glaub, ich weiß jetzt, warum mir diese Problematik nie
begegnet

Noch besser wäre es, die Abhängigkeiten über 2 oder 3 Tabs zu verteilen, so das man erst Wechseln kann,
wenn alle erforderlichen Daten vorhanden sind. Macht das ganze auch übersichtlicher.

Gruß
Thomas

[freak]

- Die OnError Konstanten sind für x64 und PPC CPUs und desshalb nicht in der x86-Version

Da viele x64 und x86 von einer IDE aus kompilieren, wäre es IMHO wünschenswert, wenn beide Varianten
im Strukture-Viewer vorhanden wären. Auch für das "Autovervollständigen".

Dann würden wir regelmäßig Bugreports bekommen von der Form "Die Autovervollständigung schlägt Konstanten vor die es gar nicht gibt!". Alleine das Vorhandensein in der Dokumentation führt ja scheinbar schon zu Verwirrung

Wenn grundsätzliche Sachen geändert werden, also was weiß ich, irgendein
Parameter neu zu einer Funktion hinzukommt, merkt man es beim Start. Aber
so ein Kack, der bringt einen schier zur Verzweifelung, denn manchmal wirkt
sich sowas auch ganz anders aus, sprich das Programm schmiert ab ... Mit
anderen Worten: Man sollte doch einmal funktionierendes so lassen wie es
ist. Und wie gesagt, ich meine die dunkle Erinnerung sagt mir, ein ganz
ähnlich geartetes Problem gab es schon einmal ...

Ist schon ein Kack wenn diese dämlichen Entwickler ihr Produkt weiterentwickeln oder einfach so grundlos Bugs beheben. Das sollte echt verboten werden!

Bist du dir da so sicher?
Denn vorher war #PB_EventType_Focus = 256
und in der aktuellen PB-Version ist der 14000.

Desshalb werwendet man Konstanten. Der Wert dahinter ist absolut unerheblich und kann nach Bedarf verändert werden.


Das aktuelle Verhalten des Codes ist absolut korrekt:
- das Gadget erhält #PB_EventType_Focus
- der Requester wird geöffnet => Das Gadget verliert den Fokus und erhält #PB_EventType_LostFocus
- der Requester wird geschlossen => Fokus geht zurück zum vorherigen Fenster/Gadget. Das Gadget erhält wieder #PB_EventType_Focus, weil es wieder den Fokus erhält.

Wenn eine ältere Version diesen Event unterschlagen hat dann war das ein Bug, weil das Gadget den Fokus erhalten hat ohne den dazugehörigen Event.

Ich halte die Vorgehensweise in diesem Code UserInterface-technisch für sehr bedenklich: Auf die Aktion des Users einem Gadget den Fokus zu geben damit zu reagieren den Fokus wieder zu entfernen (und sogar mit einem Requester zu stören) ist sehr verwirrend. Wenn ich mit der Tab-Taste von Gadget A zu Gadget C will und dabei zufällig bei Gadget B vorbei komme erwarte ich nicht, mit einem "freundlichen" Ding-Ton und einen Requester generft zu werden nur weil der Entwickler denkt ich will da was reinschreiben (was ich ja gar nicht vor habe). Wie ts-soft gesagt hat: Deaktivieren oder auf readonly setzen ist die korrekte Methode.

[Vera]

Hi sharkpeter,

ich hab mir Dein Beispiel auch mal angesehen und der Effekt mit der rekursiven Fokusschleife (böse Falle) taucht ab PB 4.50 auf.
Ich hatte den Code zuvor auch auf Linux getestet und kann Dir sagen, dass es sich dort auch schon bei 4.40 so verhält.

Das nach einer Meldung, der Fokus wieder auf die zuletzt aktive Position zurückgegeben wird, finde ich eigentlich naheliegend/folgerichtig, denn so könnte ich ja direkt, auf den Hinweis reagieren und eine Änderung vornehmen.
Möglicherweise macht Linux das automatisch und dieser 'Service-Mangel' wurde dann für WIN nachgereicht, um die Verhaltensweisen anzugleichen. Eine kleine, unwesentliche Verbesserung - gering erwähnenswert.

Sorry - das hilft Dir natürlich wenig, außer vielleicht, nicht weiter zu hoffen, dass das wieder rückgängig gemacht wird und sich mit dem Unausweichlichen abzufinden.

wünsche trotzdem einen heiteren Rutsch zu haben

Gruß ~ Vera

[sharkpeter]

@TS
"Ansonsten ist der Code von Peter einfach ein Design-Fehler. Wenn bestimmte ..."

- Darüber sollte sich keiner Gedanken machen, nimm es hin, es ist hier nur der Testcode.
Kannst dir ja das ganze Programm runterladen, dann siehst du auch, was dort in
Wirklichkeit gemacht wird. Meine Seite kennst du ja.

@Vera
"Sorry - das hilft Dir natürlich wenig, außer vielleicht, nicht weiter zu hoffen, dass
das wieder rückgängig gemacht wird und sich mit dem Unausweichlichen abzufinden."

- Auch darum geht es nicht, sondern nur um das Warum.

@Timo
"Ist schon ein Kack wenn diese dämlichen Entwickler ihr Produkt weiterentwickeln oder
einfach so grundlos Bugs beheben. Das sollte echt verboten werden!" Da hast du wohl
was Mißverstanden. Wenn dem so ist, das ein Bug beseitigt wird, so sollte man das auch
erwähnen, vielleicht als Klitze-Kleine-Homage an die, die mit der Entwicklungsumbebung
umgehen. Aber da steht dann nur da (V4.50: -repariert: So einige Bugs in den Libraries
und im Compiler). Es geht ja nicht um die Tatsache, DAS etwas gemacht wird, sondern
das man nicht bei jeder Entwicklungsumgebungsumstellung suchen muß wie ein Depp,
was da vielleicht wieder anders geworden ist. Dabei ist es prizipiell auch erst einmal
vollkommen Wurst, ob ein Bug beseitigt oder was grundsätzliches geändert wurde.
Ich will mit meinen Projekten weiterkommen und nicht Wochenlang im Kreis laufen.
Sicher kann es dabei auch sein, das ein durch einen Bug oder wie auch immer man so
etwas nennen möchte Fehler in der Gestaltung des eigenen Quellcodes entstehen.

Du, es ist wie in vielen Firmen, könnte Arien singen davon (Nur ein Beispiel: NC-Steuerungen
eines namhaften Herstellers mit Sitz in München und Berlin) ...

Und nun noch mal zum Problem:

Der Debugger unterstützt meine Theorie:

PB 4.51
reingeklickt 1.Durchlauf: WI=13100, ET=256 (?)
2.Durchlauf: WI=13100 ET=14000 Gadget bekommt Focus
Req. bestätigt 3.Durchlauf: WI=13100 ET=14001 (!!!) Gadget verliert Focus
4. Druchlauf: WI=13100 ET=14000 (WARUM?)

Bei allen anderen (4.0, 4.01, 4.02, 4.10, 4.20, 4.3x, 4.4x) von mir getesteten PB-Versionen
fehlt der 3. und 4. Durchlauf nach dem Klick auf den Requester!
Und bei 3.94 sogar der 1. Durchlauf, da beginnt es mit dem 2.

Gruß Jens

[sharkpeter]

Hallo noch mal zum gleichen Thema hier ein Quellcode:

Code: Alles auswählen

; Testprogramm

OpenWindow  (1,  0,  0,300,200,"Test")
StringGadget(0, 10, 10,280, 20,"")
StringGadget(1, 10, 40,280, 20,"")
StringGadget(2,400,400,280, 20,"Ich bin außerhalb, damit man mich nicht sieht ...")

Repeat
  eventid.l=WaitWindowEvent()
  eventtp.l=EventType()
  actgd.l  =GetActiveGadget()
  Select eventid
    Case #PB_Event_CloseWindow
      Quit=#True
    Case #PB_Event_Gadget
      Select EventGadget()
        Case 0
          Debug "neuer Durchlauf String 0"
          Select eventtp
            Case #PB_EventType_Focus
              ;If actgd=0
                Debug "String 0 hat den Focus erhalten"
                OpenFileRequester("test string 0","c:\","*.*|*.*",0)
              ;  SetActiveGadget(2)
              ;EndIf
            Case #PB_EventType_LostFocus
              Debug "String 0 hat den Focus verloren"
          EndSelect
        Case 1
          Debug "neuer Durchlauf String 1"
          Select eventtp
            Case #PB_EventType_Focus
              ;If actgd=1
                Debug "String 1 hat den Focus erhalten"
                OpenFileRequester("test string 1","c:\","*.*|*.*",0)
              ;  SetActiveGadget(2)
              ;EndIf
            Case #PB_EventType_LostFocus
              Debug "String 1 hat den Focus verloren"
          EndSelect
      EndSelect
  EndSelect
Until Quit

End

Und jetzt sag mir mal einer was das soll, erst wird der Focus weggenommen und dann
kommt er wieder. Und ich frage mich, das soll richtig sein?

Erst einmal so starten wie es ist und dann einfach einmal die auskommentierten Sätze
aktivieren, und schon geht es. Aber man muß ein zusätzliches Gadget erzeugen, so ein
Quatsch.

Gruß Jens