Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

Wunderbar, TreeView steht auch erst an zweiter Stelle.
Das I AM noch nicht gefragt ist passt mir auch gut in den Zeitplan.
Woran ich starkes Interesse habe ist Die Option mit einem Client was zu senden was der Server dann Broadcastet. Mir wäre es sogar recht wenn der auf einem anderen Port sendet, dem Simulantenport.
Aber unterschiedlicher Port ist nicht Hauptsache.
Das ganze brauche ich für Mapbuilding Versuche und zur allgemeinen Netzaustestung.
Des Weiteren soll da später auch ein Datenbank Client senden können.

Durchleitung:
Alter Server:
Message Länge: 8Bytes 0 0 130 3 252 2 0
0
0
130
3
252
2
127
Message Länge: 8Bytes 0 0 130 2 150 0 0
0
0
130
2
150
0
22
Message Länge: 8Bytes 0 0 130 5 71 3 0
0
0
130
5
71
3
195
Message Länge: 8Bytes 0 0 130 6 69 3 0
Message Länge: 8Bytes 0 0 130 1 254 0 0
Message Länge: 8Bytes 0 0 130 0 64 1 0
Message Länge: 8Bytes 0 0 130 3 144 0 0
Message Länge: 8Bytes 0 0 130 7 255 3 0
Message Länge: 8Bytes 0 0 130 5 25 0 0
Message Länge: 8Bytes 0 0 130 2 21 1 0
Message Länge: 8Bytes 0 0 130 4 98 1 0
Message Länge: 8Bytes 0 0 130 6 60 2 0
Message Länge: 8Bytes 0 0 130 1 8 1 0
Message Länge: 8Bytes 0 0 130 5 232 2 0
Message Länge: 8Bytes 0 0 130 0 10 2 0
Message Länge: 8Bytes 0 0 130 3 96 1 0
Message Länge: 8Bytes 0 0 130 2 194 1 0

-Neure Server:-------------------------------------------------------------
Message Länge: 8Bytes 0 0 0 0 254 0 0
0
0
0
0
254
0
125
Message Länge: 8Bytes 0 0 0 0 76 3 0
0
0
0
0
76
3
202
Message Länge: 8Bytes 0 0 0 0 89 1 0
0
0
0
0
89
1
216
Message Länge: 8Bytes 0 0 0 0 28 1 0
0
0
0
0
28
1
159
Message Länge: 8Bytes 0 0 0 0 47 3 0
Message Länge: 8Bytes 0 0 0 0 0 0 0
Message Länge: 8Bytes 0 0 0 0 53 0 0
Message Länge: 8Bytes 0 0 0 0 252 0 0
Message Länge: 8Bytes 0 0 0 0 66 1 0
Message Länge: 8Bytes 0 0 0 0 39 0 0
Message Länge: 8Bytes 0 0 0 0 60 1 0
Message Länge: 8Bytes 0 0 0 0 196 1 0
Message Länge: 8Bytes 0 0 0 0 184 2 0

Netter Gruß

Ps. Danke für die Spielsachen, immer gern genommen.

ei, mir schwant ja schon der Graus'

Anbei ein Zip:
Das Prog
RNSI2C.BAS /BIN/HEX sollte in den CO-Proc
RNMASTER.BAS/BIN/HEX sollte in den Atmega32

Die sollten sich besser vertragen.

Das Sys ist gesprächiger :-)
Ich nehme das Sys gerne, weil es so schön vor sich hin plappert.
Das RNMASTER macht natürlich einen schöneren Treeview, muss man zugeben.

Netter Gruß

Alle gut in die Winterzeit gerutscht ?

Wenn Dinge kompliziert werden, hilft es manchmal, Schwerpunkte zu setzen.
Schau'n wir mal, daß die PC-Applikationen alle miteinander können, wenn du einverstanden bist.

Eigentlich sollte RN_SERVER alles, was bei IP einkommt, auf alle anderen IPs 1:1 verteilen.
Läßt sich das verifizieren ?

