Guten Morgen,

wie kann ich den aus einer Klasse den Status einer CheckBox auslesen ?

Ich habe in Form 1 eine CheckBox.
Nun möchte ich aus einer Klasse abfragen wie der Status ist. Checked

Bei Variablen geht das mit Public Shared ja einfach. Dann kann ich drauf zugreifen.
Wie geht das bei einem Control welches ich per Designer auf die Form gezogen habe.

CheckBox ist nur eins der Controls. Es sind noch einige mehr. Unter anderem auch ein Eigenes.

vielen dank

Bernd

Hallo Bernd,

bin mir nicht sicher ob ich genau verstanden habe was du willst.

Du hast eine Form und willst den Status der Checkbox aus einer Klasse heraus abfragen ?
Vermutlich liegt die Instanz der Klasse innerhalb der Form.

Gruss

mikeb69

Du könntest ein Control auch public machen, das funktioniert. Kann man sogar im Designer machen, ist aber nicht so die feine Art.

Du könntest eventuell eine Propertie anlegen, welche im Get-Teil den Status zurück gibt.
Oder du machst eine Methode isChecked, welcher du dann z.B. als string den Control namen übergibst, so könntest du über From.ControlFind(oder ähnlich) den Status jeder belibigen Checkbox auslesen.

Bin mir nicht sicher ob das die feinsten Lösungen sind, wenn nicht klärt mich bitte auf.
Funktionieren sollten sie alle mal.

lg.

warum nicht die vorhandenen Events nutzen ?
Wenn sich der CheckedState ändern --> boolean setzen / ruecksetzen
diese boolsche Variable kannst du dann als public declarieren.

mfg

mikeb69 schrieb:

Du hast eine Form und willst den Status der Checkbox aus einer Klasse heraus abfragen ?

Ja genau so ist es.

Vielleicht versuche ich das genauer zu erklären.

- Ich bastel grade eine neues Control
- Dort ziehe ich mehrere Controls aus der ToolBox und fange an zu basteln.
- Es sind einige Aufgaben zu erledigen. Je nach Event.
- Da ich da ganze ein wenig OOP machen möchte, brauche ich den Status der Control.
- Aus der Worker Klasse (nenne ich mal so) , die Instanziert wird, möchte ich den Status der Controls abfragen. um dann zu entscheiden welche Aktion ausgeführt werden soll
- Nach der Ausführen werden einige Controls dann per Invoke aktualisiert. Das klappt ja auch.



Vielleicht ist es so verständlicher.

Also auf Controls zurückgreifen und diese "verändern" geht ja mittels Delegate und Invoke.
Ich möchte nur den Status "abfragen". Ich möchte nichts verändern.

LucaWelker schrieb:

Du könntest ein Control auch public machen

Ja das war das erste was ich versucht habe. Da reagiert er aber nicht drauf.
Verweis auf einen nicht freigegebenen Member ........

LucaWelker schrieb:

Oder du machst eine Methode isChecked, welcher du dann z.B. als string den Control namen übergibst, so könntest du über From.ControlFind(oder ähnlich) den Status jeder belibigen Checkbox auslesen.

Nu sitze ich auf der Leitung.


Danke euch beiden

Wenn es immer noch unklar ist...... Ich laufe ja nicht weg.

Edit:

warum nicht die vorhandenen Events nutzen ?
Wenn sich der CheckedState ändern --> boolean setzen / ruecksetzen
diese boolsche Variable kannst du dann als public declarieren.

Puh,
genau das habe ich beim ersten versuch das neue Control zu schreiben versucht.
Jedoch tauchen dort zu viele Probleme auf.
Ich habe mehrere Controls und damit Hunderte von Events die ich berücksichtigen muss.
Das bringt dann jede Menge If then Else End If. Teilweise werden dann Events doppelt ausgeführt.
Beispiel:

Hier können die Handels zusammen geführt werden. Was aber wieder rum bedeutet. Diese Methode wird zweimal ausgeführt. Nun muss ich aufwändig und Unnötiger weise das doppelte Feuern abfangen.
Das ist unnötig und zuviel Aufwand.

