Hier mein Programm 'PC-Time'

[Reverent]

Hallo Leute,
dies ist jetzt die Version 1.0.

Es fehlen noch eine Hilfe Datei so wie bei Windows, aber dafür habe ich mir schon den 'HTML Help Workshop' von Windows runtergeladen aber da muss ich mich erst mal noch rein denken.
Leider gibs den nur auf Englisch, aber wenn Ihr eine deutsch Anleitung habt wäre das nicht schlecht.
Desweiteren ist mir gerade noch eine Formularsteuerung eingefallen die ich noch "entwickeln" und testen muß.

Und wenn euch noch was Einfällt b.z.w. wenn sich einer findet der den Code sich mal anschaut vor langeweile.
Muß ich das ja auch noch Einbauen!

Ok zum Programm es wäre nicht schlecht, wenn Ihr zwei oder mehrere Benutzer (Administrator, User) auf eueren PC habt.
Mit dem Programm kann der Admin festlegen wie lange ein User den PC am Tag nutzen darf in Minuten z.B. 120 = 2Std. am Tag.
Für jeden Benutzer des PC kann die Zeit unterschiedlich eingestellt werden, der 16 jährige Sohn darf natürlich länger am PC wie die 12 jährige Tocher z.B.
Der User kann sich ruhig ab melden oder den PC runterfahren die verbrauchte Zeit wird gemerkt.
Ist die Zeit abgelaufen hat der User noch 30sek seine Programme zuspeichern b.z.w. zu schliessen.
Bis Dann

 

[Reverent]

Hallo Leute,
hat den ihr zu keiner was zu sagen
Bis Dann

[Edit]
Habe noch ein paar Fehler gefunden so eine sch...., und dabei dachte ich ich hätte schon alles getestet, also noch mal zurück zum Zeichenbrett!
Bis Dann

 

[Reverent]

Hallo Leute,
erstmal ein großes Entschuldigung mit dem Thread 'Interface' und DANKE trotzdem für die Antworten.
Zu meinem Programm PC-Time einige Fehler habe ich noch beseitigen können, die lagen aber mehr auf der logischen Seite.
So weit funktioniert es jetzt.
Weiter mit den Sachen die Ihr mir hier so gesagt habt was OOP angeht, irgend wie muss der Groschen da bei mir noch fallen und da auch ein DANKE für die Unterstützung.
Ich habe mir öfters mal diesen Thread:
MS-Access-DB ohne ODBC einbinden?
durch gelesen.
Ich bin da echt von Fasziniert und von der letzten Seite besonders.
Wenn ich das da lese dann denke ich, mein Wissen über Programmierung ist doch nur der Tropfen auf dem heißen Stein.
Da denkt man macht was Cooles aber alles nur S...... na ja fast. Ich muss glaube ich noch viel viel viel viel viel viel lernen.
Ich weiss nicht ob es das gibt (bei Google nicht gefunden), aber so eine schematische Skitzze wäre nicht schlecht, über die drei Schichten siehe hier und wie das alles so mit dem Objekten zusammen spielt, aber ist ja auch egal.
Bis Dann
Ach wenn es jemanden Interessiert siehe Anhang

 

[chironex]

Zum Software Entwickler zu mutieren ist halt ein langwieriger Prozess. Du brauchst Interesse, einiges an theoretischem Wissen und dann Praxis, Praxis und nochmal Praxis.

Ist wahrscheinlich wie in jedem anderen Job auch.

Schau halt mal, ob Dich Deine Firma auf entsprechende Schulungen schickt. Wenn das nicht geht, dann gibt es ja noch Bücher wie zum Beispiel von Heide Balzert das "Lehrbuch der Objektorientierung". Als Einsteigerwerk dürfte es ganz gut geeignet sein. Es wird an verschiedenen FH's verwendet und ich habe es auch schon bei einigen Gurus verstaubt rumstehen gesehen Datenbankwissen kann auch nicht schaden, aber da weiss ich nicht wirklich einen Tipp für Dich. Ich habs mir im Lauf der Jahre mit der Hilfe zum SQL-Server beigebracht, was aber eher die harte Tour war.

 

[Reverent]

Hallo chironex,
Praxis die hätte ich gerne und ein Arbeitgeber der mich auf Schulungen schickt auch.
Aber das mit den Arbeitgeber ist so ne Sache, aber das ist ein anderer Thread.
Ich schaue mir gerade das 3 Tier Schema an, und dann lese und lese und lese ich dann kommen so Sachen wie
Frontend <-> Emissaries <-> Executants <-> Backend
Frontend <- Methoden und Properties -> Emissaries
Emissaries <- XML -> Executants
Executants <- IDA -> Backend
oder

