eigenes Control - Näherungsschalter

[das-d]

Hallo,
ich beginne demnächst mit einem Projekt, bei dem eine Anlage am PC simuliert wird. Somit ist es möglich ein Programm für eine Speicherprogrammierbare Steuerung schon am Computer zu testen. Man benötigt also keinen Modellaufbau. Das testen des Programms läuft in einer schon bestehenden Software auf die ich per Schnittstelle zugreifen kann.

Nun hab ich mir überlegt zum Beispiel ein Usercontrol anzulegen welches einen Näherungsschalter immitiert. Sprich ein Sensor der zwei Zustände kennt 1 und 0 ;-) Dieser Näherungsschalter reagiert ja auf seine Umwelt sprich alles was ihm vor die Nase kommt soll er erkennen.

Dazu hätte ich jetzt jedoch eine Frage. Ist es möglich das ganze irgendwie zu Automatisieren. Heißt dass ich beispielsweise dafür sorge dass sobald das Control in der Form ist und zum Beispiel gestartet wird. Selbständig seine Umgebung absucht, und bei Bedarf ein Ereignis auslöst.
Ereignisse programmieren hab ich schon was gefunden. Jedoch weiß ich noch nicht wie ich des Absuchen gestalten soll. Denn wenn ich jetzt einfach alle Controls aus der Parent.Control Liste durchgehe kann ich mir ja nicht sicher sein ob es stimmt. Denn angenommen mein Sensor liegt auf einer Picturebox welche den Hintergrund darstellt um es alles ansprechend aussehen zu lassen. Dann würde diese Picturebox auch in "Reichweite" sein und mein Sensor angehen.


Hat jemand eine Idee wie ich dieses Problem angehen kann?

Mit freundlichen Grüßen
Daniel

[gfoidl]

Hallo,

in der Spieleprogrammierung ist das eine gängige Aufgabe -> Suche in diesem Bereich über Infos bzw. Musterlösungen

mfG Gü

[das-d]

diese Idee hatte ich auch schon. Nur leider noch nichts dazu gefunden. Aber dann weiß ich jetzt schonmal dass ich an der richtigen Stelle suche. Danke schonmal. Falls doch noch jemand etwas weiß dann bitte melden ;-) =)

Danke Gü

[gfoidl]

Nochmals Hallo,

die Rectangle-Struktur stellt die Methoden Intersect und IntersectsWith bereit. Vielleicht helfen diese weiter.

mfG Gü

[das-d]

so ich denke ich weiß jetzt wie ich es mache. Im Endeffekt werde ich auch nicht drum herum kommen im Programm eine Liste zu führen die alle Objekte beinhaltet die Kollidieren können oder auf einander reagieren sollen.
Vielleicht sollt ich meine Klassen dann von der Rectangle Klasse erben lassen. Mal sehen bin mir doch noch sehr unschlüssig über die Herangehensweise, aber ich weiß dass nichts dabei rauskommt wenn ich einfach adhoc anfange.

[das-d]

Weiß jemand wie das ist wenn ich dem Konstruktor einer Klasse per ByRef eine Variable mitgebe. Ist der Wert dieser von außen angelegten Variable dann während der ganzen Instanz ByRef verfügbar? Oder nur solang der Konstruktor "läuft"?

Habe es nun ausprobiert, scheinbar bleibt die Variable nicht ByRef verfügbar. Nun ich habe ja bereits eine Klasse als Schnittstelle welche mir die Kommunikation zum Simulationsprogramm verschafft. Nun ich werde jetzt wohl mehrere Klassen schreiben, welche dann Sensoren und Aktoren beschreiben. Ich dachte mir dass ich die einfach von der Schnittstellenklasse erben lasse.
Ich habe dann aber ein Problem dann muss ich für jeden Sensor oder Aktor den ich einsetze eine eigene Verbindung zum Simulationsprogramm aufbauen.
Muss ich jetzt um eine Verbindung nur einmalig aufzubauen, da noch eine ganze Klasse reinhängen? Denn die Verbindung ByRef mitzugeben scheint ja auch nicht zu funktionieren.
Ich hoffe ihr wisst was ich meine.

[gfoidl]

Hallo,

die Verbindung zum Simulationsprogramm kann 1x in der Basisklasse implementiert werden. Alle anderen Klassen erben von dieser.

Der Konstruktor der Basisklasse wird immer aufgerufen (bevor) der Konstruktor der jeweiligen Klasse aufgerufen wird. Schau mal in der MSDN unter diesem Thema.

Zur Verweisübergergabe: Der Verweist ist so lange "gleich" bis er neu zugewiesen wird oder auf null gesetzt wird. In deinem Beispiel vom letzten Post probier mal das OUT-Schlüsselwort.

mfG Gü

[das-d]

