PureBoard

Hallo zusammen hier bin ich schon wieder habe es versucht mit dem Zeitmesen, aber irgendwie werde ich nicht schlau.
Ich habe es geschaf das wenn ich Enter drücke die aktuelle Zeit nachgeführt wird. Aber eigentlich möchte ich das unten im Fenster die Zeit laufend mit läuft, wie mache ich dass am Besten, ich habe es in der Repead schlaufe eingefügt, bekomme dort aber keine Werte zurück, wieso eigentlich.

hier der Code

Sorry ich muss was beim Compilieren falsch gemacht haben aufeinmal geht es, auch gut. Ich freu mich drüber

Hallo duli, ...
momentan funktioniert Dein Code zwar wie von Dir gewünscht, so ganz glücklich ist Deine Methode jedoch nicht gewählt.

Du wartest ja durch den Befehl "WaitWindowEvent()" auf einen Event - d.h. Dein Programm bleibt solange stehen, bis es einen Event bekommt und kann erst beim Erhalt eines Events weiterlaufen und wieder die Zeit aktualisieren.
Dies funktioniert bei Deinem Programm nun ausnahmsweise, da Du kein anderes Gadget als ein StringGadget einsetzt, welches den Focus erhalten könnte.
Die Besonderheit beim StringGadget ist, das es immer wieder beim Blinken des Cursors automatisch einen Event auslöst, solange es den Focus hat und somit Dein Programm alle x-Millisekunden wieder aus dem Wartezustand geholt wird.
Wenn Du nun jedoch noch ein anderes Gadget (z.B. einen Button) einbaust und diesen anklickst, so erhält dieser den Focus und Deine Zeit wird nicht mehr aktualisiert, da kein weiterer automatischer Event mehr stattfindet.

Wenn Du also soetwas wie eine Zeitanzeige permanent aktualisieren möchtest bieten sich hierfür eigentlich ideal Threads an.
In Deinem Fall bräuchtest Du nur eine kleine Prozedur zu erstellen, die dann z.B. so aussehen könnte: Bei einer Prozedur musst Du dann natürlich noch beachten, dass Du die darin benutzte Variable "t_start" entweder Global machst, als Shared definierst (wie im obigen Beispiel) oder eben diese nicht im Hauptprogramm sondern in der Prozedur selber definierst - an sonsten würde sie nicht im Gültigkeitsbereich dieser Prozedur liegen und somit nicht gefunden werden.

Anschließend brauchst Du dann Deine Prozedur nur noch als Thread zu starten und alles läuft von alleine ab - egal wie der Rest Deines Codes aussieht und egal was er tut. Grüße und weiterhin viel Erfolg mit PureBasic.

ich seh da aber ein kleines problem.
momanten scheint es zu funktionieren,
aber später könnte dir das noch kopfzerbrechen bereiten.

SetGadgetText erzeugt ein Event.
da du den befehl in jedem schleifendurchlauf ausführst,
erzeugst du in jedem schleifendurchlauf ein event.

jetzt hast du aber zu bestimmten anlässen weitere events,
nämlich, wenn der User etwas eingibt,
wenn deine Procedure FillGadget() ausgeführt wird (die erzeugt drei events),
usw.
dass bedeutet, du bekommst einen permanenten overhead an events,
du hast am ende immer mehr in der schlange stehen als du bearbeitet hast.
außerdem kommt deine schleife nicht zur ruhe, weil ständig events anstehen,
dein WaitWindowEvent kommt nie zum Warten.

------------------------------------------------------------------------
mein vorschlag ist jetzt folgender:
- du solltest eine bedingung einbaun, dass die zeitanzeige nicht permanent upgedated wird.
- du übergibst einen timerweit an den wartebefehl, damit die schleife garantiert regelmäßig bearbeitet wird.

vorher wurde sie nur deshalb ständig bearbeitet, weil überschüssige events erzeugt wurden.
aber um einen Timer anzeigen zu lassen, muss man schon laufend durchgehen.

PS:
@PureLust
entschuldige, würdest du die Spatzenkanone bitte wieder einstecken?
hier jetzt threads anzuwenden halte ich für unangemessen.
du weißt ganz genau, dass es schwierig ist, damit richtig umzugehen,
das halte ich für den moment für übertrieben.

außerdem ist es hier unnötig.
wenn schon nicht die einfache methode, dann wenigstens einen Callback und keinen thread.

du hast die eventerzeugung durch SetGadgetText völlig außer acht gelassen.
ich finde es mehr als gefährlich, ein Event in einem Thread zu erzeugen,
für eine Eventbearbeitung in der Hauptschleife.

also entschuldige, aber dein Vorschlag ist alles andere als empfehlenswert.


