[Future010]

TOOL VORSTELLUNG: "ZAHLENSYSTEME"

Wie ihr sicherlich wisst, stelle ich hier schon seit einiger Zeit immer mal wieder nützliche kleine Tools vor, die von mir selbst programmiert worden sind.


Mein neues Projekt ist ein Umrechnungstool von verschiedenen Zahlensystemen, beispielsweise vom binären (101010) in das Dezimalsystem (42). Mein Tool bietet Unterstützung für die am meisten verwendeten Zahlensysteme, ist dabei schlicht und einfach zu bedienen.
Natürlich wird das Rad damit nicht neu erfunden, aber zumindest anders betrachtet. Wenn ihr meine Software ausprobieren wollt, dann ladet sie einfach kostenlos herunter.

Für Verbesserungen bin ich natürlich jederzeit offen, sei es andere Darstellungen wie Farben oder neue Funktionen. Vorschläge für neue Projekte nehme ich jederzeit entgegen, wenn ihr etwas habt, was programmiert werden soll, dann nur zu.

Quellcode wird es von mir, bezüglich der von mir veröffentlichten Projekte, nicht geben. Ich werde aber nützliche Hilfestellungen oder Tutorien anbieten können. Quellcode zu veröffentlichen schadet der eigenen Leistung.

Viel Spaß mit meiner Software, euer Future010

„Ich übernehme keine Haftung für eventuelle Schäden, die Software wird auf eigene Gefahr installiert/ausgeführt/heruntergeladen“
Dennoch keine Sorge das Tool funktioniert.






Aktuelle Version angefügt:
Version 1.2_1



 Version 1.2_1.zip (212,6K)
Anzahl der Downloads: 132


Verbesserungen:
Live Umrechnung eingefügt
Verbessertes Design
Bugfixes beim Vergrößern der Form
"WongKit Bug" Behoben






Alte Version: 1.0

 Zahlensysteme V.1.0_2.zip (231,79K)
Anzahl der Downloads: 99

Dieser Beitrag wurde von Future010 bearbeitet: 24. März 2015 - 17:52

[RalphS]

Ist natürlich Deine Sache re: Quellcode; ich möchte aber zumindest anmerken, daß es Dir als Programmautor durchaus zugute kommen *könnte*, wenn Du ihn veröffentlichen würdest.

Ein zweites Paar Augen sieht immer noch was mehr, und man lernt auch was draus, wenn andere einem sagen: hey, warum hast Du das so umständlich implementiert, das geht doch so-und-so in zwei Zeilen?

Beispiel (weil ich ja nicht weiß wie Du das gemacht hast): man kann so eine Umrechnung mit bitshift bauen und man kann auch einfach *printf nehmen. Ergebnis ist dasselbe.

Rein von dem Screenshot oben seh ich schon Potential - statt sechs RADIOs reichen vier völlig aus: einer für die Richtung (von / zu Dezimal, dann wohl eher als CHECKBOX o.ä.) und die anderen drei fürs Format (bin, hex, oct).

Dieser Beitrag wurde von RalphS bearbeitet: 23. März 2015 - 15:16

[Future010]

Danke RalphS, ich weiß deine Kritik sehr zu schätzen.

Ich denke auch, dass man im "Menü" noch etwas verbessern kann, ich mache mal ein paar Entwürfe und gucke mal, welcher am besten ist und werde dahingehend das Design anpassen.

Zitat

man kann so eine Umrechnung mit bitshift bauen und man kann auch einfach *printf nehmen. Ergebnis ist dasselbe.

Ja ginge natürlich auch, viele Wege führen nach Rom, zum einen implementierte Funktionen nehmen, oder diese Funktionen selbst schreiben, beim Binären durch den Modulo Operator, dann definieren durch if 0... if 1... Das geht.

Ich werde diese Woche vielleicht noch ein neues Projekt veröffentlichen, da mich jemand hier im Forum auf die Idee dazu gebracht hat. Aber mal sehen.

[Stefan_der_held]

Die Software selbst ist zwar für mich uninterressant, es freut mich aber zu sehen, dass du die Farbgebungen übernommen hast

// finde es irrigierend, dass "Ausgabe" einem "Eingabefeld" entspricht

würde das rein in der GUI als Text (ohne speziell erkennbares Feld) realisieren.

Dieser Beitrag wurde von Stefan_der_held bearbeitet: 23. März 2015 - 17:50

[RalphS]

"Irrigierend"? Versuch mir das grad vorzustellen.

Re: Implementierung einer Problemlösung... nun ja. Ich bevorzuge immer die "bestmögliche" Variante, wie sie sich ergibt aus:

- Eleganz. Wenn eine Codezeile (oder vielleicht genauer: eine *Anweisung*) dasselbe leistet wie viele Codezeilen, ist ersteres zu bevorzugen.

- Effizienz. Wo eine einfache Formel dasselbe löst wie eine (oder gar mehrere!) Schleifen, ist die Formel zu verwenden - eine Funktion in O(1) ist besser als eine in O(n) und eine in O(n) besser als eine in O(n²) und so weiter.

- "Optimalität". Wenn eine Implementierung mit weniger Ressourcen auskommen kann als eine andere, ist erstere zu bevorzugen. Ich sehe eine Implementierung immer als eine Art Flußkontrolle, wo der Flußanfang der Input ist und das Flußende der Output; das Programm dient dann dazu, den Fluß*verlauf* wie gewünscht zu beeinflussen, ohne daß irgendwo was hängenbleibt oder gar verloren geht.

[Stefan_der_held]

Zitat (RalphS: 23. März 2015 - 18:07)

"Irrigierend"? Versuch mir das grad vorzustellen.

doofe verbuggte Tastatur

Irritierend

[WongKit]

Ich finde es gut, dass du deine Software hier vorstellst. Ein paar Anregungen habe ich:

Fehlermeldungen
Normalerweise zwinge ich so gut wie jedes Einsteiger-Programm in die Knie. Bei deinem Umrechner habe ich es nicht geschafft. Trotz willkürlicher Eingabe wurde immer eine eigene Fehlermeldung ausgegeben. Gut!
Allerdings sollten die Fehlermeldungen sprechender sein. So etwas wie "Der Wert für einen UInt32 war zu groß oder zu klein" oder "Ungültige Konvertierung von der Zeichenfolge in Typ Integer" ist für einen Programmierer verständlich, für einen gewöhnlichen Anwender allerdings nicht. Auch die Meldung "Es konnten keine bekannten Ziffern gefunden werden." sagt nicht aus, was der Benutzer falsch gemacht hat.

Bedienbarkeit
Wie RalphS schon geschrieben hat, sollten die Radiobuttons gesplittet werden, sodass das Zahlensystem für Eingabe und Ausgabe separat festgelegt werden kann.
Zudem fände ich es nicht verkehrt, wenn du den Umrechnen-Button verzichtbar machst. Die Ausgabe kann in deinem Fall immer dann erfolgen, wenn du im Eingabefeld einen Wert änderst.

Das Eingabefeld sollte auch nur die Zeichen entgegennehmen, die zum Quellzahlensystem passen.

Sonstiges
Man sollte die Größe des Anwendungsfensters nicht ändern können. Das sieht etwas seltsam aus

Gruß
WongKit

[Future010]

Neue Version 1.2 veröffentlicht:
Mein Link

Verbesserungen:
Live Umrechnung eingefügt
Verbessertes Design
Bugfixes beim Vergrößern der Form









@RalphS

Zitat

Effizienz. Wo eine einfache Formel dasselbe löst wie eine (oder gar mehrere!) Schleifen, ist die Formel zu verwenden - eine Funktion in O(1) ist besser als eine in O(n) und eine in O(n) besser als eine in O(n²) und so weiter.

