BlitzBasic Portal Worklogs - Tinkerer's Auxiliary

Stand der Dinge

Tritium — Thu, 24 May 2012 20:58:58 +0200

Wie hab ich da so schön geschrieben? "Als nächstes werd ich ein einfaches Programm (mir schwebt da ein Einheitenrechner vor) schreiben..."

...

Eine kleine GUI ist schnell zusammengetüdelt, dann mal eben ein paar Einheiten implementiert, funktioniert. Aber - was ist das?
Code: [AUSKLAPPEN]

1000000.0 * 0.000001 = 0.99999999747524271

Soviel zum Thema einfach... da hätte ich auch vorher dran denken können. Zunächst ist das ein eher ästhetisches Problem, schließlich liefert die Rechnung ziemlich genau das richtige Ergebnis. Ziemlich genau ließe sich nach ganz genau runden, sobald aber noch ein paar Zehnerpotenzen mehr überbrückt werden müssen ist das nichtmehr so einfach.

Da hilft nur eins: Mehr Power! Und eh ich mich versah hab ich an einem Stringrechner gefrickelt.

Ich hab mir die Stringrechner hier im Forum vorher angesehen, mir hat jedoch keiner zugesagt. Zu wenig Möglichkeiten, nicht robust genug (z.B. gegenüber fehlerhaften Eingaben) und trotz Arbeitserleichterung wäre eine Einarbeitung notwendig gewesen - versteht mich bitte nicht falsch, die hier verfügbaren Stringrechner (insbesondere der von Rallimen) sind klasse, ich weiß ja (mittlerweile ), wieviel Arbeit in so etwas steckt. Da mich aber auch interessierte, wie diese Rechner programmiert werden, hab ich mich dann selbst drangesetzt. Bisher kann ich folgendes vorweisen:

- Eigenes Modul mit Dokumentation jeder verfügbaren Funktion
- Unterstützung für negative Zahlen und Fließkommazahlen
- Robust gegenüber falschen Eingaben
- Unterstützt positive und negative Unendlichkeit sowie NAN (Not a number)
- Sämtliche Zahlen können ohne zusätzlichen Aufwand auch e-notiert übergeben werden (in ca. fünf verschiedenen Schreibweisen)
- Zahlen können von der gängigen Notation in die wissenschaftliche/technische Notation überführt werden und umgekehrt
- Pi und die Eulersche Zahl e sind mit 100 Nachkommastellen verfügbar
- Hilfsfunktionen wie Sgn und Abs
- Momentan unterstützte Grundrechenarten: Addition, Subtraktion, Multiplikation (basierend auf der Trachtenberg-Methode)
- Genauigkeit der Rechnungen kann verringert werden, um unnötige Berechnungen und somit Rechenzeit zu sparen

Mit der Schnelligkeit bin ich recht zufrieden, im Debugmodus wird die Fakultät von 1000 in ca. 10 Sekunden berechnet (das Ergebnis hat etwas mehr als 2500 Stellen), ohne Debug sinds zwei, drei Sekunden weniger. Momentan fehlt die Division, da scheue ich mich noch etwas vor

Wie oben bereits erwähnt basiert die Multiplikation (und dann auch die Division) auf den Schnellrechenmethoden nach Trachtenberg - wenn man das System erstmal verstanden hat bringt es so einiges, auch auf Papier (wofür es entwickelt wurde). Solltet Ihr Euch bei Interesse also mal ansehen, so schwierig ist es nicht! Programmiertechnisch brachte es für mich v.a. den Vorteil, dass ich trotz des Umgangs mit Strings viele Berechnungen mit Integern durchführen konnte.

Für die Zukunft hat die Division absolute Priorität, da ich damit dann die vier Grundrechenarten zur Verfügung hätte. Darauf aufbauend lassen sich dann Quadrate, Wurzeln, Fakultäten, trigonometrische Funktionen etc. berechnen. Außerdem möchte ich ganz gerne, dass man Pi mit mehr Nachkommastellen bestimmen kann (hat aber vorerst keine Priorität). Für geometrisches sind zehn, zwölf Nachkommastellen zwar mehr als genug, stattdessen ließen sich solche quasi-zufälligen Zahlenfolgen z.B. für kryptographische Zwecke nutzen (von Euch, ich muss mich dann mal wieder auf das eigentliche Programm konzentrieren ).