@Duli
das mit dem thread mach mal bitte nicht.
was threads sind und wie sie funktionieren, können wir uns ein andermal ansehen,
auch über Callbacks gibts es einiges zu lernen.
aber IMHO ist für den moment eine vernünftige, einfache Eventbearbeitung in der Hauptschleife angesagt.

Kaeru Gaman hat geschrieben:SetGadgetText erzeugt ein Event.

Was so jedoch nicht korrekt ist.
SetGadgetText() in ein TextGadget löst natürlich KEINEN Event aus und bringt somit auch nicht (wie von Dir falsch beschrieben) den Eventstack zum überlaufen.
Warum dulis Beispiel dennoch funktioniert und wodurch der Event ausgelöst wird: S.o.

PS:

Kaeru Gaman hat geschrieben:du hast die eventerzeugung durch SetGadgetText völlig außer acht gelassen.
ich finde es mehr als gefährlich, ein Event in einem Thread zu erzeugen,
für eine Eventbearbeitung in der Hauptschleife.

Das habe ich natürlich nicht - da hierbei (entgegen Deiner wiederholten und dennoch immer noch falschen Behauptung) keine Events durch SetGadgetText() ausgelöst werden und meines Erachtens nach ein Thread in diesem Fall sehr wohl angebracht ist, da es sich hierbei um eine absolut klassische Aufgabe für eine permanente Hintergrundausführung handelt welche hier sehr einfach und auch bereits für einen Laien recht ungefährlich durch einen Thread gelöst werden kann.

Greetz, PL.

@threads
ich halte es trotzdem für unsinn, hier jetzt threads einzubringen.
ich bezweifle, dass es Duli in der momentanen lernphase das geringste nützt.

> auch bereits für einen Laien recht ungefährlich durch einen Thread gelöst werden kann.
um gottes willen. threads sind nix für Laien.
aber ok, rate du zu was du willst, du wirst halt widerspruch ernten.


@Events
ok, dann bin ich vielleicht von einer falschen annahme ausgegangen.

dann ist aber SetGadgetText die Ausnahme.
es gibt andere Gadget-Zuweisungsbefehle, die ein Event erzeugen.
das war nämlich vor einiger zeit mal ein problem,
dass gadgets deswegen garnicht angezeigt wurden,
weil drei set-befehle in jedem schleifendurchlauf ausgeführt wurden.

> SetGadgetText() in ein TextGadget löst natürlich KEINEN Event aus und bringt somit auch nicht (wie von Dir falsch beschrieben) den Eventstack zum überlaufen.
wieso natürlich? die schlussfolgerung dass alle setbefehle ein event auslösen weil es viele tun ist legitim.

@Kaeru:
ich möchte mit Dir hier jetzt keine Grundsatzdiskussion über Sinn und Unsinn von Threads, Gott und die Welt oder sonstige Themen führen, auch wenn ich weiss, dass solche Diskussionen hier im Forum eine Deiner Lieblingsbeschäftigungen sind.

Ich finde es nur etwas verwunderlich, dass Du von einer funktionierenden Lösung abrätst und duli statt dessen selber einen mit Fehlern übersähten Vorschlag unterbreitest.
Ich glaube nicht, dass ihm damit wirklich geholfen ist.

Aber egal. Um nicht noch einen weiteren Thread hier im Forum durch ein Deiner Diskussionen in einem OffTopic-Thread enden zu lassen werde ich mich da jetzt mal raushalten und dulis Programmierkünste Deiner Obhut überlassen (es sei denn, duli selber möchte noch Näheres über die von mir vorgeschlagene Lösung bzw. die in Deiner Lösung enthaltenen Fehler erfahren).

In diesem Sinne ... PL.

einen mit Fehlern übersähten Vorschlag unterbreitest.

Es sei denn, duli selber möchte noch Näheres über die von mir vorgeschlagene Lösung bzw. die in Deiner Lösung enthaltenen Fehler erfahren.

wo bitteschön ist meine Lösung "falsch" oder "mit fehlern übersäht"?

und wo liegt der Sinn, einem Anfänger, der wirklich noch ganz andere Schwierigkeiten hat, nen Thread vorzuschlagen?
hast du jedes seiner bisherigen posts gelesen? auch das anderen topic?


und warum zum Geier wirst du so wunderbar unfreundlich?
und was soll PL heißen?

ach, EMS.... ich bin raus, macht euern scheiß doch alleine!

hallo Jungs (oder Mädels?)

Danke für euer Engagement, ja ich bin ein Anfänger, und bin froh für einfache Lösungen.