Ist vielleicht nur eine kurze und knappe Erklärung.
Das habe ich aber alles schon durch. Das Projekt hat z.Z. mehr als 30.000 Zeilen. Genau wegen der doppelten arbeit.
Um es übersichtlicher zu halten, fange ich nochmals neu an. Mit anderen Mitteln und andere Wege.

Bin mir nicht sicher was du genau vorhast...
Aber um auf Änderungen von Controls zu reagieren, bzw deren Status abzufragen was das selbe ist bieten sich Events an.
Wenn sich der CheckedState einer CB ändert wird ein entsprechendes Event getriggert --> abonieren und entsprechend sender / Eventargs auswerten.

mcdt schrieb:

Aber um auf Änderungen von Controls zu reagieren

Ich möchte "nicht" reagieren.
Änderungen des Control sollen erst dann abgefragt und behandelt werden wenn ich sie brauche. Nicht zu der Zeit wenn sie sich ändern.


Bernd

Bernd schrieb:

Aus der Worker Klasse (nenne ich mal so) , die Instanziert wird, möchte ich den Status der Controls abfragen. um dann zu entscheiden welche Aktion ausgeführt werden soll

Das ist oft das Grundproblem des Programmdesigns: wie kommuniziert die Parent-Klasse mit den Childs, bzw. wie greifen diese auf benötigte Eigenschaften der Parent-Klasse zurück. Die reine Lehre ist klar: das Child bekommt die benötigten Parameter beim Aufruf mit, in Deinem Fall halt die Boole'schen Werte . Ein Setzen der Controls aus dem Child heraus sollte garnicht erfolgen, sondern es sollten Events ausgelöst werden auf die die Parent Klasse reagiert.

Jetzt wissen wir etwas zu wenig über Deine 'Worker'-Klasse: arbeitet sie überhaupt mit Threads / ist Threading hier überhaupt nötig /sinnvoll ?

Ein paar andere Überlegungen:

• Wenn die Worker-Klasse sehr eng mit den Controls der Form verwoben ist, und Du nur aus Platz-/Übersichtlichkeitsgründen eine Worker-Klasse benutzt: verwende lieber eine 'Partial Class' um den Code (z.B. Threading) in eine andere .vb Datei auszulagern. Das ist sauber und Du hast keine Probleme mit Übergaben/Rückmeldungen, da Du ja noch innerhalb der Klasse arbeitest.
  
• sollte das aus irgendwelchen Gründen nicht gehen, so würde ich versuchen möglichst auf das Event-Modell zu gehen: Child-Klassen sollten nicht im Code der Parents rumfuhrwerken
  
• brauchst Du in der Worker-Klasse viel Zustände der Parent-Form, kannst Du diese auch im Construktor der Worker-Klasse als Referenz mitgeben:
  
  

  VB.NET-Quellcode

  1. Public WorkerClass
  2. Private pForm as Form1
  3. ' Construktor
  4. Public Sub New (parentForm as Form1)
  5. pForm=parentForm ' parentForm sichern
  6. end sub
  7. ...
  8. End class
  
  Damit hast Du vollen Zugriff auf die Parent-Controls. Nicht so unbedingt schön, aber Microsoft macht es ja selber bei einigen Klassen vor.
  

Kangaroo schrieb:

brauchst Du in der Worker-Klasse viel Zustände der Parent-Form, kannst Du diese auch im Construktor der Worker-Klasse mitgeben:

Hei Kanguru,
genau das ist ja mein Problem. Ich brauche sehr viele Zustände in der Worker-Klasse.


Das ist mir neu. Das werde ich mir mal ansehen.
Danke Dir

Warum ist das unsauber ?

bernd

Änderungen des Control sollen erst dann abgefragt und behandelt werden wenn ich sie brauche

Und wann / wie soll das geschehen ?
Willst du eine "Refresh" Methode erstellen, bei deren Aufruf dein Control aktuelisiert wird ?
Ich glaub ich habe den Problem nicht ganz verstanden.

Bernd schrieb:

Warum ist das unsauber ?

Weil damit WorkerClass untrennbar an Form1 gekoppelt ist: WorkerClass ist nicht kompilierbar, ohne dass auch Form1 kompilierbar ist.
(Übrigens in dieser extremen Art führt Microsoft derlei Kopplungs-Desaster nirgends vor, soweitichweiß)