Danke, Gut reingerutscht, Heute noch keine Fehler gemacht.
Also dann…..

Server:
Ich denke wir können Erstmal auf direkte Adressierung verzichten.
Jede PC –Applikation horcht ob es für sie interessant ist. Wenn ja benutzt sie halt die Message.
Ob es Interessant ist erkennt sie ja daran, von wem das kommt. Das bedeutet das die PC-Apps Eine Identität brauchen die als Absender mit gesendet wird. Bei 3 Slidern im Moment kein Problem.

Neue Gegebenheit:
Da wir jetzt ein neues Konzept von Einzelkomponenten verfolgen stellt sich eine neue Option:
Es ist bei meinem Projektteil vorgesehen.
1. Zusammenrottungen von Einzelkomponenten zu einer GUI als Verein zu behandelt.
2. Das sich beliebig viele unterschiedliche Vereine jeweils über ein Konfigurationsfile bilden können.

Diese Vereine die sich da bilden sollten auch einen Namen, oder Nummer haben.

Das ganze sehe ich unabhängig von dem gesendeten RN –Anmeldestring via Server

Frage:
Wie wollen wir das Adressmäßig lösen?

Netter Gruß aus der neuen Zeit

Software Entwicklung:
Visual Basic 2005:

Ich sehe im Laufe der Arbeit, dass sich viele Softwarebausteine bilden.
Aus meiner Sicht ist es Arbeitssparend wenn wir einen Pool gemeinsamer Komponenten bilden würden die wir einheitlich benutzen und weiterentwickeln.
Wir würden auch, da es ja Open Source ist, Anderen die Möglichkeit geben, einzelne Komponenten zu benutzen, die sie nicht extra selber schreiben müssten.

Beispiele sind ein Errorhandler, Ein IniFile Erzeuger, ein Treeview, eine Singleton Fenster Routine, usw.

Das gilt logischerweise jeweils nur für eine, jetzt meine, Programmiersprache.

Als Testlauf kann ich mir das auch als separaten Ablauf vorstellen in dem nur Entwickler und Komplizen von Entwicklern Zugang haben. Wenn uns das nicht gefällt können wir es auch wieder sein lassen.

Mein Motiv dabei ist.
Eine Homogene Softwareumgebung zu erstellen die leicht zu Pflegen und zu Verbessern ist.
Die begrenzte Zeit die ein jeder hat zu schonen.
Der Bausteinbildung Vorschub zu verleihen
Zu einem guten Ergebnis zu kommen.
Von Anderen und ihrer Arbeit zu profitieren :-) .

Wie gesagt, das alles ist ein Vorschlag von mir unter dem Aspekt, dass es ja eh Open Source werden soll.


Netter Gruß

uff, uff, ne menge.

GUI e.V. : Wir haben dzt. eine Identität so eines Vereins, nur ist das halt nur Text. Auch ohne spezielle IAM könnt' da noch eine Netz-ID reinquetschen.
Aber besser wär's, überhaupt zu einem formalen Aufbau zu wechseln, solange wir noch jung sind. Denn bald werden auch die Versionen eine interessante Information sein. ("hat der dieses oder jenes schon drauf oder nicht")
Mir wäre es einfach, wenn wir da ein Key-Value-Format nehmen würden
Key1=value1 , Key2=value2 , ....;KeyN=valueN

ID=nnnnn , NAME=aaaaaaaaa , VERS=mmm , DESCRIPT=aaaaa
(alternative statt "ID" IDC=class, IDI=ident )

Für den Absender isses so soder so nur ein String, aber ich tu' mir leicht beim zerlegen, und wir können jederzeit was hinzufügen, ohne bestehende Applikationen zu tangieren.
Also:
KEY ID, IDC, IDI, VERS, NAME, ......
"="
value numerisch oder text, je nachdem (nix hexadezimales)
"," Argument-Seperator oder nix, wenn nix mehr kommt
Reihenfolge egal, alles optional ( Wenn keine ID, dann hat er eben keine)

Das "RN" am Anfang müßte dann nicht mehr sein