Auch wenn ich vermute, dass sich die an diesem Worklog Interessierten an einem Finger abzählen lassen glaube ich, dass ein Stringrechner für manche eine Arbeitserleichterung sein könnte. Deswegen werde ich vermutlich, wenn er weiter ausgebaut ist, das Modul hochladen. Vielleicht behalte ich mir vor, nur vorkompilierte Module zur Verfügung zu stellen, schließlich steckt einiges an Arbeit drin, aber das werd ich entscheiden wenn es soweit ist.

---

Nebenbei habe ich mich etwas um die Kommunikation zwischen den Programmen gekümmert, die Theorie ist aber immer noch sehr bescheiden. Wie schon an anderer Stelle erwähnt, ich programmiere gerne, aber mein Lieblingshobby ist es definitiv nicht, deswegen bin ich hier im Forum eher weniger produktiv Trotzdem hoffe ich, Euch weiterhin halbwegs konstant von Fortschritten berichten zu können.

---

Und dann wäre da noch etwas: Trotz Freunden, Hobbies und nicht zuletzt Uni etc. bleibt glücklicherweise immer wieder mal etwas Zeit fürs Programmieren, doch hin und wieder kann ich mich einfach nicht dazu motivieren. Weniger wegen des Codens an sich, sondern weil ich nach konstanter Beschäftigung (bspw. mit Schnellrechenmethoden ) etwas anderes machen möchte. Deswegen überlege ich momentan, ob ich einen zweiten Worklog anfange, den ich komplett einem Spiel widme. Ich habe noch keine konkreten Vorstellungen, es soll vom Schwierigkeitsgrad (für den Programmierer) aber eher moderat bleiben, damit ich etwas habe, was ich fertigstellen kann. Damit hätte ich dann zur doch eher drögen Anwendungsentwicklung ein kreatives Gegenstück.

Naja, man wird sehen. Bis dahin!

Umstrukturierungen und so

Tritium — Wed, 21 Mar 2012 00:26:35 +0100

N'Abend,

wie aus meinem letzten Post vielleicht zwischen den Zeilen zu lesen war, wird das Konzept nach wie vor überarbeitet. Bei aller Liebe zur Bauteilverwaltung hatte ich bisher nämlich keine überzeugende Idee, wie ich denn zusätzliche Features (wie eine Projektverwaltung, ein Lexikon, etc.) sinnvoll einbinde, ohne das Programm vollkommen zu überladen. Die Idee der Bauteilverwaltung gefällt mir sehr gut, aber dennoch gibt es noch so einige Sachen, die man als Elektronikbastler doch auch vom Computer erledigen lassen könnte. Und nicht zu vernachlässigen ist, dass es bereits einige Programme zur Bauteilverwaltung gibt. Sie gefallen mir zwar nicht (was ja Geschmackssache ist), aber das ist kein triftiger Grund, warum dieses Programm besser ist als die bereits bestehenden.

Ums kurz zu machen: Von den Klausuren abgesehen hat mich diese Unsicherheit davon abgehalten, große Fortschritte zu machen. Doch glücklicherweise gibt es manchmal so etwas wie Geistesblitze

Warum sollte ich das ganze nicht etwas modularer gestalten? Das würde dazu führen, dass man zusätzliche Features problemlos hinzufügen könnte ohne die Bauteilverwaltung zu überladen. Und diesen Gedankengang hab ich in diesem Prototypen manifestiert:

Damit bin ich von der ursprünglichen Idee etwas abgewichen (und ganz nebenbei seht Ihr jetzt auch, welche Bedeutung TA hat ). Damit wird aus der Bauteilverwaltung ein Programm zur Verwaltung von hilfreichen Elektronik-Programmen, unter denen eines dann eine Bauteilverwaltung ist. Da diese Programme in einem zentralen Programm verwaltet werden, kann ich es mir gut vorstellen, dass diese Programme sich auch aufeinander beziehen können, will heißen, möchte ich bspw. in meiner Bestandsverwaltung etwas über ein Bauteil wissen, ruft TA automatisch das Lexikon-Programm mit dem entsprechenden Artikel auf.