Das mit der Verbindung implementieren wäre nicht das Problem. Aber wenn die Sache mal läuft will ich nicht für jedes Objekt das simuliert wird eine seperate Verbindung aufgebaut wird. Damit ich das nicht muss würde warscheinlich eine Shared Deklaration der Schnittstellenklasse reichen oder? Dann würde jedes Objekt auf die selbe Klasse, die diese Schnittstelle bietet zugreifen. Somit auch alle über die eine Verbindung laufen?



Zu der Byref zuweisung nochmal:

Das hier wäre meine Testklasse:
[highlight=vb.net]
Public Class test
Dim merker As Boolean

Public Sub New(ByRef wert As Boolean)
merker = wert
End Sub

Public Function change_val() As Boolean
merker = Not merker
End Function

Public ReadOnly Property value()
Get
Return merker
End Get
End Property
End Class
[/highlight]

Nun habe ich diesen Test durchgeführt:
[highlight=vb.net]
Public Class Form1
Dim merkerer As Boolean
Dim tester As test

Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
merkerer = False
tester = New test(merkerer)
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
tester.change_val()
Me.CheckBox4.Checked = Me.merkerer
Me.CheckBox5.Checked = Me.tester.value
End Sub
End Class
[/highlight]
Wenn ich jetz Button1 betätige ändert sich Checkbox5 erwartungsgemäß bei jedem Click. Mit Checkbox4 funktioniert dies leider nicht :-(

[gfoidl]

Zu deinen Testklassen:
CheckBox4 kann den CheckedState nicht ändern da der Wert von merkerer immer der selbe ist (false).
Der merker-Wert in der Klasse ist unabhängig davon -> eigenes Objekt.

Zur Verbindung:
Shared ist icht nötig -> siehe meinen letzten Post. Die Basisklasse wird für jede Instanz der davon abgeleiteten Klasse selbst instanziiert.
Somit kann alles was für alle Objekte der Simulation gilt in der Basisklasse definiert werden.
Zur Laufzeit ist dann jedes Objekt das von der Basisklasse erbt auch gleichzeitig eine Instanz der Basisklasse und somit kann dieser Code ausgeführt werden.
Nähere Infos zur Vererbung zB bei http://openbook.galileocomputing.de/...e2aba44fc532e8.
Diese Vorgehensweise erleichtert die Arbeit sehr.

Anmerkung:
VB.net-Code kann mit [highlight=vb.net]dein Code[/highlight] formatiert werden.

mfG Gü

[das-d]

Zum Vbnet code ding danke, hab das grade gesucht. vor ein paar Tagen gelesen aber wieder vergessen ;-)

Ja des war ja mein Problem ich dachte ob die ByRef sozusagen vielleicht bestehen bleibt ;-) aber das ist nicht so schlimm, da hab ich ja jetzt eine neue Lösung ;-)

Ja ich weiß was du meinst. Aber somit wird jedes meiner Objekte eine Instanz meiner Basisklasse. Und auch jedes dieser Objekte würde anhand der Methoden der Basisklasse für sich eine eigene Verbindung aufbauen. Und dass will ich nicht. Ich will nur ein einziges mal eine Verbindung aufbauen und diese für alle meine Objekte nutzen. Falls das mit deiner Möglichkeit auch ist, hab ich ja einen großen Fehler gemacht in meinem Wissen über Vererbung von Klassen.



Vererbung
Hab mir das jetzt nochmal durchgelesen. Das was ich haben will. Wäre also demnach eine Static Referenz auf die Schnittstelle zu meinem Simulationsprogramm. Ich wäre daher unabhängig von den Objekten und würde immer auf die "gleiche Schnittstelle" zugreifen. Hätte diese demnach auch nur einmal im Speicher vertreten - ähnlich dem Ojbektzähler?! Richtig Verstanden?

[gfoidl]

Vererbung
Hab mir das jetzt nochmal durchgelesen. Das was ich haben will. Wäre also demnach eine Static Referenz auf die Schnittstelle zu meinem Simulationsprogramm. Ich wäre daher unabhängig von den Objekten und würde immer auf die "gleiche Schnittstelle" zugreifen. Hätte diese demnach auch nur einmal im Speicher vertreten - ähnlich dem Ojbektzähler?! Richtig Verstanden?