Auf jeden Fall habe ich echt noch nicht verstanden was ihr hier diskutiert. Ehrlich gesagt habe ich noch nicht mal ganz verstanden wie eine Prozedur so unabhänig läuft. Theoretisch weiss ich das die Werte inerhalb einer Prozedur isolliert bleiben, aber wieso der #True wert Z.B. gefühlt ist, keine Ahnung. Oder wieso inerhalb einer Prozedur Oberflächenelemente angesprochen werden können Zeitlich unabgänig von anderen Vorgängen, verstehe ich noch nicht. Also Ich bin wircklich ein Anfänger. Aber was ich super finde das hier wenn auch Leute verschiedener Meinung sind, ich brauchbare Lösungen so erklärt bekomme das ich es verstehe, und deswegen möchte ich euch beiden Danken. Und wenn ich das was ihr geschrieben habt wieder verdauen konnte und verstehe werde ich mich wieder melden und freue mich schon jetzt auf so tolle unterstützung wie jetzt.

Danke viel mals

duli hat geschrieben:(oder Mädels?).

... Treffer, ... versenkt. :

duli hat geschrieben:Auf jeden Fall habe ich echt noch nicht verstanden was ihr hier diskutiert.

Deswegen finde ich solche Diskussionen zwischen zwei Parteien innerhalb eines Threads ja auch so sinnlos. Sie gehen am eigentlichen Problem bzw. der Fragestellung meist komplett vorbei und dem Fragenden helfen solche Diskussionen in keinster Weise. Aber vielleicht kriegen wir das ja jetzt mal hin.

duli hat geschrieben:Ehrlich gesagt habe ich noch nicht mal ganz verstanden wie eine Prozedur so unabhänig läuft. Theoretisch weiss ich das die Werte inerhalb einer Prozedur isolliert bleiben, aber wieso der #True wert Z.B. gefühlt ist, keine Ahnung. Oder wieso inerhalb einer Prozedur Oberflächenelemente angesprochen werden können Zeitlich unabgänig von anderen Vorgängen, verstehe ich noch nicht.

Also das mit dem "zeitlich unabhähigen" Ablaufen ist natürlich keine Grundeigenschaft aller Prozeduren.
Ein solcher unabhängiger Ablauf betrifft im Grunde nur Sonderfälle wie z.B. CallBacks oder Threads.
Aber erst mal zu den etwas einfacheren Teilen Deiner Frage:

- Sinn und Zweck von Prozeduren sowie deren Gültigkeitsbereichen:
Stell Dir vor, Du entwickeltst ein Programm. Nun könntest Du ja alle benötigten Befehle einfach untereinander schreiben (und noch mit ein paar Sprungmarken versehen um im Code auch noch vor und zurück springen zu können).
Bei größeren Projekten hat man dann aber häufig den Fall, dass man ein und dieselbe Funktion oder Berechnung an verschiedenen Stellen ausführen müsste.
Im Grunde ja kein Problem - denn die Routine mit der gewünschten Berechnung könnte man ja einfach kopieren - was wohl auch funktionieren würde.
Komplizierter wird es dann, wenn Du nachher zu dem Schluß kommst, dass Du eben in diese Berechnung eine Änderung durchführen musst. Denn dann musst Du jede einzelne Stelle in Deinem Programm wiederfinden, wo Du diese Änderung durchführen musst.
Und genau da liegt dann das Problem, da schleichen sich dann leicht Fehler ein.

Wenn Du nun jedoch statt des Duplizierens diese Berechnung in eine Prozedur packst, welche Du dann eben einfach nur x-mal aus Deinem Programm aufrufst, so hast Du später nur eine einige Stelle (eben die Prozedur), die Du ändern müsstest und alle Aufrufe greifen dann automatisch auf diese veränderte Prozedur zu. Soweit einläuchtend, oder?

- Gültigkeitsbereiche von Variablen:
Der Gültigkeitsbereich - oder wie Du es nanntest, das "isoliert bleiben" von Werten (Variablen) - wurde mal eingeführt um Programme u.A. besser modular aufbauen zu können.
Stell Dir mal vor, Du und Dein Sohn würden zusammen ein Programm entwickeln. Du würdest (sagen wir mal) den Hauptteil davon schreiben und Dein Sohn einige Prozeduren dazu, welche Du dann aus Deinem großen Hauptteil aus aufrufst. (Hauptteil ist evtl. etwas unglücklich formiliert, aber ich hoffe Du weisst was ich damit meine.)
Du benutzt dann z.B. in dem von Dir entwickelten Teil ein paar der von Anfängern so beliebten Variablen x,y,z,n oder auch m. Genausogerne benutzt Dein Sohn aber eben auch genau diese Variablen in seinem Teil des Codes - nur eben für vollkommen unterschiedliche Zwecke.
Wenn man Eure beiden Teile dann also letztendlich zusammenführen würde, so wäre die Wahrscheinlichkeit groß, dass sich Variablen gleichen Namens in die Quere kommen können und es zu unvorhersehbaren Problemen kommen kann.