Zum Screenshot: Zunächst möchte ich an dieser Stelle feststellen, dass ich den hässlichen Büro-Look unbedingt überarbeiten möchte. Da das aber auf die Funktionalität keinen Einfluss hat, muss das leider warten
Unter dem Fragezeichen links oben findet sich eine kurze Hilfe zum Programm, in der das wichtigste beschrieben ist. Über das Plus links unten werden neue Programme importiert, sodass sie dann in der Liste angezeigt werden. Übrigens existiert bisher kein einziges Programm, ich hab da nur mal ein paar Dummys platziert, um das Bild etwas anschaulicher zu machen.
Jedes Programm wird mit drei Buttons in die Liste eingetragen: Der große (der die Beschriftung trägt) startet das entsprechende Programm. Über das Kreuz kann das Programm entfernt werden, und mit "^" sollen Updates gesucht werden können.
Die Anordnung funktioniert bereits, das Fenster kann skaliert werden, woraufhin alle Programme so angeordnet werden, dass nicht nach rechts, sondern nur nach oben/unten gescrollt werden muss. Die Buttons "?" und "+" bleiben immer an der gleichen Stelle, sind also auch während des Scrollens immer präsent. Übrigens hab ich hier ein ScrollPanel (MaxGUI.ProxyGadgets) verwendet, das funktioniert nach kleineren Anlaufschwierigkeiten jetzt wunderbar.

Den zweiten wichtigen Punkt hab ich vor einer guten Stunde fertiggestellt (zumindest funktionierts und hat bisher keine Bugs ): Die Grundlage für die Kommunikation zwischen den Programmen. Um das ganze wirklich modular zu machen werden TA und jedes der importierten Programme eine eigene .exe-Datei sein. Dazu hab ich jetzt ein Modul fertiggestellt, dass mir NamedPipes zur Verfügung stellt. An dieser Stelle vielen Dank an Der Eisvogel, der in diesem Thread was zum Thema gepostet hatte:

https://www.blitzforum.de/foru...light=exen

Da ich davon keine Ahnung hatte war das ein toller Einstiegspunkt in die Thematik. Das daraus entstandene Modul ist jetzt ein klein wenig umfangreicher geworden und unterscheidet sich recht stark von dem geposteten Code, aber vom stumpfen Abschreiben hat schließlich bisher noch keiner was gelernt.
Sollte Interesse an dem Modul bestehen, dann schreibts in die Kommentare, dann würd ich das zu einem späteren Zeitpunkt posten, an dem ich es öfter eingesetzt hab und mir dementsprechend sicher sein kann, keine allzu üblen Bugs eingebaut zu haben.

So, das soll's für diesen Eintrag erstmal gewesen sein. Als nächstes werd ich ein einfaches Programm (mir schwebt da ein Einheitenrechner vor) schreiben und in TA einbinden, also versuchen, die Kommunikation zwischen den Programmen auf die Beine zu stellen und eine sinnvolle Struktur in die Sache zu bringen. Bis dahin würd ich mich über Kommentare jeglicher Art freuen und wünsch Euch noch eine schöne Nacht.

Lang ist's her...

Tritium — Sat, 28 Jan 2012 18:58:34 +0100

...seit ich hier etwas getan habe. Ich hätte liebend gern schon früher was gemacht, aber die Uni ist nunmal wichtiger, außerdem hab ich mich das letzte Jahr wieder mehr mit Elektronik befasst, wodurch für dieses Projekt keine Zeit blieb.

Um's kurz zu machen: Ich hab mit BlitzMax angefangen, da mir Blitz3D doch irgendwann zu umständlich wurde, was das Verwalten von Objekten anging. Und dementsprechend folgt auch die nächste Konsequenz: Die einfache GUI, die ich in den ersten ein, zwei Posts präsentiert habe, wurde aufgegeben. Klar war es interessant, sowas mal selbst zu schreiben (seltsamerweise hat's auch funktioniert ), allerdings hat es mich ja komplett von dem abgehalten, was ich eigentlich vorhatte.
Deshalb benutz ich jetzt die MaxGUI, die sollte für mein Projekt vollkommen reichen. Außerdem macht's doch mehr Spaß, die eigene Arbeit direkt in die GUI einbinden und dementsprechend die Fortschritte sofort sehen zu können

Desweiteren hab ich das Projekt jetzt umbenannt. Von "IV" in "TA". Klasse, oder? Mein Programm einfach "Inventarverwaltung" zu nennen war mir doch zu langweilig, das hört sich so nach deutscher Bürosoftware an, und das muss ja nicht sein. Die Auflösung, was "TA" denn bedeutet, gibt's ein andernmal

