PureBoard

Verfasst: **09.07.2007 20:40**

Hier eine etwas einfachere methode.

If OpenPreferences(#PB_Compiler_Home + "PureBasic.prefs")
  If PreferenceGroup("Global")
    Result.l = ReadPreferenceLong("TabLength",1)
  EndIf
  ClosePreferences()
EndIf

Debug Result

EDIT

Mist, TS war schneller.

Verfasst: **09.07.2007 22:29**

ts-soft hat geschrieben:@D@nte
So ist wohl schneller und einfacher
Code: Alles auswählen
If OpenPreferences(#PB_Compiler_Home + "PureBasic.prefs")
  PreferenceGroup("Global")
  tablength = ReadPreferenceLong("TabLength", 2)
  ClosePreferences()
EndIf
Funktioniert aber nur bis PB4.02! Wegen des Pfades

Danke TS-Soft.
Allerdings muss es heißen:

Code: Alles auswählen

If OpenPreferences(GetEnvironmentVariable("HOME")+"/" + ".purebasic.prefs")
  If PreferenceGroup("Global")
    TabLength = ReadPreferenceLong("TabLength",1)
  EndIf
  ClosePreferences()
EndIf

Unter dem Pfad #PB-Compiler_Home liegt die Default-pref, die Pref-Datei, die erzeugt wird, wenn ich die Einstellungen vorgenommen habe, liegt im "HOME"-Verzeichnis. Hat mich einiges an Sucharbeit gekostet.
Zudem ist das eine Systemdatei und unsichtbar, also muss der Punkt davor!
So ist das richtig auf dem Mac. Andere OSes-Abfragen müssen halt mit CompilerIF entsprechend eingebaut werden.
Aber so funktioniert das Snippet gut. Ich hab es nur noch nicht eingebaut.

Verfasst: **09.07.2007 22:43**

al90 hat geschrieben:
michel51 hat geschrieben:
Ausserdem habe ich nach dem Start (Button) nur noch Buchstabensalat auf dem Desktop, der erst verschwindet, wenn ich die Anwendung schließe.
Ich schätze mal das es an den Flags von RunProgram() liegt ? (Nicht getestet)
Das von dir beschriebene phänomen tritt normalerweise immer dann auf,
wenn eine gestartete Anwendung mit dem Flag '#PB_Program_Wait'
versehen wird.

Die Flags bei RunProgram sind "0". Ich denke, das hat einen anderen Grund.
Ich habe mir mal einen Messagerequester vor Break eingebaut und einen weiter hinten.
Den ersten kann ich noch lesen, da ist alles in Ordnung.
Mit dem Aussprung aus der Schleife durch Break wird jeder 2. Buchstabe aller Text verschluckt. Schon vor dem Label "Umschreiben" ist das der Fall. Muss also andere Gründe haben. Vielleicht wird irgend etwas nicht richtig geschlossen durch das Break ..?

Verfasst: **10.07.2007 22:22**

@michel51

Hast recht. Das Flag ist "0". Hatte garnicht so drauf geachtet. Keine ahnung
warum es bei dir diese gfx fehler gibt. Konnte bei mir bislang nichts feststellen.
Ich hatte es allerdings nur kurz mit einem dreizeiler getestet und nicht
mit grösseren projekten.

Vielleicht wird irgend etwas nicht richtig geschlossen durch das Break ..?

Schon möglich. Wie gesagt hatte ich mir den code nur grob angeschaut. Vielleicht kann
@Stargate mehr dazu sagen, da er seinen code besser kennt als ich. Ich habe
ehrlich gesagt auch keine grosse lust mehr näher darauf einzugehen. (u.a. auch wegen zeitmangel

)

Verfasst: **11.07.2007 19:51**

Hallo STARGÅTE,
habe deinen Code nun zum Laufen gebracht und will ihn demnächst hier posten.
Habe nur noch 2 Fragen
1. Wofür dient dieser Teil?

Code: Alles auswählen

    If Random(10) :
     Loc = Int(Loc()/Lof()*290)
     SetGadgetState(4, Loc)
     WindowEvent()
    EndIf

Und das 2.

Code: Alles auswählen

   F = MessageRequester("Info", "Datei wurde erfolgreich bearbeitet."+Chr(10)+"Datei jetzt öffnen ?", #PB_MessageRequester_YesNo) 
   If F = 6
    RunProgram(FileName$+".pb", "", 0)
   EndIf

Soll hier der geänderte Code in den Editor geladen werden um ihn anzuzeigen?
RunProgram startet aber nur executables...
Die anderen Probleme sind gelöst und ich hoffe, es ist sogar plattformübergreifend.

Verfasst: **11.07.2007 20:32**

Mit RunProgram lassen sich alle Dateitypen starten. Somit also auch .pb Dateien.
Man sollte aber beachten das man mit RunProgram nicht jaPBe starten kann.
Dazu kann man alternativ

ShellExecute_(0, 0, File$, Parameter$, DefaultPath$, #SW_SHOWNORMAL)

benutzen.

Verfasst: **11.07.2007 22:32**

al90 hat geschrieben:Mit RunProgram lassen sich alle Dateitypen starten. Somit also auch .pb Dateien.

Wirklich? Aber bei der Zeile

Code: Alles auswählen

F = MessageRequester("Info", "Datei wurde erfolgreich bearbeitet."+Chr(10)+"Datei jetzt oeffnen ?", #PB_MessageRequester_YesNo)
      If F = #PB_MessageRequester_Yes
         RunProgram(FileName.s+".pb", "",GetPathPart(FileName.s+".pb"),0)
;          RunProgram(FileName.s+".pb", "",0)
      EndIf
   EndIf

tut sich nichts. Ich denke, dass die geänderte Datei zunächst ja mal in den Editor geladen werden muss bzw. soll, um sie anzuzeigen.
Dass ich einen Code mit Einrücken lesbarer mache, heisst doch aber nicht, dass ich ihn gleich ausführen will.
Vielleicht denke ich aber auch daneben..

Aaahh.., gerade fällt mir ein, das direkte Starten einer .pb Datei (Doppelklick) mit gleichzeitigem Öffnen von Purebasic funktioniert auf (meinem) Mac nicht. Weiss aber noch nicht warum.

Kennst du eine Methode, wie man den geänderten Code (also "Filename.pb.pb") in den Editor laden kann zum anzeigen?

Verfasst: **11.07.2007 22:34**

Code: Alles auswählen

     Loc = Int(Loc()/Lof()*290)

Loc() ist die Location des Lese-Pointers
Lof() ist die länge des geöffneten files
ich wette, 290 ist die breite des gadgets.

also überleg mal, was das wohl tut, einfachste mathe...

...funktioniert das überhaupt zuverlässig?

wenn die rückgabe von Loc() und Lof() integer sind, könnte da erstmal NULL rauskommen,
bevor es mit 290 multipliziert wird.
ich würde die 290 an den anfang der berechnung stellen...

...oder bewirkt Int() einen Float-Cast auf seine Argumente?
..die internen on-the-fly typecasts von PB sind ein buch mit sieben siegeln...

Verfasst: **11.07.2007 23:17**

Kaeru Gaman hat geschrieben: Loc() ist die Location des Lese-Pointers
Lof() ist die länge des geöffneten files
ich wette, 290 ist die breite des gadgets.

also überleg mal, was das wohl tut, einfachste mathe...

Dass das zum Vorbelegen des Prozessbargadgets dienen soll, ist klar.
Und Grundschulmathe sollte eigentlich jeder kennen und können. Ich jedenfalls tue das.

Aber wofür dient das Random(10) und das WindowEvent() ?
Das war die eigentliche Frage, hab mich wohl ungeschickt ausgedrückt.

...funktioniert das überhaupt zuverlässig?

Das ist die entscheidende Frage.

Ich glaube auch, dass die Berechnung auf dem Mac nicht so funktioniert. Wenn ich mich recht erinnere, ist der Int()-Befehl buggy.

Edit Hab die Berechnung eben noch mal getestet. Int() scheint tatsächlich buggy zu sein (s. unten)
Aber mit

Code: Alles auswählen

Loc.l = 290*Loc(1)/Lof(1)

läuft der Prozessbalken.

..die internen on-the-fly typecasts von PB sind ein buch mit sieben siegeln...

Da hörst du keinen Widerspruch

Verfasst: **11.07.2007 23:32**

> Aber wofür dient das Random(10) und das WindowEvent() ?

also, beim Random muss ich raten:
er wollte keinen counter einbaun für "jedes zehnte mal".

das WindowEvent soll wohl dazu dienen, die änderung in der anzeige sofort umzusetzen.
ist aber verdammt unsauber.
klar, SetGadgetState erzeugt ein event und schiebts in die queue,
und ein einzelnes WindowEvent() holt ein event von der queue und verwirft es (der rückgabewert wird ja nicht ausgewertet),
aber wenn da zufällig noch ein anderes event in der queue war, verwirfst du das falsche.

besser weglassen.

.....ich hab mir auch nicht den kompletten code durchgelesen,
war nur aktuell auf deine frage angesprungen.

wenn es innerhalb einer normalen eventschleife liegt, wird die aktualisierung ja beim nächsten durchlauf ausgeführt.
ich würde es also so schreiben:

Code: Alles auswählen

    ActCount +1
    If ActCount > 10
     ActCount = 0
     Loc = Int(Loc()/Lof()*290)
     SetGadgetState(4, Loc)
    EndIf

das ist so schon ok, weil das aktualisierung-event nur jeden zehnten durchlauf erzeugt wird.
man muss vorsichtig sein, nicht in jedem durchlauf solche events zu erzeugen, weil sonst die queue überläuft.

noch eleganter ist es, das WaitWindowEvent mit einem timeout zu versehen,
und nur, wenn die schleife wegen des timeouts durchlaufen wird,
(also die rückgabe von WaitWindowEvent = 0 ist)
die aktualisierung auszulösen.

PureBoard

Automatische Einrücküberarbeitung