Autor Beitrag
jasocul
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 6393
Erhaltene Danke: 147

Windows 7 + Windows 10
Sydney Prof + CE
BeitragVerfasst: Di 07.06.05 20:47 
user profile iconhansa hat folgendes geschrieben:
Und @Jasocul : ja, das ist in der Tat ein Teil einer eigenen Komponente. Aber wieso mag ich keine Fremdkomponenten ? Die sind mir nur lediglich egal, sofern ich in der Lage bin mit vertretbarem Aufwand selber eine zu machen. Allerdings gibt es momentan tatsächlich handfeste Argumente gegen den Einsatz derselben. Ich sage nur .NET. Wielange dauert die Portierung einer Fremdkomponente ? Wird das überhaupt in Angriff genommen ? Wie weit ist z.B. Jedi.NET ? Wer weiß. Zur Zeit ist alles sehr ungewiss. Siehe Schicksal von Turbopower. Für den hier angesprochenen Zweck sind die Jedi-Ritter allerdings eher wie Atombomben auf Spatzen zu werfen. :lol:

Ich hatte nur den Eindruck gewonnen, dass du lieber alles selbst machst, bevor du etwas "fremdes" anfasst. :D
Bei den Portierungen hast du das selbe Problem mit eigenen Komponenten. Und wenn etwas sofort mit .NET rauskommt, würde ich mirt über die Stabilität echt Gedanken machen.
Ich benutze übrigens für numerische Eingaben die Komponente TjvCalcEdit.
hansa
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3079
Erhaltene Danke: 9



BeitragVerfasst: Di 07.06.05 22:19 
@Mods : das ist zwar jetzt auch ziemlich OT, aber es ist wichtig ! Bitte jetzt nicht aus dem Zusammenhang reißen und verschieben !

user profile iconjasocul hat folgendes geschrieben:
...Ich hatte nur den Eindruck gewonnen, dass du lieber alles selbst machst, bevor du etwas "fremdes" anfasst. :D
Bei den Portierungen hast du das selbe Problem mit eigenen Komponenten...


Der Eindruck stimmt ja auch, sofern es denn ohne zuviel Aufwand geht. Das ist ein entscheidender Unterschied ! Meine Erfahrungen sind die folgenden : den Schwierigkeits-grad für Komponentenentwicklung stufe ich als sehr hoch ein. Gute und brauchbare Infos sind sehr, sehr selten zu finden. Soviel vorab für diejenigen, die denken, ohne Vorkenntnisse in 5 Min. eine eigene Komponente entwickeln zu können.

Was ist nun zu tun ? Dazukaufen oder sich das Ganze selber beibringen ? Lassen wir mal das Geld außen vor. Der Aufwand das selber zu lernen ist, wie gesagt, hoch. Aber der Aufwand eine Fremdkomponente richtig zu beherschen ist auch nicht zu unterschätzen. Bei letzterem kommt noch folgendes dazu : die Vorgaben sind bekannt und man muß was suchen, das paßt. Einfach ist das nicht und zeitraubend noch dazu. Ich hatte irgendwann für solche Sachen wie hier gefragt, keinen Nerv mehr. Irgendwie waren die fertigen Komponenten nie das richtige und zudem total überfrachtet. Wenn überhaupt dabei, so ist es äußerst schwierig sich in fremden Source einzuarbeiten. Oder zu umfangreich, wie die Jedis, um schnell mal was passendes zu finden. Allerdings ist es bei jedem anders. Mir war von Anfang an klar, daß ich fast das ganze von Delphi abgedeckte Spektrum beherrschen mußte. Da gehören auch eigene Komponenten dazu. Irgendwann wäre das sowieso gekommen. Ja und deshalb habe ich so eine "leichte" Sache wie die hier genommen um das mal bis zum bitteren Ende durchzuziehen.

Insgesamt hat das jetzt alles (trotz dem Zeitaufwand) eine Reihe von Vorteilen : ich weiß was ein package ist und wo was hin muß. Natürlich habe ich auch Fremdkomponenten. Bei den eigenen weiß ich genau wo was im Fall der Fälle im Source zu ändern ist. Wie ich das in die Komponentenpalette packe und dort auch ein eigenes Icon hinkriege. Die Umstellung auf .NET wird IMHO nicht viel werden, ich brauche aber nicht auf andere Leute zu warten und mache das so wie ich will. Vor Longhorn wird in der Richtung allerdings kaum was passieren.