Da ich aus diesem Eintrag ein klein wenig mehr als nur "Hallo, ich lebe noch" machen möchte, will ich Euch hier mal das aktuelle Konzept und meine Ziele für dieses Projekt vorstellen. Ich weiß, hab ich im ersten Post schon erwähnt, aber ein bisschen hat sich doch getan, deshalb:

Features

- Verwalten von Bauteilen: Das Programm macht es möglich, jederzeit Bauteile zum Inventar hinzuzufügen und wieder zu entfernen. So weit, so bekannt.

- Intelligente Suchfunktion: Dieses Feature möchte ich mit als erstes implementieren, sobald die grundlegende Verwaltung funktioniert. Sinn der Sache ist es, dass das Programm den Bauteilestand so intelligent wie möglich durchsucht. D.h., ich als Nutzer sage z.B. "Besitze ich 5 mal den BC547B?". Normalerweise würde jetzt die Datenbank durchsucht mit dem Ergebnis, dass die Antwort entweder Ja oder Nein lautet. Das wäre bei Elektronikbauteilen jedoch viel zu kurz gegriffen, denn vielleicht besitze ich keine BC547B mehr, dafür aber BC547C? Diese passen in 99% der Fälle genauso gut, und das Programm würde nix davon sagen. Genau das will ich verhindern, indem das Programm nicht nur nach dem angegebenen Teil sucht, sondern die Suche auch dynamisch, je nach Anforderung, auf andere Typen ausweitet, diese bewertet und dem Nutzer am Ende des Suchvorgangs eine geordnete Liste mit Treffern präsentiert, die sehr wahrscheinlich auch zum Suchfilter passen.
Genauso soll es möglich sein, eine "logische" Suche durchzuführen, also nicht nach einem speziellen Teil zu suchen, sondern z.B. sagen zu können "Ich brauche einen Kondensator mit 47µF und einer Spannungsfestigkeit von mind. 16V, allerdings darf er nicht axial sein, ist da was passendes im Bestand?". Und hier kommt der schwierige Teil: Für so eine Suche werden definitiv mehrere Ergebnisse gefunden. Da muss das Programm jetzt selber wissen, dass es bspw. sinnvoll ist, den Preis in die Bewertung mit einzubeziehen, außerdem sollten Elektrolytkondensatoren gegenüber Tantalkondensatoren bevorzugt werden, etc.
Ich habe hierfür schon ein grundlegendes Gerüst im Kopf, bisher hab ich das aber noch nicht getestet. Auf jeden Fall ist mein Ziel, solche Beziehungen nicht direkt als Code umzusetzen, auch nicht als Skript oder so. Es gibt so viele verschiedene Beziehungen unter den Millionen von Teilen, die existieren, dass das vollkommen unmöglich wäre, alle einzubeziehen. Mir schwebt da etwas vor, was die meiste Arbeit dem Programm überlässt, dazu aber in einem anderen Post mehr.

- Information: Dieser Punkt wird arbeitsreich. Mir schwebt vor, dass dieses Programm nicht nur Bauteile verwalten kann, sondern auch jede Menge Hintergrundinformationen bereithält. Wenn bspw. ein Transistor mit Zustand "Unbekannt" im Bestand ist, dann soll der Nutzer ohne große Umwege auf einen Hilfebutton drücken können, der ihm diesen Zustand weiter erläutert und in diesem speziellen Fall auch sagt, wie er den Zustand des Transistors genauer bestimmen kann.
Außerdem möchte ich dafür sorgen, dass der Nutzer beim Hinzufügen eines Bauteils dieses nicht erst selbst definieren muss, sondern das Programm bereits anhand weniger Angaben (grobe Eingrenzung, zu welcher Gruppe es gehört, Kennung) erkennt, worum es sich handelt. Bei Bedarf können die Standardwerte dann geändert werden.
Diese Arbeit wird sich nach dem Schreiben des Programms abspielen und viel Zeit in Anspruch nehmen. Wenigstens interessiere ich mich für Elektronik, sodass die Recherche nicht zu langweilig wird Dennoch muss ich mir diese Arbeit aufteilen, wozu ich im nächsten Punkt komme:

