Eure Meinung zu : UtilitiesLib

Hallo Leute

ich habe am WE. mal damit angefangen eine Utilities-Lib zu schreiben die ich an all meine Apps dranhängen will, da man sonst die selben methoden immer und immer wieder codet... das nervt 😁

Was gehört eurer Meinung nach denn in die Lib so alles rein? Folgendes habe ich schon realisiert
*Windows Version und Edition *Windows Usernamen / Gruppennamen auslesen *Windows ServicePack Version *Excel Version (per LateBinding für evtl. Export und Import) *Word Version (per LateBinding für evtl. Export und Import) *Powerpoint Version (per LateBinding für evtl. Export und Import) *Outlook Version (per LateBinding für evtl. Export und Import) *Prozess Utilities *Dienst Utilities *EventLog Utilities *Eigene MessageBox *Eigener InputDialog (mit typensicherer prüfung) *Exception Dialog (zum übermitteln von Exceptions an d. Hersteller)

Was könnt ich noch rein packen??

THX schon mal im voraus

Hallo Thorsten1983,

wenn du wissen willst, was man alles reinpacken könnte, wird die Liste sicher endlos. Die Frage ist also wohl eher, welche Grenzen setzt man, bzw. welchen Focus gibt man der UtilitySammlung.

Auch weil die Motivation bei solchen Projekten typischerweise nach einiger Zeit nachlässt, ist die Konzentration auf das Wesentliche zu empfehlen. Je größer man die Sache aufhängt, desto größer ist die Chance, dass nachher gar nichts herauskommt. Wenn man sich moderate Ziele setzt, ist die Wahrscheinlichkeit, dass man ein brauchbares Ergebnis erzielt, viel größer.

Vielleicht ist es auch besser gar nicht so sehr auf die gesamte Sammlung abzuheben, sondern einzelne Klassen oder Klassenbibliotheken zu bestimmten Themen zu machen. So wie es in Prozess Utilities, Dienst Utilities und EventLog Utilities schon anklingt. Jede dieser Klassenbibliotheken kann schon richtig groß werden, wenn man da alles reinpackt, was man reinpacken könnte.

Außerdem solltest du die Objektorientierung nicht aus den Augen verlieren. Utilities driften schnell in eine Sammlung von Funktionen ab. Besser ist es aber möglichst sinnvolle und nützliche Klassen zu designen, die dann - quasi als Nebeneffekt - auch nützliche Methoden zur Verfügung stellen. Wichtiger ist aber, dass sie nützliche Objekte zur Verfügung stellen.

herbivore

Hallo herbivore,

danke schon ma für die schnelle AW. klar die Problematik ist mir bekannt, immer wieder gibt es das generelle Motivationsproblem bei solchen dingen.

Für mich ist an dieser Stelle halt wichtig, dass ich die Dinge, die sich nicht logisch an eine Objektinstanz heften, bzw. die immer wiederkehrend entwickelt werden müssen, kapsele. Dienste- und EventLog sind hier ein gutes beispiel, im laufe der zeit kommen immer wieder irgendwelche Routinen vor, die man auf den Std. .Net aufsetzt, um dies nicht immer und immer wieder zu implementieren habe ich das Einfach mal in die Utilities gemacht, natürlich bieten alleine diese beiden Dinge genug stoff um alleine ne ganze Lib zu füllen.

Aber ich denke der richtige ansatz wird wohl eher sein dass ich die Util.Lib mitziehe von App zu App und dann entscheide ob die Methode X evtl. öfters benötigt wird und dann in die Util umziehe.. so wächst die Lib ständig an, wobei natürlich drauf geachtet werden muss dass sie nicht zugemüllt wird. 😉

Hallo Thorsten1983,

hast du vor, die Lib hier zu veröffentlichen?

herbivore

darüber hab ich mir noch keine gedanken gemacht...

aber prinzipiell spricht nichts dagegen 😁

Hallo Thorsten1983

für die Office-Wrapper würde ich mich brennend interessieren, da dies doch relativ häufig in meiner Arbeit vorkommt.
Da könnte man viel Zeit und "graue Haare" einsparen 😉

Hallo Thorsten1983,

aber prinzipiell spricht nichts dagegen