Zitat von Dipl.-Inform. Marcus Warm
Zwischen den Executants und dem Backend können Daten mittels DAO oder ADO ausgetauscht werden. Bei älteren Projekten ist dies oft noch DAO, bei neueren verwendet man ADO. Um unabhängig von Änderungen bei ADO & Co zu sein, bin ich der Meinung, daß man die Datenbankzugriffsobjekte kapseln sollte. Also eine selbst erstellte Schale darum legen. Denn beim Datenbankzugriff - egal welche Datenbank - egal ob DAO oder sonstwas - geht es immer um dasselbe. Es wird irgendeine SQL-Abfrage geschickt, die z.B. Datensätze löscht oder selektiert. Im letzteren Fall kann man diese durchlaufen und die Feldinhalte abfragen. Meine Schale heißt IDA (Independent Database Access). Sie kapselt gleichermaßen DAO wie ADO. Warum noch DAO? Meine Projekte laufen derzeit noch unter DAO. Die Umstellung auf IDA steht mir noch bevor. Ist die Umstellung abgeschlossen, so ist der Wechsel auf ADO sehr einfach. Denn ich bleibe dann selbstverständlich bei IDA - ich tausche dann nur die IDA-DLL aus: von DAO-basiert nach ADO-basiert. Ein DAO-nach-ADO-Wechsel von größeren Projekten an einem Tag! Die ständigen Änderungen der Datenzugriffsklassen seitens Microsoft können mich dann nicht weiter jucken. Ich pass einfach IDA an und kann die neueste Datenzugriffstechnologie nutzen.

3 Tier Architektur

Und das ist alles noch Harter Tobak für Mich.
Am liebsten wäre mir wenn ich sowas mit jemanden zusammen machen könnte z.B. ein Datenbankprojekt (liegt ja nahe) was man dann gemeinsam programmiert, um gemeinsam zulernen.
Muß ja von der Datenbankstruktur nichts großes sein so ich sag mal 5-10 Tabellen und es dann mal mit allen "Techniken" so richtig auf die Spitze treiben.
Um nachher auch mal die DB aus tauschen z.B. von Access nach MySql oder mal das Frontend austauschen u.s.w.
Damit man mal so ein Beispielprojekt hat. Ich würde mich freuen, wenn sich da jemand finden würde. Ich möchte nur lernen, alleine lernen finde ich nicht so cool, am liebsten zu Zweit oder zu Dritt.
Bis dann und gute Nacht Ihr alle da Draußen!

 

[chironex]

Überleg Dir halt mal ein einfaches Beispiel. lass für den Anfang Benutzerverwaltung und Berechtigungssystem weg. Das belastet nur. Fünf bis zehn Tabellen hast Du schnell zusammen. Mach Dir dann Gedanken zum DAL, also Deiner Abbildung der relationalen Daten auf Objekte und setz darauf einen Business Layer auf. Mach Dir Gedanken, was Du zu ändern hättest, sollte sich zum Beispiel der Name des Datenbankservers ändern. Wo müsstest Du den überall ändern? Darf eigentlich nur eine einzige Stelle sein! ;-) Schau Dir auch an, was Du brauchst um solche Konfigurationssachen zu ändern? Den Code ändern und neu kompilieren ist ganz schlecht, sowas gehört am besten in XML-Konfigurationsdateien.

Ob Du es richtig gemacht hast oder nicht siehst Du, wenn Du eine Weboberfläche und eine Windows Forms Anwendung schreiben kannst, die auf die gleichen Business Objekte zugreifen können. An Deiner Stelle würde ich gar nicht soviel zu dem Thema lesen, da Dich das anfangs sowieso nur verwirrt. Ich bin da mehr der explorative Typ. Schau Dir halt mal an, was Du so alles mit abstrakten Klassen, Interfaces und Vererbung machen kannst. Damit hast Du ein bissl Rüstzeug um ein einfaches kleines Projekt anzugehen.

Ich hoffe, das hilft Dir ein bissl fürs Erste.

 

[Christian Kusmanow]

Hallo Reverent!

erstmal ein großes Entschuldigung mit dem Thread 'Interface'

Ich muss auch sagen das ich ziemlich grob zu Dir war und entschuldige mich.
Aber ich sehe es hat doch was gebracht.
Lass Dich nicht unterkriegen. Und lass deiner Neugier freuen lauf.

Am liebsten wäre mir wenn ich sowas mit jemanden zusammen machen könnte z.B. ein Datenbankprojekt (liegt ja nahe) was man dann gemeinsam programmiert, um gemeinsam zulernen.

Ich hätt mich damals auch noch nicht allein an sowas rangetraut.
Es brauch wirklich ein gutes Verständniss für die OOP sowas anzugehen.
Du musst wissen das dieses technik darauf aufsetzt und sowieso IMO nie
ohne die OOP möglich währe.
Hast dich schonmal mit dem Entitiy-RelationShip-Model (ERM) beschäftigt?
Ist eine wichtige Grundlage zum Verständniss des Aufbaus einer DB.
Urschleim quasi.

Versuch doch erstmal kleiner Projekte anzugehen und diese auch richtig abzuschließen.
Damit Du ein besseres Vertändniss für die Dinge ansich bekommst.
Ich denke damit überforderst Du dich nicht so und kannst Dir gleichzeitig mehr Feinheiten aneignen.
Irgendwann wirst Du dann wie ich "das Bedürfniss" haben, endlich mal "was großes"
zu entwickeln. Dann hast Du die Vorraussetztungen und es wird Dir echt leichter fallen
und 100%ig sogar Spaß machen dein Wissen gekonnt einzusetzen.

MfG, cosmo