- Flexibilität: Das Programm soll seine Informationen über Pakete erhalten. Standardmäßig wird es über ein Paket verfügen, das alle wichtigen Bauteile und Informationen zusammenfasst. Möchte man dann aber zu einem spezielleren Gebiet genauere Informationen, dann muss das jeweilige Paket importiert werden. Außerdem möchte ich es möglich machen, dass diese Pakete gleichzeitig als Updatemöglichkeit dienen.

Das waren erstmal die wichtigsten Punkte. Momentan bin ich dabei, einen Paketeditor zu schreiben, der das Erstellen und Bearbeiten der oben erwähnten Pakete möglich macht. Genaueres dazu gibt's in einem späteren Post.

So, hoffentlich war diese Abhandlung nicht zu langweilig, vielen Dank, wenn Du diesen Text bis hierhin gelesen hast
Ich hoffe, bald Fortschritte verkünden zu können, die ich auch mit Screenshots bebildern kann. Momentan lohnt sich das noch nicht, weil es effektiv nicht viel zu sehen gibt.
Achso, den Februar über schreibe ich Klausuren, deswegen kann ich noch nicht abschätzen, wie schnell es hier weitergeht. Ich gebe mir aber Mühe, möglichst schnell weiterzuarbeiten

Übrigens, wie änder ich hier die Schriftgröße? Die Kombobox macht nix, und "size=" in eckigen Klammern scheint auch nicht zu funktionieren...

Das kleine 1*1 der Programmoptimierung

Tritium — Tue, 19 Oct 2010 21:26:53 +0200

Nabend,

ich bin jetzt soweit, dass Textfelder auch mehrzeilig sein können. Und, wie gewünscht: Per Tabulator kann man zwischen den Feldern wechseln.

Nächstes Ziel sind dann wie gesagt die Comboboxen, aber das kann noch ein paar Tage dauern
Ich lad auf jeden Fall eine neue Demo hoch, sobald sie funktionieren.

Ich möchte diesen Eintrag aber auch nutzen, um (v.a. Anfängern) eine kleine Hilfestellung zu geben, was das Optimieren der Programmgeschwindigkeit angeht. Bisher hat mein Programm nämlich ca. 10 Sekunden gebraucht, bis es geladen war (merkt man in der Demo nicht). Ich hab das vorläufig auf die Types geschoben, schließlich benutze ich sie in diesem Projekt sehr häufig und grade zu Anfang wird da ziemlich viel erstellt.

Nach etwas Suchen habe ich dann aber rausgefunden, woran es liegt:

Wenn ein Fenster geöffnet wird, wird hinter das Fenster ein Gitter aus schwarzen Pixeln gezeichnet, um die eigentliche Benutzeroberfläche etwas abzudunkeln und so das Fenster zu betonen. Dieses Gitter wird jedesmal durch das Programm erstellt, wenn ein neues Fenster erzeugt wird. Die Erstellung sah zunächst so aus:

Code: [AUSKLAPPEN]

image = CreateImage(GraphicsWidth(),GraphicsHeight())

SetBuffer ImageBuffer(image)

For x=1 To GraphicsWidth() Step 2
For y=1 To GraphicsHeight() Step 2
Rect x,y,1,1
Next
Next

SetBuffer BackBuffer()

Eben schnell mal hingeschrieben

Dieser Codeblock brauchte jedesmal sagenhafte 900 Millisekunden. Bei zehn Fenstern hat man da schnell was zusammen. Keine Frage, da musste nachgebessert werden. Kurzes Nachdenken erinnert an CopyRect()! Also optimieren:

Code: [AUSKLAPPEN]

Rect 1,1,1,1

For x=1 To GraphicsWidth() Step 2
For y=1 To GraphicsHeight() Step 2
CopyRect 0,0,2,2,x,y
Next
Next

Alleine schon diese kleine Änderung halbierte die benötigte Zeit! Das ist aber leider immer noch zuviel, die Schleifen werden einfach zu oft ausgeführt. Deshalb war der nächste Schritt, das zu kopierende Quadrat größer zu machen. Dazu erstellt man vor der Schleife "von Hand" ein Quadrat mit 8x8 Pixeln:

Code: [AUSKLAPPEN]

Rect 1,1,1,1
Rect 1,3,1,1
Rect 3,1,1,1
Rect 3,3,1,1
CopyRect 0,0,4,4,0,4
CopyRect 0,0,4,4,4,0
CopyRect 0,0,4,4,4,4