*puff* für Erste

*next*
Für das Startup ist die Zusammensetzung eines GUI e.V. natürlich wichtig. Aber beim laufenden Betrieb bin ich mir jetzt nicht sicher, was eine GUI-ID für eine konkrete ´Bedeutung hat.
Gibt es die gleiche Komonente (ID-mäßig) in verschiedenen, gleichzeitig laufenden GUI e.V ?

Kannst du einfach mal vor Dich hinspinnen und erzählen, wie du dir so eine Roboter-Session idealerweise vorstellst ?
Die Frage geht danach: Was ist dynamisch variabel, und was ist fest definiert ?

(Ich mein, dem Robby kann ja kein neuer Haxen wachsen, nur weil man auf der anderen Seite einen Slider dazustartet)

GUI e.V. Teil 1:
Hört sich sehr gut an.
Machen wir erstmal so.
Du brauchst das für den Server ja noch nicht so dringend einbauen wenn der erstmal nur beim Broadcasting bleibt.
Broadcasting würde mir im ersten Schritt schon reichen.
Den Rest wickeln ja dann Die PC-App’s ab.
Damit hast Du mich schon mal vom Hals und deine Ruhe :-)

Netter Gruß

Ok, wie gesagt, eigentlich sollte er das broadcasten machen. Bitte schau mal, ob's wahr ist

(Nicht die erste "ID" Message, logo) Oder soll er doch ?

GUI e.V. Teil 2:

Was mich interessiert ist die Interaktion von PC-Apps untereinander.
Dem armen Robi können ja, wie Du schon sagtest keine extra Beine wachsen.

Vorspann:
Wir haben eine Situation wo die PC und Internetseite wartet.
Die 3D Fraktion kann ohne RN Datenstrom nichts Darstellen.
Die Mappbuilder können ohne den Unterbau eines Netzwerks keine vernünftige Entwicklung voranbringen.
Marvin42x braucht Datenströme für seinen kleinen RN Zoo
Selbst die Motorrad -Scheinwerfer –Verstell -Fraktion könnte besser entwickeln.
Auch die Vogonen könnten mit Hilfe des RN-Netzes die Herrschaft über die Rasenmäher erringen.
So, ich hör mal auf, das würde noch so ne Weile weiter gehen.

Nachspann:
Also.
Das Zentrale Start Center MARV (Marvin’s Administrations and Remote Viewer)
Ist der Ausgangspunkt.

1. Ini File für die Session1 wählen. z.B. „Rasenmäher3.ini“
2. Starknopf drücken
3. Es werden gestartet:
• Rn-Server mit Konfiguration
• 5 Slider
• 1 Radar
• 8 Levelmeter
• 1 Graph
• 1 PC –App Mappbuilder V.2.1
• 1 PC App Erkennungssystem Datenbank
• 1 PC –Datenlogger Datenbank
• 1 PC –Videosystem mit Streaming
• 1 PC -ÜbergeordnetesVerhaltensModul

Session2:
Ini File „MappEntwicklung.ini“ wählen.
Startknopf drücken.
Es werden Gestartet:
• 1 PC -Simulant, der einen Datenstrom erzeugt, als wäre er ein Roboter
• 1 PC Map Displayer
• 1 PC Verhaltensmodul
• 1 PC Map Analyser
• 3 Slider
• 3 Graphen
• 1 Radar
• 1 PC 3D Display

Session 3:
………..
…………

Ja, es gibt naturgemäß in jeder Session z.B. Slider, deren Class und ClassID sind nur unterhalb einer GUI ID eindeutig.
Das schöne ist, das Du die Komponenten für alles verwenden kannst.
Wenn Du willst kannst Du auch Dein Intelligentes Haus damit verwirklichen.

Uff, Verschnaufpause.
Erstmal Genug.
Sacken lassen.
Und Respons abwarten.


Broadcast:
Wusste ich gar nicht, Das er das macht.
Da müsste ich ja ein Echo von meiner Message erhalten?

Netter Gruß

Zitat:

---