Aus diesem Grunde wurden mal die äusserst geniale Geschichte mit den Gültigkeitsbereichen von Variablen eingeführt.
So kann also der Gültigkeitsbereich einer Variable z.B. nur lokal (für das Hauptprogram oder eben NUR innerhalb einer Prozedur) oder eben auch global (verfügbar im gesamten Code) sein.
Im oben beschriebenen Fall wäre also eine von Dir ein Deinem Hauptteil benutzten Variable "X" nicht im gleichen Gültigkeitsbereich wie eine von Deinem Sohn in seiner Prozedur benutzte Variable "X" und würden sich somit auch nicht "beisses".
Für weitere Feinheiten zu Gültigkeitsbereichen schaust Du am Besten mal in der PB-Hilfe nach (z.B. unter Define, Global, Protected oder auch Shared) .

Bei dem von Dir angesprochene "Wert" #True handelt es sich nicht um eine "Variable" die ja wie gerade beschrieben einen Gültigkeitsbereich haben kann, sondern eine "Konstanten".
Konstanten sind im Grunde Platzhalter, die einen bestimmten Wert representieren. Konstanten werden beim Compilieren vom Compiler durch den jeweils dafür definierten Wert ersetzt werden.
Du kannst es Dir im Grunde wie bei einer Textverarbeitung vorstellen, bei der dann z.B. alle "#True" durch eine "1" ersetzt werden.

Somit ist es also im Grunde exakt das gleiche, ob Du nun "X = #True" oder "X = 1" schreibst.
Statt einer festen Zahl solche Konstanten zu nehmen hat z.B. den Vorteil, dass der Name einer Konstante viel aussagekräftiger ist als einfach nur eine Zahl.

Stell Dir vor, Dein Sohn hätte eine Prozedur für Euer Projekt geschrieben, bei der der Benutzer 3 Antwortmöglichkeiten hat: "Ja, Nein, Abbruch".
Seine Prozedur würde Dir dann als Wert die Zahlen 1,2 und 3 für die entsprechenden Antworten zurück liefern.
Nun würdest Du in Deinem Code dann also die Zahlen 1,2, und 3 auswerten:
Wenn RückgabeWert = 1 dann mach das, ...
wenn RückgabeWert = 2 dann mach das, ...
wenn RückgabeWert = 3 dann mach das ...
Die Chanche ist groß, dass Du in einigen Wochen nicht mehr auf Anhieb weisst, wofür die Zahlen 1,2,3 standen.

Wenn Ihr aber nun ein paar Konstanten diese Wert 1,2,3 zuweist und eben dann diese Konstanten in Eurem Code benutzt, so wird die Abfrage gleich viel leichter lesbar:

=> zuerst die Definition der Konstanten:
#Antwort_Ja = 1
#Antwort_Nein = 2
#Antwort_Abbruch = 3

Auswertung:
Wenn RückgabeWert = #Antwort_Ja dann mach das, ...
wenn RückgabeWert = #Antwort_Nein dann mach das, ...
wenn RückgabeWert = #Antwort_Abbruch dann mach das ...

Sieht doch schon mal etwas mehr selbsterklärend aus, oder?

Die Verwendung von Konstanten hat aber auch noch weitere, viel essentiellere Vorteile. Deren Erläuterung würde aber momentan wohl noch etwas zu weit gehen.
Wichtig für das Verständniss ist im Grunde, dass Konstanten Platzhalter für irgend etwas (Zahlen, Zeichen, Buchstaben) sind, und diese dann vom Compiler auch durch exakt diese Zahlen, Zeichen, Buchstaben ersetzt werden - egal wo sie stehen. Konstanten sind also global und representieren überall im Code den selben Wert.
Auch kann einer Konstante nur ein einziges Mal ein Wert zugewiesen werden, der dann eben konstant bleibt. Im Gegensatz zu einer Variable, deren Inhalt ja verändert werden kann - also variabel ist.

Ich schätze das war jetzt erst mal genug Tobak um Deine Gehirnwindungen zum Qualmen zu bringen.
Ich nehme mal an, dass es klar ist dass weder dieser Beitrag noch das gesamte Forum eine umfangreiche Einführung in die Programmiereung bieten kann und auch nicht alle Aspekte bis ins Detail behandelt werden können. Von daher wäre ein gutes Buch zum Thema "Einstieg in die Programmierung mit Basic" mit Sicherheit sehr hilfreich.
Wenn Du aber das o.g. mal verdaut hast und dann noch weitere Fragen zu "unabhängig laufenden" Prozeduren oder eben "Oberflächenelementen" hast, dann kann ich Dich da ja gerne nochmal mit einigen weiteren Ausführungen quälen.

So long und gutes Gelingen .... PL.