For x=8 To GraphicsWidth() Step 8
For y=8 To GraphicsHeight() Step 8
CopyRect 0,0,8,8,x,y
Next
Next

Rechnerisch braucht diese Variante nur noch ein sechzehntel der Schleifendurchläufe der vorigen Methode! Damit bin ich vorerst zufrieden, die Erstellung eines Fensters dauert jetzt noch ca. 40ms. Das ist eigentlich immer noch recht viel, aber wir sind ja erst in der PreAlpha, gell?

Und wie kommt man darauf?

Naja, ein Patentrezept, wie man einen bestimmten Abschnitt schneller macht gibt es leider nicht. Was aber aus vielen Forenbeiträgen hervorgeht ist, dass man sehr schnell dazu neigt, auf die Sprache zu schimpfen, bevor man nach eigenen Fehlern sucht. Doch das Finden der Programmbremsen ist gar nicht so schwierig!

Das Werkzeug der Wahl sieht so aus:

Code: [AUSKLAPPEN]

time = MilliSecs()

;
; Code Code Code
;

DebugLog MilliSecs() - time

...also nichts weiter als eine simple Zeitmessung. Als nächstes überlegt man sich, welcher Teil des Programms eigentlich langsam ist. Der Ladevorgang? Dann kommt der obige Code um die Laderoutine. Ist das Programm hingegen dauernd langsam, sollte man den Code in der Hauptschleife platzieren.

Und was bringen uns die Zahlen nun? Zunächst einen Vergleichswert. Wir brauchen einen Maßstab, mit dem wir den Erfolg der Optimierung messen können.

Jetzt folgt der etwas langweiligere Teil: Wir gehen jede Funktion durch, die an dem langsamen Abschnitt beteiligt ist. Damit lässt sich schnell feststellen, welche Funktion der größte Zeitfresser ist. Der nächste und letzte Schritt ist, den Zeitmesser innerhalb der Funktion solange zu verschieben und zu verkleinern, bis wir den Teil gefunden haben, der so lange braucht. Und ab da muss man dann leider wieder nachdenken, wie der Abschnitt optimiert werden könnte

---

Ich hoffe, dass die kleine Anleitung dem einen oder anderen ein bisschen weiterhilft!

Demo-Update

Tritium — Tue, 12 Oct 2010 23:01:11 +0200

Ich hab die Demo nochmal überarbeitet und eine neue Version hochgeladen. Außerdem habe ich die Radioboxen fertiggestellt, die ab jetzt ebenfalls in der Demo zu bewundern sind!

https://www.blitzforum.de/upload/file.php?id=9657

Eine kleine Demo!

Tritium — Mon, 11 Oct 2010 19:56:47 +0200

Wie versprochen also eine kleine Demo (EDIT: neue Version):

https://www.blitzforum.de/upload/file.php?id=9657

Sieht nicht sehr spektakulär aus, ist aber in Wirklichkeit sehr viel Arbeit gewesen bis hierhin! Wie gesagt, ich hab die GUI selbst geschrieben (worauf ich übrigens recht stolz bin ). Im Programm sieht dann z.B. eine Buttonerstellung so aus:

Code: [AUSKLAPPEN]

gui_createButton(1,"Standard",330,516,140,30,"",False)

Unter den Argumenten befinden sich u.a. der interne Name, die Position, Höhe, Breite und noch ein paar Dinge, dazu aber später mehr. Jetzt wünsche ich erstmal viel Spaß mit der recht kurzen Demo

Bei Fragen stehe ich gerne zur Verfügung.

Erster Eintrag

Tritium — Sat, 09 Oct 2010 22:44:34 +0200

Nachdem ich jetzt ziemlich lange nichts mehr in diesem Forum gemacht habe, möchte ich Euch mal mein aktuelles Projekt vorstellen.

Ich hatte vor ungefähr einem halben Jahr die Idee, ein Programm zur Verwaltung elektronischer Bauteile zu schreiben. Eine kurze Suche ergab, dass sowas bereits existiert. Die bestehenden Programme hatten allerdings einige Nachteile, entweder wurden sie nicht fortgeführt, besaßen viel zu viele Funktionen oder brauchten zusätzliche Dinge wie MySQL, Java ( ) oder gar einen virtuellen Server.
Was läge da näher, als das mal mit BlitzBasic umzusetzen?