Static Referenz auf die Schnittstelle hab ich noch nie gehört. Vielleicht liegst daran dass das VB-spezifisch ist (ich komme von C#).

Wenn hingegen eine explizite Schnittstellenimplementierung gemeinst ist dann hast du teilweise richtig verstanden. Es wird nicht immer auf die gleiche Schnittstelle zugegriffen, sonder dein Objekt wird als Instanz dieser Schnittstelle "verstanden" -> dadurch kannst du auf alle Member die die Schnittstelle offenlegt zugreifen.

Ich hab mir (bisher) kein Konzept zur Kollisionskontrolle gemacht aber dennoch würde ich das Basisklassen-Prinzip verwenden, da alle Objekte eine gemeinsame Basis haben (müssen) und gleiche Eigenschaften und Methoden haben.

mfG Gü

[das-d]

das auf jeden Fall ja bei VB ist das was c# als static bestimmt meines Wissens shared. Dadurch lässt sich der Objektzähler realisieren, da ja diese Methode oder Eigenschaft für alle gleich ist. Es geht mir dabei weniger um die Kollisionskontrolle. Denn eine Mehrfachverbindung wäre durchaus möglich. Nur weiß ich nicht wie sich das auf die Gesamtperformance zum einen von meinem und zum anderen von dem Simulationsprogramm auswirkt.

Aber danke für den C# Link. Hab schon immer das .Net Buch für VB von Galileo hier aber ich meine das des mit den Klassen im C Buch besser beschrieben ist. Oder ich habs jetzt erst richtig verstanden ... oder aber ich habs damals schlicht zu schnell überflogen ;-)

Danke für diene Hilfe.
Bin dadurch heute wieder ein gehöriges Stückchen weiter gekommen und werd jetzt dann mal kleine Tests durchführen bevor ich mich an den ganz genauen Aufbau meiner Klassen mache.

[gfoidl]

Nur weiß ich nicht wie sich das auf die Gesamtperformance zum einen von meinem und zum anderen von dem Simulationsprogramm auswirkt.

Die Performance hab ich mit diesem einfachen Bsp mal getestet - ist zwar C# aber nichts besonderes:
[highlight=c#]
using System;
using System.Diagnostics;

namespace ConsoleApplication1
{
class Program
{
static void Main()
{
const int N = 10000;
Stopwatch sw = new Stopwatch();

sw.Reset();
sw.Start();
for (int i = 0; i < N; i++)
{
A a = new A();
for (int j = 0; j < N; j++)
{
a.DoSomething();
}
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);

sw.Reset();
sw.Start();
for (int i = 0; i < N; i++)
{
B b = new B();
for (int j = 0; j < N; j++)
{
b.DoSomething();
}
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);

sw.Reset();
sw.Start();
for (int i = 0; i < N; i++)
{
Foo foo = new Foo();
for (int j = 0; j < N; j++)
{
(foo as IInterface).DoAnything();
}
}
sw.Stop();
Console.WriteLine(sw.ElapsedTicks);
Console.ReadKey();
}
}

public class A
{
public void DoSomething()
{

}
}

public class B : A
{

}

interface IInterface
{
void DoAnything();
}

public class Foo : IInterface
{
void IInterface.DoAnything()
{
}
}
}
[/highlight]

Das Ergebnis sieht (erwartungsgemäß) so aus:


mfG Gü

[das-d]

Danke ich glaube ich weiß was du mir zeigen willst. Ich habe aber mehr gedacht dass es sich wohl vielleicht Negativ im Simulationsprogramm auswirkt wenn viele Objekte verbinden. Außerdem muss ich jede Verbindung schließen wenn ich mein Programm beende. Da sonst das Simulationsprogramm nicht beendet werden kann (es denkt es sind noch Verbindungen da, was ja theoretisch auch stimmt), deshalb ist es für mich schon einfacher in der Hinsicht da ich sagen kann ok ;-) ich schließe nur eine Verbindung.
Andererseits wäre das ja im Destruktor eines Ojektes auch nich falsch aufgehoben oder?

[gfoidl]

Ich versteh nicht warum du nur eine Verbindung hast?

Jedes Objekt sollte eigenständig sein (mit einer gemeinsamen Basisklasse, die die gemeinsamen Member hat). In deiner Anwendung sollten alle Objekte in einer Liste (oder einem Array) gespeichert werden. Mit dieser Liste führst du die Verwaltung der Objekte durch.

• Prüfen auf Kollisionen. Dazu hat jedes Objekt eine Eigenschaft deren Datentyp Point[] ist, denn somit kann die Form angegeben werden und einfach per Prüfung auf Geradenschnitte eine Kollision entdeckt werden
• Verbindung herstellen/trennen (was auch immer verbunden werden muss)

Diese zwei aufgeführten Punkte (natürlich erweiterbar) sind in der Basisklasse zu implementieren da dies für alle Objekte gilt.

Sollte ein Objekt zB ein Kreis sein ist es nicht sinnvoll den durch einen Polygonzug (Point[]) zu approximieren sonder als Kreis mit Mittelpunkt und Radius zu speichern. In diesem Fall müssen die Member der Basisklasse überschrieben werden um dies an den Kreis anzupassen.

Verstehst du was ich meine?

mfG Gü