Müßte man mal schauen, ob es auch für Änderungen der Inhalte von Spalten eine Message gibt, wo man z.b. über UserMessages das automatisieren könnte. Klar, bei sehr vielen Gridbox-Einträgen wird das uninteressant. Aber bei Normalbenutzung, wie bei mir, ist es schon interessant. Und wenn es wirklich mal mehr Einträge gibt, hat man ja auch noch die Möglichkeit, bei dieser Aktion die Gridbox kurzzeitig auszublenden. Ist ja immer das Neuzeichnen, das aufhält.
Beiträge von H.Brill
-
-
Hallo Jens-Arne,
vielleicht wäre das ja auch ein Anlass für RGH, noch bestimmte Funktionen für die Gridbox einzubauen. Gerade das
~LVSCW_AUTOSIZE
wäre ja schon interessant. Sowas braucht man ja schon öfter.
-
Ja, danke Jens-Arne. Daß sowas ja auch geht, konnte ich mir denken, steht ja auch einiges in der Messages.ph.
Es ging mir eher um das obige Zitat aus der Hilfe. Da RGH ja das anbietet und die Werte aus der Datenbank-Tabelle übernimmt, sollte es auch richtig funktionieren.
-
Vielleicht noch was was von früher :
Wir Kinder hatten damals ja auch schon Antiwerbung für Zigaretten gemacht und gerne gewitzelt :
ZitatDer Pappa sitzt auf dem Toilettenrand und raucht die Peter Stuyvesant. Und das, was hinten runterfällt, das ist der Duft der großen weiten Welt.
oder
Siehst du die Gräber hier im Tal ? Das sind die ehemaligen Raucher der REVAL !
oder auch die
TOTHANDLE
-
Was ich noch anfügen möchte :
Sicherlich kann man diesen Umstand umgehen, wenn man die Ergebnisse von SQL("Exec",..) zuerst in die interne Listboxliste leitet und dann selber mit Move("ListToHandle",...) die Daten rüberschiebt. Aber da nun Roland es in der Hilfe ja bei SQL("Exec",...) anbietet
Zitat>2: Handelt es sich beim letzten Parameter um das Handle einer Gridbox, wird das Ergebnis in diese geschrieben, wobei die Spalten und Überschriften der Tabelle in die Gridbox übernommen werden.
sollte es aber auch richtig funktionieren. Normalerweise ist ja der XProfan-Programmierer beim Erstellen der Gridbox für seine Spaltendefinitionen verantwortlich. Er sollte ja sicherstellen, daß die Texte in die einzelnen Spalten auch reinpassen. Es kann ja auch Situationen geben, wo es beim XProfan-Programmierer gar nicht erwünscht ist, daß XProfan intern die Spaltengrößen ändert. Im übrigen brachte ein
bei SQLLITE auch nichts. Vielleicht wäre da ein Schalter angebracht :
Im Modus 0 wird dann nur in die Spalten der Gridbox geschrieben und im Modus 1 werden die Spaltenbreiten der Gridbox , wie bis jetzt gehabt, in Bezug auf die Datenbanktabelle, zusätzlich geändert. Vielleicht genügt ja auch ein zusätzlicher Modus (3) bei db("SQLEXec",..), der das Verhalten steuert.
-
Hallo,
da Roland hier (Zukunft XProfan) ja öfters vorbeischaut, schreibe ich es mal hier hin.
folgender Code :
Code
Alles anzeigenwindow 800,600 var handle sldll = db("slUseDLL", "SQLite3.DLL") var Handle grid = Create("GridBox", %HWnd, "", 0, 10, 10, 480, 150) var Handle lb = Create("Listbox", %HWnd, 0, 10, 200, 480, 150) var handle mydb = db("slInit", ":memory:") /* if db("slTableExists", mydb, "KUNDEN") db("slSQLExec", mydb, "DROP TABLE KUNDEN", 0) endif */ db("slSQLExec", mydb, "CREATE TABLE KUNDEN ( VORNAME CHAR(25), Name CHAR(25), GEBDAT DATE, GEHALT NUMERIC)", 0) db("slSQLExec", mydb, "INSERT INTO KUNDEN (Vorname,Name, GebDat, Gehalt) VALUES ('Hugo','Maier','25.06.1958',1234.56)",0) db("slSQLExec", mydb, "INSERT INTO KUNDEN (Vorname,Name, GebDat, Gehalt) VALUES ('Klara','Müller','13.02.1961',1654.32)",0) db("slSQLExec", mydb, "INSERT INTO KUNDEN (Vorname,Name, GebDat, Gehalt) VALUES ('Roland','Hülsmann','23.09.1955',3500.25)",0) db("slSQLExec", mydb, "INSERT INTO KUNDEN (Vorname,Name, GebDat, Gehalt) VALUES ('Heinz','Brill','04.01.1958',3200.55)",0) db("slSQLExec", mydb, "SELECT * from KUNDEN", grid) db("slSQLExec", mydb, "SELECT * from KUNDEN", lb) // Als XML 'set("SQLFile", "Adressen.xml") 'db("slSQLExec", mydb, "SELECT * from KUNDEN", 2) // Als JSON 'set("SQLFile", "Adressen.json") 'db("slSQLExec", mydb, "SELECT * from KUNDEN", 2) db("sldone", mydb) WaitEnd endMir ist aufgefallen, wenn man mit
die Ergebnisse in eine Gridbox schreibt, zeigt diese nicht alles ordnungsgemäß an, bzw. schneidet ein Teil ab. Sieht man hier bei den Spalten Name und GebDat. Da die untenstehende normale Listbox alles richtig anzeigt, gehe ich mal davon aus, daß bei der Berechnung der Spaltenbreiten etwas schief läuft. Auch die interne Listboxliste zeigt es richtig an. Habe es auch schon mit und ohne Spaltendefinitionen (bei Create("Gridbox",...)), versucht, ist aber auch da das gleiche Spiel. Ich habe es jetzt nur mit SQLLite getestet, denke aber daß es bei normalem SQL auch so ist. Vielleicht kann sich Roland das mal anschauen.
Mein Code zeigt auch, wie man mit SQLLITE eine Memory - DB anlegt. Diese existiert nur im Speicher und nicht physikalisch auf Datenträger. Ist evtl. auch ein Tipp, wie man die erweiterten Fähigkeiten von SELECT zusammen mit der WHERE Klausel auf eine Gridbox anwenden kann, indem man den Inhalt zuerst in die Memory-DB transferiert.. Die Memory-DB muß man natürlich zusammen mit der Gridbox pflegen.
-
Was vielleicht auch nicht jeder weiß :
Wie deckt man Zahlen- oder Buchstabenbereiche mit der Mehrfachabfrage Select...EndSelect ab ?
Wenn man da etliche Eingaben prüfen möchte, stößt man ja leicht mit der Aufzählungsform und Komma bei CaseOf 1, 2, 3 usw. schnell an die Grenzen, was die Schreibarbeit betrifft. Wenn man jetzt größere Bereiche von Zahlen oder auch von Buchstaben vom Alphabet überprüfen möchte, kann man sich auch die IF()-Funktion im Zusammenhang mit Between() oder Match$() zunutze machen :
Code
Alles anzeigenDeclare Long zahl, ende, p, String b Cls ende = 0 Print "Gib eine Zahl bis 499 ein. 0 = Ende" WhileNot ende Locate 2, 1 Print "Zahl : " Locate 2, 8 Print Space$(10) Locate 2, 8 Input zahl Select zahl CaseOf If(Between(zahl,1, 99) = 1, zahl, -1) Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print zahl, "innerhalb 1 und 100" CaseOf If(Between(zahl,100, 199) = 1, zahl, -1) Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print zahl, "innerhalb 100 und 200" CaseOf If(Between(zahl,200, 299) = 1, zahl, -1) Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print zahl, "innerhalb 200 und 300" CaseOf If(Between(zahl, 300, 399) = 1, zahl, -1) Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print zahl, "innerhalb 300 und 400" CaseOf If(Between(zahl, 400, 499) = 1, zahl, -1) Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print zahl, "innerhalb 400 und 500" CaseOf 0 ende = 1 EndSelect EndWhile Locate 5, 1 Print "Taste für Weiter...." WaitKey Cls ende = 0 Locate 1,1 Print "Gib einen Kleinbuchstaben a-y ein 0 = Ende" WhileNot ende Locate 2, 1 Print "Buchstabe : " Locate 2, 13 Input b Select b CaseOf If(Match$("[a-n]{1}", b) <> "", $Match, "") Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print b, "innerhalb a - n" CaseOf If(Match$("[o-z]{1}", b) <> "", $Match, "") Locate 3, 1 : Print Space$(30) Locate 3, 1 : Print b, "innerhalb o - z" CaseOf "0" ende = 1 EndSelect EndWhile waitkeyIst evtl. interessant, wenn man z.b. Artikelgruppen (Bereiche) überprüfen möchte. Kann man evtl. mal öfter brauchen.
-
So könnte man prüfen, ob ein String NUR Buchstaben und evtl ein Blank enthält oder auch andersrum, ob er Zahlen (Rückgabe -1) enthält.
CodeDef IsAlphabetic(1) If(Match$("[a-zA-ZßäÄöÖüÜ ]{" + Str$(Len(@$(1))) + "}", @$(1)) <> "", 1, -1) Declare String s1, s2 s1 = "Hallo Welt" s2 = "abc123Welt" Cls Print IsAlphabetic(s1), IsAlphabetic(s2) Waitkey EndVielleicht kann es ja jemand brauchen.
-
-
Würde das nicht gehen ?
Mit Create("hPic", ....) Bild laden, die Systemvariablen %BmpX und %BmpY enthalten dann Höhe und Breite des Bildes. Ob bei GetPixel(x, y) der Bildschirm oder das zuletzt geladene Bild gemeint ist, müßte man noch herausfinden. Vielleicht klappt ja was mit der Umleitung von StartPaint -1 und DrawPic. Wenn nur der Bildschirm geht, muß man halt zuerst das Bild darauf zeichnen und dann relativ zu den Koordinaten mit GetPixel(x, y) arbeiten.
Müßte man mal probieren.
-
Kommt ein Mann in den Baumarkt und fragt nach Hodenfarbe. Sagt der Verkäufer : Haben wir nicht. Zu was soll das denn gut sein ? Der Mann : Ich war gestern beim Arzt. Der Cholesterin-Spiegel sei zu hoch. Ich soll die Eier streichen.
-
Ich denke auch, daß mein Fragesteller damit leben kann, zumal ich ihm letzte Woche schon gemailt habe, daß einSelberextrahieren der Datei zu schwierig ist. Er braucht ja eigentlich nur was, damit er die erzeugten Dateien bzw. die Titel, die ja in einer extra erzeugten .csv Datei stehen, besser verwalten kann.
Was mir noch aufgefallen ist :
Wenn ich $ProgDir statt $CurrentDir als Pfad für das Tool nehme, funktioniert das Tool nicht bzw. schreibt nichts, obwohl in beiden Ordnern das Tool existiert. Auch dauert es ewig länger, wenn man die Dateien in einen Ordner auf z.b. USB-Stick extrahieren läßt. Bei ein paar Sekunden hätte ich ja nichts gesagt, aber das geht über eine Minute und noch mehr. Aber das ist ja kein Problem von XProfan sondern eher eines von Windows bzw. vom DOS-Untersatz (Konsole).
-
Habe ich mir auch schon ohne ChatGPT gedacht, daß das nicht so einfach ist, da ca. 600 Zeilen für ein kleines Konsolenprogramm ja ganz schön viel ist und da mehr dahinter steckt.
Also bleibe ich da lieber bei dem Konsolenprogramm und mache dem Fragesteller evtl. was zur Verschönerung bzw. zus. Speicherung.
-
Für die Frage, ob Du das machen darfst, kommt es wohl darauf an, ob das Musikdateiformat ein freies Format dergestalt ist, dass jeder, der möchte, solche Dateien erstellen darf, oder ob das nicht der Fall ist (jeder darf z.B. MIDI-Dateien erstellen, soweit ich weiß, aber es darf nicht jeder DOC-Dateien erzeugen).
Nach meinem Verständnis denke ich schon, daß man das darf. Oder warum schreibt das Instrument einen XML-Vorspann davor, der alle Infos liefert ? Das könnte das ja auch genausogut geräteintern speichern. Auch dem ehemaligen Mitarbeiter von der Firma Roland (lebt jetzt in den USA), der angeblich an dieser Sache beteiligt war, ist es egal. Nur möchte der keine Zeit mehr daran verschwenden. So hat es mein Fragesteller, der kurz mit ihm Kontakt hatte, mal gesagt.
PS: Wenn du mit einem Editor die erzeugten .upg-Dateien anschaust, steht da auch jeweils ein XML-Header an erster Stelle. Den müßte man so dann auch neu schreiben.
-
Glückwunsch auch von mir.
In 3 Jahren bin ich auch soweit