Also hab ich mich viele Abende hingesetzt und (zu meiner eigenen Überraschung) sehr viel Code produziert.
Die erste Hürde war, dass ich eine GUI brauchte. Davon gibts ja genug (die außerdem ziemlich gut sind), ich hatte aber Lust, das mal selber auszuprobieren. Das Ergebnis ist besser, als ich zunächst dachte. Natürlich hat meine GUI einige Nachteile, z.B. lässt sich nur ein Fenster gleichzeitig öffnen. Außerdem ist sie - trotz aller Allgemeinhaltung - auf dieses Programm ausgerichtet, weshalb sie eher umständlich für allgemeine Probleme genutzt werden könnte.

Was bringt das Programm jetzt? Der Gedanke ist folgender: Als Elektronikbastler sammelt man über die Zeit tausende von Bauteilen (die man zu 50% nie brauchen wird). Um das alles zu sortieren gibt es verschiedene Ansätze: Wer sucht, der findet; das Haufenprinzip; beschriftete Marmeladengläser; Raaco-Boxen, etc.

Welches Prinzip man auch benutzt, dieses Programm soll im Endeffekt folgendes machen: Man registriert jedes neu hinzugekommene Bauteil. Wenn ich dann etwas brauche, gebe ich den Typ ein und das Programm sagt mir, wieviel davon wo vorhanden ist. Zusätzlich ist es möglich, Mindestmengen anzugeben, dadurch kann das Programm automatisch eine Einkaufsliste der benötigten Teile erstellen.
Eine weitere Möglichkeit ist es, nach Ersatztypen zu suchen. Viele Teile gibt es in x-facher Ausführung, meist mit praktisch identischen Kennwerten. Wenn also mal ein Teil nicht vorhanden ist, dann kann das Programm nach bestimmten Kriterien suchen, ob ein Teil vorhanden ist, das als Ersatz passen würde.

Vieles davon ist im Moment allerdings noch Zukuntfsmusik, sonst wär das hier ja kein Worklog. Deshalb zunächst mal ein Bildchen:

Das ist eine der Seiten, die man in dem Programm aufrufen kann. Hier verwaltet man die Datenbanken, in denen Teile, Projekte und anderes gespeichert sind. Diese Datenbanken sind übrigens jeweils in einer separaten Datei, wodurch sie auch einfach ausgetauscht und mit einer anderen Instanz des Programms geöffnet werden können.

Dann will ich das Bild mal von oben nach unten durchgehen: Die Titelzeile zeigt den Namen des Programms und außerdem den Namen der aktuell geladenen Datenbank. Darunter befindet sich dann der Titel der Seite. Beschriftungen wie diese lassen sich mit meiner GUI überall platzieren und sind den Labels aus BlitzPlus sehr ähnlich. Ich unterscheide dabei noch zwischen statischen und dynamischen Labels. Der hauptsächliche Unterschied ist, dass statische Labels schneller sind, aber nicht im Nachhinein manipuliert (=verschoben, gelöscht, umbenannt, etc.) werden können.
Unter der Überschrift befindet sich eine Liste. Bisher ist es möglich, Elemente hinzuzufügen, sie wieder zu löschen, sie auszuwählen und die Liste zu sortieren. Außerdem kann man in der Liste nach oben und unten scrollen, allerdings fehlt noch ein Scrollbalken.
Tja, darunter befinden sich dann die Buttons, zu denen es nicht viel zu sagen gibt. Draufklicken und es passiert was

Unten befindet sich dann schließlich eine Statuszeile. Im Moment enthält sie sowas wie die Credits in Kurzform, später wird sie auch Hilfetexte zu einzelnen Elementen anzeigen.

Noch ein Wort zum Status: Im Moment befindet sich das Programm im PreAlpha-Status. Mein Ziel für den Alphastatus ist es, dass man Bauteile eintragen, bearbeiten und auch grundlegend suchen kann. Alles andere (z.B. Scrollbalken) sind erstmal zweitrangig.
Das kurzfristige Ziel ist es, Comboboxen und mehrzeilige Eingabefelder zu implementieren.

So, das wars erstmal für diesen Eintrag. Ich werde in den nächsten Tagen eine Probeversion online stellen, das sagt meist mehr als Bilder und Text.