Genau so soll es sein. Aber mit O(n) ... beschreibt man ja eigentlich das O Kalkül, das kenne ich noch aus Algo I, es lässt sich aber auch definitiv auf die Effizienz anwenden. (Laufzeit...)

Zitat

Bedienbarkeit
Wie RalphS schon geschrieben hat, sollten die Radiobuttons gesplittet werden, sodass das Zahlensystem für Eingabe und Ausgabe separat festgelegt werden kann.

In neuer Version deutlich vereinfacht/verbessert

Zitat

Sonstiges
Man sollte die Größe des Anwendungsfensters nicht ändern können. Das sieht etwas seltsam aus

Verbessert

Zitat

Zudem fände ich es nicht verkehrt, wenn du den Umrechnen-Button verzichtbar machst. Die Ausgabe kann in deinem Fall immer dann erfolgen, wenn du im Eingabefeld einen Wert änderst.

In der Neuen Version verbessert, LIVE Umrechnung eingefügt.

Zitat

Fehlermeldungen
Normalerweise zwinge ich so gut wie jedes Einsteiger-Programm in die Knie. Bei deinem Umrechner habe ich es nicht geschafft. Trotz willkürlicher Eingabe wurde immer eine eigene Fehlermeldung ausgegeben. Gut!
Allerdings sollten die Fehlermeldungen sprechender sein. So etwas wie "Der Wert für einen UInt32 war zu groß oder zu klein" oder "Ungültige Konvertierung von der Zeichenfolge in Typ Integer" ist für einen Programmierer verständlich, für einen gewöhnlichen Anwender allerdings nicht. Auch die Meldung "Es konnten keine bekannten Ziffern gefunden werden." sagt nicht aus, was der Benutzer falsch gemacht hat.

Danke, das freut mich sehr. Das Tool sollte sehr ausfallsicher sein. Benutzerdefinierte Fehlercodes wären tatsächlich noch eine gute Verbesserung. Danke.

Dieser Beitrag wurde von Future010 bearbeitet: 24. März 2015 - 11:02

[WongKit]

Schön, dass du dir unsere Verbesserungsvorschläge angenommen hast!

Nimm dir aber ruhig Zeit, Änderungen zu testen.


An Stelle eines Timers solltest du direkt auf die Änderung des Feldes reagieren. Ich gehe stark davon aus, dass es in .net eine Art "OnChange" Ereignis gibt.

Gruß
WongKit

[Future010]

Danke, für die Meldung des Bugs. Ich habe den mal "WongKit Bug" getauft.
Ich finde das sehr gut, dass du versuchst die Software an die Grenzen zu treiben !
So hat jeder etwas davon. Und bitte sei mir nicht böse, wenn ich dass so sage, aber diese Fehler des dümmsten anzunehmenden Users zu testen ist klasse. Danke also für die Meldung des Bugs

"WongKit Bug" Behoben

[Future010]

Statusupdate von 03.05.15

Ich werde meine Software hier im Winfuture Forum nicht mehr weiterentwickeln bzw publizieren können. Grund hierfür liegt darin, dass ich nebenbei in der professionellen Entwicklung der Informatik mitwirke. Und diese Arbeit dort einfach wichtiger und ausschlaggebender ist, als kleine Projekte hier zu veröffentlichen, die nur einen kleinen Interessentenkreis erreichen.

Meine Tools resultierten immer aus netten und kleinen Ideen heraus. Ich hoffe stets dem Nutzer etwas passendes anbieten zu können, da die Zeit für solche kleinen Hobby Projekte jedoch mittlerweile sehr knapp geworden ist, ist es mir nicht mehr möglich, hier im Forum Software zu publizieren.

Ich danke soweit für das Interesse an meiner Software, die Downloads werden vermutlich noch für einige Zeit zur verfügung stehen. Ich hielt es an dieser Stelle für wichtig, diese Information herauszugeben. Danke !