fein, dann mach das mal bitte, denn die Forenbeschreibung lautet:

Vorstellung von eigenen Projekten zur freien Benutzung durch die Community.

und nicht "Fragen zu eigenen Projekten, die man dann für sich behalten will." 🙂

herbivore

fein, dann mach das mal bitte,

Ja werd ich tun, allerdings kann sich dass bis zum WE. hinziehen, da ich das neben der arbeit mache und mein chef mir was anderes sagen würd wenn ich die lib hier code und die aufträge liegen bleiben 😜

*g*

Hallo Thorsten1983,

Ich fände eine Utility Lib sehr gut. Jedoch müsste man sich wie herbivore gesagt hat, vorerst auf ein Teilgebiet beschränken, damit das Projekt nicht zu gross - sprich unüberschaubar wird. Ich dänke auch, dass eine solche mächtige Utlilty Lib nicht alleine realisiert werden kann.

Grüsse, pro

Ich fände eine Utility Lib sehr gut. Jedoch müsste man sich wie herbivore gesagt hat, vorerst auf ein Teilgebiet beschränken, damit das Projekt nicht zu gross - sprich unüberschaubar wird. Ich dänke auch, dass eine solche mächtige Utlilty Lib nicht alleine realisiert werden kann.

Ja das stimmt, im nachhinein ist man schlauer, ich werde die lib hier veröffentlichen, dann können sich alle darin austoben. Prinzipiell sehen n Augen eh mehr als 2 😁

Hallo Thorsten1983,

Prinzipiell sehen n Augen eh mehr als 2

falls n > 2 🙂

herbivore

jaja immer diese hürden in den If Clauses 😁 😁 😁 rofl

Gibts denn news zur UtilitiesLib?

GRüße...

Wann wird die Lib denn nun veröffentlicht?

Finde die Idee gut und würde mich gerne dran anhängen, hab diese Wochenende wahrscheinlcih ausser wieder ner Flasche Jacky nichts zu tun.

Würde gerne folgendes Anbieten für das Projekt:

• Global Skinning Component für Controls
• Widgets
• DockingControler

Allerdings je nach zeit abhängig.
Später evtl. noch nen Skinning Tool für's Customizing

Soo nen kleines Feedback die Skinlib ist kurz vor der Fertigstellung.

Das ganze funktioniert wie folgt, man zieht eine Komponente Namens SkinExtender auf den Designer und jedes Control auf der Form bekommt im PorpertyGrid nun die Einträge Skin. Dort gibt es dann die folgenden Möglichkeiten:

UseWindowsTheme:
ja / nein - bei ja wird windows themes benutzt sofern UseDefault auf ja ist.

UseDefault:
ja nein - bei nein wird der Skin reingeladen.

Skin:
Ladet vordefinierten Skin via eindeutigen Namen. Hier bin ich grade bnoch dran das ganze auf ne assembly loader umzustellen für nen späteres skinning tool mit den man dann die einzelnen Controls bearbeiten kann. Damit verbunden wird noch ein globales skinning. So das man eine form welche das SkinComponent besitzt auf alle das selbe Skin vererbt defaultmäßig. Damit braucht man nicht jedes control einzelnd anklicken und den "Skinnamen" wählen bzw. eingeben.

BorderAppearance:
Wenn UseDefault auf nein gestellt wird, so kann man hier der Skinn manuell verändert werden via normalen images. Ebenso kann man hier einfluss auf das DragAndDrop Ereigniss nehmen (ja man kann damit Buttons auf ner Form herumschieben). Die Mauscursor für das Strechen (also auch nen Button z.b. größer zerren) an den jeweiligen Kanten.

CaptionButton:
Wird noch bearbeitet momentan kann man damit sogar Buttons auf nen Button malen 😉 Überlege mir da noch eine Logik die das defaultmäßig erstmal nur bei ner Form veranlässt aber durch umschalten eines kleines schalterchens auch für andere Controls verfügbar macht.

Ansonsten, hoffe werde damit kommendes Wochenende fertig und kann schon etwas reinstellen. Dannach geht es an die Widgets und den DockingControler. Das SkinningTool für das erstellen der Assemblys folgt später, da dieses am meisten zeit beanspruchen wird.