Und jetzt noch das führende "," mit automatischer Null. Ich habe das ganze natürlich OOP-mäßig gemacht. Deshalb die Variable ZulZeichen. Das wird für string, integer und real eben immer so besetzt, wie es sinnvoll ist. Ab integer wurde z.B. auch rechtsbündige Eingabe eingeführt. Insofern bräuchte ich nur das OnKeyPress im RealEdit daraufhin anzupassen und schon hätten alle Real-Felder diese Eigenschaft. Man versuche so was mal bei einer Fremdkomponente zu machen. 8)

_________________
Gruß
Hansa
GKar Threadstarter
Hält's aus hier
Beiträge: 5

Win XP
Delphi 7 trial
BeitragVerfasst: Mi 08.06.05 07:28 
Also,

jetzt melde ich mich wieder zurück...

Habe hier ja ganzschön was losgetreten.

Inzwischen habe ich das doch anders lösen können, ich poste den Code später mal hier, dann bitte ich Euch, mir als Neuling vielleicht ein ppar kritiken (gutgemeinte) dazuzugeben, oke?!

Jetzt kam da der Begriff "Jedi-Bibliothek" auf. Was ´n des? :shock:

Gruß
alzaimar
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2889
Erhaltene Danke: 13

W2000, XP
D6E, BDS2006A, DevExpress
BeitragVerfasst: Mi 08.06.05 07:53 
user profile iconhansa hat folgendes geschrieben:

Eingaben wie "0," werden mit Nullen aufgefüllt. Die Anzahl der Nachkommastellen stelle ich hierbei im OI ein.

Wo denn? In Delphi? Bei TEdit? Gibt's nicht.

user profile iconhansa hat folgendes geschrieben:

Führende "," "-" usw. sind nicht erwünscht. Wäre aber wohl kein Problem, bei einem "," am Anfang daraus "0," zu machen.

Ich glaube, es geht hier um ein TEdit, das die Eingabe reeller Zahlen ermöglichen soll. Und wenn nicht, habe ich eine Lösung präsentiert, die das kann. Zu den reellen Zahlen gehören auch nun mal auch Vorzeichenbehaftete und Angaben der 10er Potenz (1,23E+34).
Das man Deine Lösung noch abändern kann, steht außer Frage. Aber so, wie sie dasteht, funktioniert sie erstens nicht und ist zweitens eben unvollständig. Und mit allen (selbstverständlich einfach zu implementierenden) Änderungen und Erweiterungen erscheint Deine Lösung ziemlich kompliziert (an Codegröße gemessen).

Zu Der Frage, ob der Anwender wissen sollte, ob nun der Punkt oder das Komma der Dezimalseparator sein soll, verweise ich Dich auf den Dezimalpunkt auf der numerischen Tastatur. Jeder Datentypist wird Dir mit deiner Einstellung eins Husten, wenn Du ihm sagst, das in der deutschen Version der Dezimalpunkt eben ein Dezimalkomma ist und er deshalb bitte auf die komfortable Eingabe via numerischer Tastatur verzichten muss.

user profile iconhansa hat folgendes geschrieben:

Das überlasse ich doch nicht dem Anwender. :shock:

Eben, dafür sorge ich im Code.

Obwohl Du mit der Prämisse, Probleme zu vermeiden, anstatt Sie nachträglich zu lösen, Recht hast, passt das hier (leider) nicht. Wenn ich eine Art TFloatEdit haben will, lande ich IMHO mit deinem Ansatz (OnKeyPress) in einer Sackgasse (Siehe Oben). Mein Vorschlag, das mit TryFloatToStr zu machen, ist auch nicht perfekt, hier wäre ein DEA angebracht. Mir ging es um eine Möglichkeit, die vorhandenen Mittel zu nutzen, um zum Ziel zu kommen. Eure Einwände bezügl. des Try...Except sind einfach korrekt. Aber dazu ist so ein Forum ja da: Dazulernen und Erfahrungen austauschen.

Ich meine, eine Kombination aus OnKeyPress und OnChange (bzw. über einen Validierer) wäre stilistisch ideal: OnKeyPress lässt nur legale Zeichen zu, während der Validierer die Syntax überprüft.

@GKar: Die Jedi-Bibliotheken gibt es hier www.delphi-jedi.org/