Da kannste das working der WorkerClass ebensogut auch gleich im CodeBehind von Form1 machen - evtl. inne partiale Class, wie Kangaroo ausführt.

Aber IMO brauchen wir viiel mehr Infos.

Verstehe ich richtig: Du willst ein UserControl basteln?

Warum?

Wie soll es heißen (bitte nicht "SuperControl") - Was soll der Concern dieses UserControls sein?

(Bitte alle Fragen beantworten)

Beim Aufruf der Klasse kannst du dir dann Checkboxen und CO rückgeben lassen, oder wie ich hier auch Sachen übergeben

bastimw schrieb:

Beim Aufruf der Klasse kannst du dir dann Checkboxen und CO rückgeben lassen, oder wie ich hier auch Sachen übergeben

Das würde dann so aussehen

Nö, ist mann dann doch zu unübersichtlich. Zumal der Aufruf aus mehreren Events geschehen kann.

ErfinderDesRades schrieb:

Weil damit WorkerClass untrennbar an Form1 gekoppelt ist:

Das währe dann eigentlich kein Problem. Die Klasse ist ja für die Form da. Halt nur für verschiedene Einsatzbereiche.

ErfinderDesRades schrieb:

evtl. inne partiale Class

Genau das kenne ich noch gar nicht.

ErfinderDesRades schrieb:

Verstehe ich richtig: Du willst ein UserControl basteln?

Ja !

ErfinderDesRades schrieb:

Warum?

Weil es das in der Form nicht gibt.

ErfinderDesRades schrieb:

bitte nicht "SuperControl"

nein keine Angst.
Es soll dann SuperControl2012 heißen.

ErfinderDesRades schrieb:

Aber IMO brauchen wir viiel mehr Infos.

- Das was die Worker-Klasse machen soll, ist halt abhängig von den einstellungen der Controls.

Beispiel:


So das ganze dann mit ganz vielen Variationsmöglichkeiten.
Das wiederum bedeutet ganz viele If denn Else bzw. Select Case.
Und weil es so viele Möglichkeiten gibt.....

Um mir aber die Arbeit zu ersparen ist es einfach, erst wenn die Worker-Klasse arbeiten soll, die Hand Voll Controls abzufragen und dann die Richtige Sub aufzurufen.

Wie gesagt bei der Parent-Form gibt es zu viele Events die dann unnötigerweise gefeuert und abgefangen werden müssen.
Das Control war eigentlich ( außer einige Kleinigkeiten) schon fertig, aber leider zu anfällig.
Somit auch nicht sauber bzw. unzuverlässig.
Darum möchte ich das in der Art machen wie hier beschreiben. Weil ich mir dann weniger Probleme erhoffe.

Danke
Bernd

ErfinderDesRades schrieb:

Aber IMO brauchen wir viiel mehr Infos.

hmm, wir machen hier kein Design-Review, sondern nur Vorschläge zum Datenaustausch zwischen Parent/Child Klasse. Alles andere würde imho zu weit gehen. Ausserdem lernen wir wohl alle am meisten aus den Dingen die wir falsch machen, so bleibt dann ja Raum für das SuperControl2013

Eine Worker-Class die Zugriff auf die Parent-Form hat, habe ich Dir ja im o.g. Codeschnipsel gezeigt. Angelegt wird die Klasse dann halt mit

Zum Thema Partial Class: wenn der Code für 1 Klasse zu unhandlich / zu gross wird, so möchte man zur besseren Strukturierung oft Code in eine zusätzliche Datei auslagern, - aber möglichst ohne eine neue Klasse anzulegen. Das geht in VB.NET über die Deklaration 'Partial Class':


Insofern kannst Du also eine Datei Form2.Threading.vb anlegen und den ganzen Code der das Threading betrifft hier auslagern. Der Compiler führt nachher alles zusammen. Gleiches macht Visual Studio übrigens mit den Definitionen im Designer, diese werden alle in die Datei (normalerweise ausgeblendet) Form2.Designer.vb ausgelagert.