-
Außerdem frage ich mich, warum Du die Datei nicht selbst auseinandernimmst (blockread --> blockwrite). Dazu brauchst Du doch kein externes Programm.
Das habe ich auch schon krampfhaft versucht und bin immer wieder gescheitert. Die Dateien hatten einen anderen Anfang, als die, die das Tool erzeugt hatte. Die Dateien waren somit für den ROLAND-eigenen Editor, mit dem mein Anfrager die Dateien wieder rüberspielt, unbrauchbar. Offensichtlich stimmte da immer der Offset für BlockRead() nicht. Normalerweise kann man die Länge auch aus dem XML-Vorspann rauslesen. Aber, wo man da genau zu lesen anfangen muß ? In einem Elektronik-Forum sagt auch jemand, daß da zuerst ein 7 Byte großer Bereich übersprungen werden muß. Evtl. noch zur Info : In der .upa - Datei stehen da überwiegend Steuerbefehle für das elektronische Akkordeon drin. Laut Info des Autors von dem Tool stecken da ca. 600 Zeilen C-Quellcode drin. Scheint also doch etwas aufwändiger zu sein.
ZitatAlles anzeigenEF BB BF : Magic
4 Bytes : Länge des XML Header (Big-Endian)
XML Header : XML mit weiteren Angaben zu den Daten
die einzelnen Sets : Anzahl und Größe entsprechend dem XML Header
"UPLIST" : Bedeutung unklar, für die Sets wohl nicht relevantDie einzelnen Sets fangen also ab Offset "7 + Länge des XML Header" an,
die Anzahl und Größe ergibt sich aus dem XML Header.Zum XML Header, der ist eigentlich selbsterklärend, es wird der Aufbau
der Daten beschrieben, die relevanten Teile:für den Fr: <SET size="26038" number="98" offset="0">
-> 98 Sets mit je 26038 Bytes
für den Fr-8x: <SET size="25752" number="1400" offset="0">
-> 1400 Sets mit je 25752 BytesAuch damit kam ich nicht so recht weiter. Die Titel sollten jeweils ab Offset $39B als 7Bit Ascii (20 Bytes) stehen. Vielleicht hast du ja damit mehr Glück. Bloß meinte Volkmar damals, das täte gegen das Urheberrecht verstoßen. Deshalb hatte ich es löschen lassen und aufgegeben. Aber der Autor des Tools täte das ja auch, da er das Tool ja als Download im Elektronik-Forum anbietet.
Wäre halt zu schön gewesen, den Musikern sowas zur Verfügung zu stellen. Man weiß ja nicht, wie lange MS noch Konsolenprogramme unterstützt.
-
Danke für deine Mühe.
Oha, das ist ja wahnsinnig schnell. Da braucht man ja keine Fortschrittsanzeige. Die paar Sekunden kann man ja auch leicht mit einer Sanduhr (UseCursor 2) überbrücken. Was ist da denn der Unterschied (Shell zu WinExec() ) ? Ich hatte das Tool ja mit Shell aufgerufen. Selbst beim Aufruf auf auf Konsole (CMD) brauchte das ziemlich lange, obwohl es ja keine Ausgaben auf Konsole macht.
Da muß ich mal schauen. Ich will ja das Programm flexibel halten und mit ChooseDir$() und LoadFile$() die Pfade und Quelldatei ermitteln. Das Tool selber kann ja immer in $ProgDir liegen. Dort gehört es ja auch hin. Das nehme ich später auch als Ressource auf und schreibe es beim Programmstart, damit es auch immer verfügbar ist.
-
Der Fokus liegt also auf die Erkennung des Fortschritts von RolandFrxSettings.exe.
Ja genau. Da das Programm ja etwas stupide arbeitet oder besser gesagt keine Ausgaben über den Fortschritt macht und nur kommentarlos in den Ordner schreibt, soll ein Programm drum herum, das eine Progressbar über den Fortschritt anzeigt. Da man ja die einzelnen .upg-Dateien auch wieder zurückspielen kann, soll später noch eine kleine Datenbank hinzu kommen. Der Benutzer kann ja einzelne Registrierungen (.upg) wieder neu in ein Bank im Akkordeon legen und somit sind verschiedene Kompositionen möglich, z.b. für eine Hochzeitsfeier, Geburtstag, kleines Volksfest usw. Auch eine Weitergabe der einzelnen Registrierungen an seine Kollegen ist da möglich. Da wäre es ja übersichtlicher, hier mit einem Windowsprogramm und einer Gridbox oder einem TreeView zu arbeiten, als von Konsole bzw. Explorer einzelne Dateien zu kopieren bzw. zusammen zu stellen. Man muß ja wissen, wo die einzelenen Titel (Registrierungen) stehen. Sähe auch halt etwas hübscher aus.
-
Hallo JörgG,
Den Ausgabeordner kann auch woanders liegen. Das Programm und die .upa-Datei natürlich auch.
Dachte, man sieht es in meinem Code :
Codeprog = $ProgDir + "RolandFrxSettings.exe -d " + Del$(outordner, Len(outordner), 1) + " " + dateiAnsonsten einfach auf Konsoloe (CMD)
ZitatRolandFrxSettings.exe
aufrufen. Im Klartext also :
ZitatRolandFrxSettings.exe -d test upg_all.upa
test = Ordner, in den die Dateien geschrieben werden
upg_all.upa = die zu zerstückelnde Datei
Die Einzeldateien (1400 Stk.) sind immer gleich groß (26.853 Bytes - 27 KB). So eine große .upa-Datei hat immer 1400 Registrierungen (Einzeldateien) 100 Bänke zu je 14 Registrierungen. Es gibt auch noch ein kleineres Arkordeon, wo die Dateien kleiner und die Registrierungen weniger sind. Spielt hier aber erstmal keine Rolle.
-
Danke, JörgG für die Info.
Das mit dem
wußte ich nocht nicht.
Es scheint mir aber auch nicht zu helfen. Ich weiß ja nicht, wie ich dann den Fortschrittsbalken steuern soll.
Am besten versuche ich es mal mit einem Timer, der alle Sekunde mit AddFiles den Ordner ausliest.
Die Listboxliste wird dann in ein Array kopiert. Bei jedem Auslesen mit AddFiles (vorher mit ClearList löschen) wird ja die Listboxliste um einen (wenn das Timing stimmt) Eintrag erhöht. Wenn man dann beim zweiten mal die Größe des Arrays (SizeOf()) mit der Anzahl der Listboxeinträge vergleicht, weiß man, daß eine neue Datei geschrieben wurde und kann den Fortschrittsbalken ums 1 erhöhen. Da das Fremdprogramm ja am Schluß eine .csv-Datei schreibt, kann ich dann auch die Gridbox entsprechend füllen. Soweit mal meine Gedanken dazu.Ich habe mal zum Ausprobieren das DOS-Programm und eine .UPA-Datei (die mit dem Programm zerlegt wird) zum Testen angehängt.