..ja ein Echo von meiner Message ..

---

Der einzige, der nix kriegt, ist der Absender. Das schien mir zu schleifen-gefährlich. Auch darüber kann man natürlich reden.

Sessions: I see. d.h. wenn das Setup mal steht, is alles klar.
Was man zuvor ganz einfach braucht, ist ein "config-designer". Mit intuitiver Bedienung, versteht sich.

Und einen Cyber-Atmega als simulanten.

Irgendeine innere Stimme sagt mit, daß wir noch einen Haufen Arbeit haben :-)

Zitat:
Irgendeine innere Stimme sagt mit, daß wir noch einen Haufen Arbeit haben
:-) :-) :-)

Nee kein Sorge.
Wir schaffen nur die Optionen dafür.
Hi hi.

Zitat:
Der einzige, der nix kriegt, ist der Absender.

Das ist ja super so.
Wenn wir die Identifikationen auf die App –Ebene legen ist ja hier erstmal alles gegessen.

Fast alles ;-)

Jetzt kommen Apss die längere Messages benötigen.
Sagen wir mal, ……..
Mir fällt gerade nix ein.
Aber nehmen wir mal an einer will partout eine Bitmap übertragen.
Wie lösen wir das?

Netter Gruß

Mit langen Binärschweinen ist das etwas ambivalent.
Solange wir für die Applic. das Netzwerk transparent halten, kann eine Message immer auch über einen µC laufen, und da hat es Grenzen bei der Größte. Da MÜSSEN wir die Bitmap in Slices zerteilen. Das hat auch den Vorteil, daß sich der andere Traffic dazwischenschummeln kann und nicht zum Stillstand kommt.
Da werden wir wohl noch nachdenken lassen, damit wir nicht gar so schnell unsere eigene Regeln austricksen müssen.

So weit so gut.
Wenn der Server so tut wie erwartet, habe ich, glaube ich, erstmal alles was ich benötige.
Die Woche bin ich mit der Zeit etwas knapp.
Ich werde aber trotz dem versuchen ob ich nächste Woche eine kleine Demo zur Diskussion bereitstellen kann.

Netter Gruß

Na das geht ja gut los :-)

Nach dem ich nun gesagt habe, ich habe alles.
Hier der erste Wunsch:
Kannst Du an Deinem Server eine CheckBox „Fast Connect“ anbauen?
Der Wert FastConnect sollte dann auch in Deinem Config File auftauchen und ausgewertet werden.
Im Falle in dem in der Server Config Fast Connect auf 1 gesetzt ist startet der Server sofort alle Verbindungen. Wenn Fast Connect = 0 macht er keinen Connect

Hintergrund:
Ich möchte schon bei der Demo unmissverständlich klarmachen:

Ein Knopfdruck und die Sache läuft.

Dazu ist es notwendig, dass ich, wenn ich den Server als erstes starte steuern kann das er ohne weitere Zutun Online ist. Die folgenden Apps werden dann dasselbe tun.
Damit steht das System komplett mit laufendem Netz.

Sag mal bescheid ob Du damit einverstanden bist.

Netter Gruß

:mrgreen: das übliche User-Verhalten
Vorher: "Ich möcht ja nix als dieses oder jenes
....
Nachher: "Könnte man nicht noch......."

Kein Einwand, mal sehen, wie ich dazukomm'

:mrgreen: das übliche User-Verhalten

Keine Ahnung aber rum meckern: :-#
Ich habe das laden der .CFG nochmal probiert.
Den Pfad "TRACE" will er bei mir nicht aus der Datei laden. Bei IP und ... geht das richtig. [-o<

Vogon: Das werden wir noch klären, daran wird's nicht scheitern.

Ich werke grad' an einer VB-fähigen DLL + Demo für
erstmal Conifg-Files Manipulation (Load, read, write, update, Flush)

sieht gut aus, demnächst Liefertermin

@PicNick:
Das überschlägt sich ja hier.
Bei dem Tempo muss man ja aufpassen, dass einem nicht die Mütze vom Kopf weht.

Im Detail:
Scheinbar lohnt es sich auf Software-Ebene eine Art Abstimmung einzuleiten.
Ich arbeite gerade angestrengt an der Konfiguration meiner Anwendung.
Dazu benutze ich Ini Dateien, schreibe und lese darin.
Wenn demnächst eine DLL ins Haus steht werde ich natürlich die einbauen damit das alles ein Guss wird.
Im Klartext, ich werfe eine menge Arbeit in die Tonne.
Darum mein Vorschlag:
Eine Art Frühwarnsystem einzurichten an dem ich meine Aktivitäten ausrichten kann.
Vielleicht so eine Art Liste von Dingen die Dir vorschweben.
Hoffentlich schwebt Dir viel vor ;-)
Keine Ahnung wie wir das realisieren, aber es dürfte sich für das Projekt lohnen.
Auch die Definition von Software –Schnittstellen würde ich gut finden. Dadurch wird das Ganze schön Strukturiert.
Zum Schnittstellen festlegen würde ich Dich als Häuptling wählen.
Du hast sicher einen geschärften Blick für so was.

Server:
Der Vogone hat recht, mit dem Aufruf des Servers einschließlich Config bekomme ich das nur über ein *cmd hin in dem die Komandozeile steht. Dann habe ich aber ein offenes Konsolefenster am Hals.
Ich kann Dir eine Ultraleicht-Demo schicken, da kannst Du das mit dem Aufruf aus MARV raus untersuchen. Das ist bestimmt nur eine Kleinigkeit.

Der neue sollte dann auch kein RN mehr vom TCP Client verlangen? Mir war so.



Ausblick:
Ich bin ganz hibbelig. Das was wir hier machen wird ein ganz tolles Ding.
Und ich freu mich schon auf die ersten Gehversuche von alle dem.
Das macht richtig Spaß.

Netter Gruß

Das mit der config File war urspünglich nicht so bös' gemeint. Ich hab halt der Einfachheit halber für den RN-SERVER das verwendet, was ich sozusagen in der Lade hatte (Ich brauch' sonst immer Plattform-neutrale Sachen). Der Witz daran ist der, das sie nach dem Laden real im Speicher als hierarchischer Tree zur Verfügung steht, man muß nicht immer jeden Sch... in irgendein feld schreiben, um es sich zu merken, und den ganzen Tree zu lesen oder auf File zu flushen, geht auch elektrisch. Arbeitet sehr ähnlich der Registry in Windows

Dann ist eben der Gedanke der zentralen Config aufgetaucht, und da kann so ein Tree schon hilfreich sein, wenn man ihn mit der gleichen Struktur aufbaut wie eben die ganze Applikation.

Ich werd' die Doku + Demo zum Download herrichten.

Das ist eine DLL, die direkt von allen DLL-Fähigen Programmen verwendet werden kann. Die Funktionen im Wesentlichen

Create (empty) Tree
Drop Tree
Build (file-name-string) Einlesen ganzer Tree
Flush (file-name-string) Rewrite ganze Tree
Create/Delete/Find Directory "Knoten"
Create/Delete/Find Parameter "Key"
Create/Delete/Find Value "Value"

Primär ist alles auf string-basis, weil das überall geht.

Ich möcht noch die IP-Geschichte verpacken, das haben wir ja schon abgedeutet. Von den Funktionen her eigentlich wie die normale Socket-Geschichte, nur das Message-Zerlegen und Aufbauen ist integriert.

Eventuell auch die Layer0-ComPort Sache, die könnten ja vielleicht auch endere brauchen.



Und diverses Bit und Byte-gefummel, das immer wieder nervt.

Die meisten Sachen gibt's ja schon, es geht nur darum, wie man das vernünftig mit einer DLL exportieren kann.

Ja, der neue will kein "RN" mehr (is aber noch in Arbeit, mit der "fast-connect" Geschichte)

Doku hab' ich begonnen :
https://www.roboternetz.de/wissen/in...C_PC-Programme

Gerade Marvins Marvellous MARV getestet.
Überleg' grad, ob EINE zentrale ini/cfg überaupt zweckmäßig ist
Also:
MARV weiss, was wie oft zu starten ist + einige setup parameter
Aber die einzelnen Komponenten könnten durchaus auch ein Eigenleben führen.
*murmel, grübel*

Sorry, bin auch schon wider runter vom Baum. War ein harter Tag.
Und Du weist, ich habe es schon viermal neu geschrieben und ich schreibe es wenn es sein muss auch zehn mal neu.

Das mit der einheitlichen Cofig-Geschichte und dem Tree ist Genial.
Das ist viel besser als das was ich habe.
Das eignet sich fast als Geburtstagsgeschenk :-)

Das Du unter Anderem bei der Bit und Byte-Fummelei noch hilfst entspannt mich ungemein.
Es ist ein ziemlicher Graus, wenn man sich das alles zusammensuchen muss.

Ich mach jetzt erstmal mit meinem Zeug so weiter und werde nach und nach mit den Sachen mitziehen.
Was schön ist, dass ich einige Probleme die noch ausstehen erstmal parken kann und da nicht so viel Zeit verwenden muss.
Bin schon wieder ganz oben auf :-)
Freu mich.


Netter Gruß

Ps. Sehe gerade es ist angekommen.
Fein

Bei der Ini –Sache bin ich ganz offen, der beste Vorschlag gewinnt

Netter Gruß

Erläuterung des bisherigen Konzepts:
Jede Einzelkomponente trägt sich höchstpersönlich in das Config File mit einer eigenen Rubik ein, wenn man sie positioniert und eingestellt hat und den save Config Button drückt.
Jede Komponente hat seinen eigenen Save Button.
Die Komponente könnte auch als Einzelkämpfer auftreten.
Dann ist halt das Ini File kleiner.

In Arbeit ist zurzeit der Wechsel zwischen verschiedenen Konfigurationen.
Sprich Config Files dadurch entstehen dann unterschiedliche EV.’s.

Die Info welches Config nun das angesagte ist soll als Pfadangabe über ein Start-Argument in der Komandozeile an die startenden Einzelkomponenten mitgegeben werden. Dort wird ja bereits eine laufende Nummer mitgegeben die zum Bestandteil des Namens wird, also der ID „Trackbar 1“ z.B.
Weiter ist angedacht dort auch IP und Port und eventuell Komponentennamen zu übergeben.

Das managt MARV.
MARV weis ja was es tut,(hoffentlich) .
Weiter Merkt sich MARV die TaskID und kann beim drücken vom Aus Button alle gestarteten Tasks anhand der TaskID wieder abräumen.
Später sicher auch in einer Auswahl gezielt einzelne.

Jetzt der Schwenk zur Kür:
Geplant ist eine Remote -Funktion der Komponenten wenn sie erstmal online sind.
Das geschieht über IP Messages mit Befehlen. Damit kann man sie im laufenden Betrieb verschieben, vergrößern, verkleinern, Wertebereiche umstellen. Na das Ding wird damit lebhaft wie ein Floh, wenn man will.
Das kann man natürlich auch benutzen um die Komponenten erst nach dem Start anzuordnen. Oder umzuordnen falls sich Gegebenheiten verändern.
Auch kann man darüber die Komponente beenden.

Puhh….
Erstmal genug.

Man kann sehen, dass das RN-Com eine weit offene Architektur hat. Da bleibt kein Auge trocken und keine Seele ungetröstet.

Netter Gruß

So jetzt noch der Rest:
Es ist dem geneigten Leser natürlich schon klar, dass mit der TCP Remote –Funktion auch ein Roboter seine eigene GUI starten und konfigurieren kann. Der Befehlsumfang und die Parameter sind ja nicht sehr aufwendig.

Wenn ein RN-Server und ein MARV online sind, ist fast nicht unmöglich.

Netter Gruß

Apropos Typisches Userverhalten: :-)

Ich hätte da einen Wunsch: :-)

Wenn ich mich jetzt mal auf mein Konzept beziehe.
Würde es reinpassen wenn der Server die TCP -Befehle:
Form.Hide
Form.Show
Form.Minimize
Form Resize
Können würde.

Aus dieser Anforderung raus stellt sich dann die Frage eines einheitlichen TCP-Befehlssatzes oder Formates.

Da diese Befehle ja für alle Komponenten funktionieren sollen.

Mein Vorschlag:
Es wäre lieb, wenn Du die Definition dafür vorschlägst und wir die dann festlegen.

Die Notwendigkeit, dass der Server oben genannte Befehle kann ist nicht eilig.
Er dient jetzt erstmal nur als Vehikel um dieses Feature fertig zu definieren.
Außerdem weis ich noch nicht ob Du damit in der Form einverstanden wärst.

Netter Gruß

Weiter geht’s

Ich mach heute den Alleinunterhalter :-)

Jetzt eine Übersicht über TCP –Standardbefehle:
Das schwebt mir so vor:
Form.Hide
Form.Show
Form.Minimize
Form Resize
FormPosX
FormPosY
FormSizeX
FormSizeY
Close(Programmende)
CurrentConfig
Save Config
Load Config
Set Value, (welcher Wert), (Wert)
StartAction (irgend eine Aktion)

Na und was noch so kommt…….

Netter Gruß

OT (Now to something completely different)

Da is eine Zip, wo ich so eine Art digitalmixer mit einer ähnlichen Aufgabenstellung wie MARV gemacht habe (is schon älter)

unzip
wenn's auf der disk c:\ ist:
Start MX0.EXE
FILE->OPEN-> "saurier.mix"
DRV -> (right-mouse for config)
TRANSPORT-> Start / STOP / ZERO

bißchen rumdrücken, doppelclicken und right mouse Menues

Wenn's Spaß macht.

Zitat:

---

..den Alleinunterhalter ..

---

Na, du hast ja auch ein umfangreiches Programm, wo sicher noch ein paar Zugaben kommen :-)

Ich hab' schon mal den Helm aufgesetzt und bin in den Schützengraben gekrochen. Da wird js scharf geschossen. :-)

Ich glaub es ja nicht.

Das hast Du ja alles schon mal gemacht.
Da ist ja alles wie es sein soll.

Da müssen wir aber zusehen, dass wir für das jetzige Projekt ein gemeinsames Konzept haben was die Erfahrungen von Deinem Mixer verwertet.

Du hast ja ungeahnte Qualitäten :-)
Da muss uns ja nicht bange sein.

Jetzt habe ich natürlich ein Informationsdefizit in Hinblick auf das Konzept was dem Mixer zu Grunde liegt.

Das was ich bis jetzt von mir beschrieben habe ist ja die Beschreibung eines Konzepts.
Und Konzepte kann man wechseln wie die Socken.

Den Mixer kann man bestimmt Recyceln :-)

Netter Gruß

Zitat:

---

...kann man bestimmt Recyceln ...

---

Ja, in den Müll :mrgreen:
Aber ich hab natürlich was gelernt dabei.

BTW: ich find' da grad eins meiner (Test) Programme für Video files u. Video Capture devices. Soll man das auf DLL umbauen, damit du deinen Karaoke Hamster realtime gucken und analysieren kannst ? Reicht ja, wenn sich einer die Hände gebrochen hat.
Oder hast du das eh' schon fertig ?

Das wird ja immer besser.

Mein Hamsterviewe geht natürlich schon. ich wäre aber an einer Lösung von Dir mehr interessiert.
Meine Erfahrung hat gelehrt, das ich besser damit fahre :-)
Wenn das noch in einer Dll eingepackt ist wird die Softwarelandschaft auch schön homogen.
Weißte doch, Standardisieren auf Teufel komm raus.
Und wenn sich einer schon einen Abgerackert hat soll das genug sein. Ich bin kein Masochist und verlange nach extra Schwierigkeiten.

Netter Gruß

Mixer:
Einen Unterschied glaube ich beim Mixer zu sehen.
Der Taskmanager erzählt mir von einem Multi Window Konzept.

Wir haben uns ja diesmal auf ein Multi Task Konzept geeinigt.
Was bei der Frage der Kommunikation zwischen den Komponenten möglicherweise andere Erfordernisse hat.

Im Erscheinungsbild ist aber genau das wieder gespiegelt was ich gerade baue.

Bin ja gespannt was daraus wird.

Netter Gruß

Nun, die Funktionalitäten der Mixer-Komponenten unterscheiden sich von unserem Konzept nicht so sehr. Die von dir genannten Form.xxx Methoden braucht man so oder so.
Beim Mixer haben sie natürlich im Betrieb recht flott zu kommunizieren, das geht natürlich bei multi-window einfacher.
Ich hab das so, daß es eine allgemeine "Komponenten"-Klasse gibt, die die Komponenten erben. Dadurch sind aus zentraler Sicht die allgemeinen Funktionen und Felder(eigenschaften) einfach über diese einzelne Klasse anzusprechen, egal, was die Komponente sonst darstellt.
Das ist praktisch bei so Dingen wie minimize & restore, das gibts als methode eben nur einmal und in der Komponente selbst braucht man da garnix mehr.

Na schau'n wir mal.

Meerschweinchen gefragt !

Da ist ein VB Projekt mit dem Versuch, eine "Config-File" mit TREEVIEW zu kombinieren.

Theoretisch, wenn du es aufmachst und im Debug laufen läßt, sollte es sich bewegen.

Die Config-File ist halt irgendeine, die ich erwischt habe.
Es geht aber auch jede andere

Vielleicht guckst du mal rein, drückst eiin paar knöpfe und schaust die die VB mal an, ob du was erkennen kannst.

DOku folgt. Ich bin mir über die Schnittstelle noch nicht so sicher, zu viel soll's nicht sein, zuwenig aber auch nicht.


(Im Textfeld kann man die werte alle ändern)

Microsoft (R) Visual Basic-Compiler has encountered a problem and needs to close. We are sorry for the inconvenience.


Prima, eine CompilerBombe.

Wie haste denn die Programmiert?
Das ist bestimmt nicht einfach.

Wenn ich mal fortgeschrittener bin versuche ich mich auch mal an so was.

Harr harr hi hi.

Mach Dir nichts draus, das Leben geht weiter.

Netter Gruß

Nee, jetzt mal Quatsch bei Seite.
Ich muss mal sehen, er behauptet die Dll nicht zu finden, auch wenn ich sie in die Projektmappe einfüge.
Damit ist aber erstmal der Compilerabsturz vom Tisch.
Einen Verweis darauf kann ich auch nicht hinzufügen weil er sagt das ist möglicherweise keine compatible.

Ich versuch mich noch dran. Es ist ja gleich die Frage mit den Dlls.

Netter Gruß

Ich werd mal den Gegenversuch mit der Express-Version machen. Hoffe, daß es nicht daran liegt.
Wie gesagt, in der declaration muß der Pfad stimmen, also ev. korrigieren

declare Tralala LIB "C:\da\und\dort\rnregist.dll" etc.

EDIT: Nein, auch mit der Express geht es tadellos.

Ich hab die gepostete Zip runtergeladen , in ein verzeichnis
d:\VB2005_exp_ed
und dort aus der zip dann
d:\VB2005_exp_ed\tooltest......
erzeugt.

Da hab ich jetzt aus der Ferne im moment auch keine Weisheiten :-(

Jetzt hab' ich die DLL dorthin kopiert /verschoben, wo auch das Tooltest.exe nach dem Veröffentlichen hinkommt.
Dann von DORT in den Projektordner aufgenommen
Dann Tooltest veröffentlicht.
Da klappt es auch.
Für den Registry/config Filenamen sollt' man ein Eingabefeld machen.
EDIT: Ja schön, aber dann noch einen "OPEN" Button dazu
Den TreeView aufbau kann man dann aber nicht in "Form-Load" machen, sondern in der Open-Button-routine
eieieiei