Wenn Du vor der Wahl stehst, Worker-Klasse oder Partial Class: gibt es bei Dir nur 1 WorkerClass , so nimmst Du besser die Partial Class.

Kangaroo schrieb:

gibt es bei Dir nur 1 WorkerClass , so nimmst Du besser die Partial Class

Das werde ich ebenfalls nun ausprobieren.

Sorry ich bin nicht der große Theoretiker, liegt an meiner LRS.

Ich mache jetzt mal mit den aussagen von Kangaroo einige versuche.
Dann Blicke ich meist schneller durch.


vielen dank an alle die mir hier geholfen haben.

Wenn ich dann immer noch nicht weiter komme melde ich mich wieder.
Ich lasse den Thread nochmal auf.

Danke

Bernd

Kangaroo schrieb:

hmm, wir machen hier kein Design-Review

hmm - im Forum schwätz ich grundsätzlich immer daher, wassichgrad am wichtigsten finde - ob das nun das Design betrifft oder den Datenaustausch, oder das Design des Datenaustauschs oder whatever.

Aber da meine Fragen nur insoweit beantwortet wurden, dass das SuperControl gecodet werden soll, weil es das noch nicht gibt, und sein Concern nicht weiter definiert ist, binnich draußen.

ErfinderDesRades schrieb:

und sein Concern nicht weiter definiert ist,

Es geht sich ja um die Frage:
wie frage ich den Status eines Controls, aus einer Klasse ab ?

Wenn du aber mehr Informationen haben möchtest, weil deine Neugierde dich nicht in ruhe lässt, kannst du mich gerne per PN anschreiben. Dann bekommst du von mir eine genauere und aussagekräftigere Beschreibung. Warum nicht !

Aber ich glaube wenn jeder TE hier erstmal sein Vorhaben ausgiebig beschreibt, werden die Threads zu lang und aufwändig. Der der es schreibt benötigt viel Zeit. Die es Lesen haben dann vermutlich keine Lust mehr soviel zu lesen.

kein Problem, ich bin für jeden Spass zu haben.

danke

Bernd

Bernd schrieb:

ErfinderDesRades schrieb:

und sein Concern nicht weiter definiert ist,

Es geht sich ja um die Frage:
wie frage ich den Status eines Controls, aus einer Klasse ab ?

Dassis kein Concern.

Mit "Concern" ist der Zweck, oder auch die Zuständigkeit einer Klasse gemeint.
Und wenn von einer Klasse nicht bekannt ist, wofür sie ühaupt gut sein soll, dann kann man rein garnix dazu sagen.

Aber ich glaube wenn jeder TE hier erstmal sein Vorhaben ausgiebig beschreibt, werden die Threads zu lang und aufwändig. Der der es schreibt benötigt viel Zeit.

Sehe ich gegenteilig:
Grad weil man den TEs immer die Infos sowas von ausse Nase ziehen muß werden die Threads mitunter 20 poste lang und länger.

Gewissermaßen eine Variante des Quick & Dirty - Effekts: Schnell die Frage hingeschmissen, und dann tagelang dran ausbessern.

Kangaroo schrieb:

hmm, wir machen hier kein Design-Review, sondern nur Vorschläge zum Datenaustausch zwischen Parent/Child Klasse. Alles andere würde imho zu weit gehen.

Ich sehe das wie Kangaroo. Eigentlich ganz einfach.

Entweder reden wir aneinander vorbei, oder ich habe ne Blockade.

sorry, ich will hier keinen verärgern oder kitisieren. (wie schreibt man das nu wieder, wir rot unterringelt)

Bernd

Hi Bernd, ich hab mal diesen Thread überflogen.
Grundfrage ist immer: Wer ist Master, wer ist Slave.
Bei mir wäre die Hauptform der Master, also tut er Änderungen kund.
Der Slave reagiert darauf.
Du willst viele Infos rüberreichen, da sehe folgende Möglichkeit.
Jedes einzelne Datum hat seine Kennung (ein Enumber) und bei Änderung eines Zustandes wird ein Event gesendet, das das Enum und den Zustand enthält.
Der Slave wertet aus und speichert die Information und verarbeitet, wenn es soweit ist.