![]() |
Zitat:
Probier ich morgen, wenn ich wieder in der Arbeit bin. |
Es geht wirklich so einfach. Du hast nur verabsäumt dem Variant Formular2 zu sagen wer und was er ist :D
In deinem Code ist Formular2 nämlich wirklich nur ein nicht befüllter Variant (Zum Glück gibt's den Datentyp in .NET nimma). Dein Code: ------------------------------------------- DoCmd.OpenForm "Formular2", , , , , , "" Formular2.test = "hallo" ------------------------------------------- Versuch's mal so: ------------------------------------------- Dim Formular2 As Access.Form DoCmd.OpenForm "Formular2" set Formular2 = Application.Forms.Item("Formular2") Formular2.test = "hallo" ------------------------------------------- 0der als Kurzfassung: ------------------------------------------- DoCmd.OpenForm "Formular2" Application.Forms("Formular2").test = "hallo" ------------------------------------------- |
Wieder mal ein großes Merci an euch beide (flinx und Seidl) :hallo:
Public test as string und dann im 1. Form den Code vom Seidl, und es geht 1A. Aber eines noch: (@Seidl) falls du dazu kommst, könntest du ev. kurz "ausführen" wie du das mit der Klasse gemacht hättest? Brauchst mir jetzt keine Klasse bauen, nur kurz in Worte fassen, wie du das gemacht hättest (rein aus interesse) :rolleyes: :) Also nochmal danke, wünsch euch noch einen schönen (Arbeits-)Tag. |
Für eine Variable allein würde eine Klasse auch keinen Sinn machen. Sinnvoll würde sowas z.B. dann, wenn mehrere globale Variablen von mehreren Formularen aus gelesen und geschrieben werden sollen und sich dabei gegenseitig beeinflussen (kommt auch vor).
In so einem Fall wären die Variablen als private Members einer Klasse gut aufgehoben. Wenn z.B. Recordsets dabei sind, dann kannst du die im Initialize der Klasse setzen und im Terminate wieder vernichten. Die Änderungen an Variablen könnte man dann über Methoden oder Properties (property set) der Klasse definieren. Dadurch würde jede Änderung an den Variablen, egal von wo sie ausgeht, den richtigen Ablauf von nötigen Änderungen durchlaufen. Man kann dann nicht mal versehentlich eine der Variablen ändern ohne die von ihr abhängigen anderen zu berücksichtigen. Ausgelesen würden die Variablen dann natürlich über property get. |
hui - das wirft ja wieder viele Fragen auf... ;)
Zitat:
Zitat:
dim neueInstanz as Klasse set neueInstanz = new Klasse? terminate? set neueInstanz = nothing? Zitat:
hmm, ich glaub ich brauch doch eine Beispielklasse von dir... Mit Methoden versteh ichs ja noch. Man macht globale Variablen in der Klasse (mit Dim im "Kopf" des Klassenmoduls) Und in die schreib bzw. lese ich dann mit Prozeduren/Funktionen - right? Aber Property set/get? Von dem hab ich noch nicht wirklich was gehört. Naja, ich hoff ich geh dir nicht zu sehr am Geist, aber vielleicht findest ja mal Zeit. ;) Und ich dank dir auf alle Fälle schon einmal für deine Ausführungen. Denn wie du siehst, bin ich nicht sehr bewandert was Klassen betrifft und hab sie eigentlich bis auf eine Ausnahme noch nicht verwendet. (obwohl ma sicher sooo viel damit machen kann) |
Mit Klassen kannst du eigentlich auch nicht viel mehr machen als ohne. Es geht nur um das gedankliche Modell mit dem man übersichtlicher und weniger fehleranfällig programmieren kann. In der wirklichen Welt abstrahieren wir ja auch zu einfachen Denkmodellen. Wer kümmert sich schon darum was in einem Auto vorgeht wenn man auf's Gas tritt? Es gibt eben das Auto und die Möglichkeit auf's Gas zu treten, was zur Folge hat das man schneller wird. Man muss das Auto dazu nicht verstehen und es ist im Prinzip komplett austauschbar, solange jedes der Autos ein Gaspedal hat.
Ich hänge dir eine gezippte Access-Datenbank an in der ich eine Kreis-Klasse und ein kleines Modul in dem sie verwendet wird geschrieben habe. Natürlich ist die Klasse eigentlich komplett sinnlos aber wenn's nur darum geht mal sowas zu sehen, wird es schon reichen. Allerdings muss ich dich darauf hinweisen, dass meine Theorie auch schon ein wenig eingerostet ist. ;) Ich würde dir auf jeden Fall empfehlen ein wenig über das Prinzip der objektorientierten Programmierung zu lesen. Wenn man das richtig einsetzt kann es sehr viel Arbeit sparen. Der Code wird leichter wiederverwendbar und kann einfacher ausgetauscht werden. Wenn du mit anderen Programmierern zusammenarbeiten musst wirst du ohnehin nicht drum rum kommen. |
Danke!
Von der allg. Theorie kenn ich mich eh aus. (Klassen, Instanzen, Methoden, ....) Und das mit der Abstraktionsweise usw. - ist mir bekannt. (ein bissl lernt man ja in der Schule auch) Nur habe ich es eben noch nie IRL verwendet (verwenden müssen). Und der springende Punkt ist eben, den du angesprochen hast, es wird übersichtlicher. Nur die "rohe" Theorie bringt mir halt net viel, ohne sowas mal zu programmieren, bzw. genau zu wissen, wie ich die einzelnen Klassen entwerfen kann und was es dafür für "Eigenheiten" der Programmiersprache gibt. Ich werd mir dann dein quasi Lehrbuchbeispiel, zumindest der Name lässt darauf schließen, anschaun. Und da werd ich schon sehen, wie das in VB funktioniert. :) mfg, LLR |
Eine Klasse für einen Kreis habe ich wirklich schon öfter als Beispiel für Klassen gesehen. Ich fürchte, das wird aber so ziemlich alles sein, was mein Beispiel mit einem Lehrbuch verbindet :D
Sehr beliebt ist auch das Beispiel Bankkonto. Dazu ist mir aber nicht viel anschauliches eingefallen. Tja, ich werd' langsam vergesslich und doof. |
Zitat:
Es war auch kein Lehrbuch, sondern eine haufen Zettel, die von einem Univ. Prof. geschrieben wurde, der bei meiner (alten) Schule unterrichtet (hab ihn aber leider nicht gehabt) Dort warens Kreise, Dreiecke und Rechtecke/Quadrate... Und so viel wie du weißt, glaub ich nicht, dass du doof wirst. :) :hammer: |
So jetzt hab ich mir grad deine Beispielklasse angesehen - das war genau das was ich gebraucht habe. :D
Jetzt weiß ich endlich, was man wie wo in VB machen kann. ;) 2 kurze Fragen hab ich noch: die Procedure "Class_Initialize()" wird nehm ich an ausgeführt, sobald man eine Instanz der Klasse erstellt - richtig? und "Class_Terminate()" wird ausgeführt wenn man die Instanz = nothing setzt bzw. der Code zu Ende ist - right? Und ich denke, die werden immer so heißen, wurscht welchen Namen die Klasse erhält. Ups, jetzt warens doch 3 Fragen. Das nächste is eigentlich noch was, was nicht direkt zur Klasse gehört: was machst du mit dem Recordset und den 2 "Prozeduren": Code:
Property Set Data(Data As ADODB.Recordset) BTW: kann man eigentlich "Sub-Klassen" definieren, die dann Eigenschaften/Methoden etc. von der Parent-Klasse erben? Nochmals herzlichen Dank. :) |
Alle Zeitangaben in WEZ +2. Es ist jetzt 13:39 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag