Dockmanager

Rund um die LCL und andere Komponenten
Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Ich versteh kein wort ?! Du willst eine Form auf einer TListbox platzieren ?
Was macht das für einen Sinn ?
Also probiert hab ichs mit einem Panel und einer anderen Form.

OK, ich habs soeben mit ner Scrollbox probiert Siehe Screenshot. Ihr treibt mich heute echt in den Wahnsinn ;)
Dateianhänge
Unbenannt.PNG
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Mehrer Datensätze aus ein Datenbank im gleichzeitigen Zugriff ohne dauernd auf- und zumachen. Alle dasselbe FormularObjekt nur andere Daten. Ganz elegant, wird das Formular auf seinen Header verkleinert und man sieht auf einen Blick (Caption) welche man offen hat und kann die nach Wunsch wieder auf- und zuklappen. Aufgeklappt kann man Daten ändern und wieder speichern oder zu einem anderen Datensatz wechseln.

Klassenraum-Anwendung:

Mehrere IP-Server, jeder ein anderer Port, werden als Formulare in einer Scrollbox gehalten. Der Moderator kann zu jeder Zeit einen neugierigen Blick auf den Zustand der einzelnen Server-Pages werfen und z.B. feststellen wie weit die Bearbeitung einer Aufgabe gediehen ist oder helfend eingreifen.

Besonders einfach zu entwickeln, da das Formular selber der IP-Server ist. Command als String definieren (geht visuell) und das Antwortverhalten einbauen. Der Client kann als dll (so) gebaut werden (ebenfalls visuell) und per MainServer vom Client geladen werden. Kaum ist der Client aktiv, sieht der Moderator das auf der ServerPage (aktive Benutzer).

Entwicklungszeit für eine Komplette Anwendung (Server- und Clientpage) wenige Tage. Voller SQL-Zugriff lokal auf dem Server möglich.

Tausend weitere Möglichkeiten vorstellbar... :roll:
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Bahnhof.

Und ich weiss auch noch nicht wo das Problem ist.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Das geht nicht mit Formularen, die Modal werden. Die klauen dem MainServer und allen anderen den Focus. Das ist eine vollständig asynchrone Anwendung die je nach Anforderung beliebige Clients bedient, die jeder für sich Teilnehmer an einer andere Anwendung sein dürfen.

Trotzdem hat der Moderator die volle Kontrolle über jeden einzelnen Server ohne deswegen mehrere Anwendungen starten zu müssen. Ein MainServer ist die Mutter aller anderen Anwendungsserver. Also müssen auch alle im MainThread des SuperServers laufen.

Das kann doch so schwer nicht zu verstehen sein?

Und ich hab keine Lust deswegen x Threads zu bauen, das wäre kaum noch visuell zu machen. Ist das Formular aber selbst der Server kann man das als Control bereits mit den Grundmöglichkeiten zur Verfügung stellen und der Entwickler baut nur noch das Protokoll. Nach belieben kann er das dann als Einzelanwendung bauen oder in den SuperServer integrieren. Auf die Art kann auch der Client mehrere Anwendungen parallel verarbeiten, der wird dann Clientseitig ebenfalls zum SuperServer, aber eben nur für den Clientteil der Anwendung.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Beitrag von theo »

???

Also dein letztes Posting hat was Schnulli.
Ich glaube langsam du machst das absichtlich.
Ist das Newsgroups - Dadaismus? :-)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Puh und ich dachte schon ich bin der einzige der das 10x liest und immer noch nix verstanden hat.

Hast du früher mal Bedienungsanleitungen geschrieben schnulli ?
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Das ist wohl mehr asynchrones Denken mit Blick auf den betroffenen Anwender, der keine Lust hat ständig irgendwelche Programme klein- und wieder großzumachen.

Tatsache ist nunmal das jeder IP-Server für sich bereits ein Thread ist. Will ich das visuell entwickeln, also das gewünschte Protokoll für genau diesen Server einbauen, dann geht das nur mit einem Formular oder Frame. Frame dann, wenn ich mit einem Formular nichts anfangen kann. Wenn ein Formular den Fokus verliert wird der im Kontext laufenden IP-Thread gleichzeitig auch lahmgelegt. Das ist probiert und geht also nicht.

Der Main-IPServer übernimmt bestimmte zentrale Aufgaben wie z.B. login-Verwaltung und verteilen der angeforderten Anwendungs-Lib. Der darf also auch nicht lahmgelegt werden.

Der einzige gangbare Weg ist demgemäß eine Komponente die eingebettet im Mainprogram läuft und damit die an sie gerichteten Anfragen bearbeitet ohne das diese über den Main-IPServer verteilt werden. Das hält einfach den Aufwand für ein neues Anwendungsprotokoll klein, weil nur die spezialisierten Teile eingebaut werden müssen. Den Rest kennt die Komponente bereits. Und anstatt nun HTML-Seiten durch die Gegend zu schieben und die in einer Session zusammen zu basteln, werden nur Nutzdaten übers Netz weitergegeben.

Man kann also sowohl den Server wie den Client zussamenklicken, was soll nun daran falsch sein?
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Ich versuch das was ich bisher denke verstanden habe mal zusammenzufassen. Du willst eine Anwendung bauen, die Auf einem Rechner laufende Porgramme in Ihrem Hauptfenster einbettet und man kann dann diese Fenster in einer Baumansicht auf und zuklappen ?!

Der IP Schnickschnack interessiert hier an dieser Stelle ja gar nicht. Oder ?!
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Beitrag von theo »

Gut, ich probiers auch mal, macht bestimmt Spass: ;-)


Das einfachste wäre wohl, 25 Apache Server in ein ID3 Tag zu integrieren.
Das Tag könnte man dann über Thread-gesteuerte Prozesse asynchron in einer Combobox abbilden. Das öffnen der Combobox löst einen Cron Job aus
der sich regelmässig mit dem CERN in Genf synchronisiert. Damit ist die eindeutigkeit der Prozess - Thread Relation gewährleistet.
Die Apache Server solllten natürlich gleichzeitig auch Webbrowser und Radiowecker sein.
Versteht Ihr was ich meine?

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Du kannst das nicht da sind zuwenig unnütze informationen drin *duck*
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Beitrag von theo »

Christian hat geschrieben:Du kannst das nicht da sind zuwenig unnütze informationen drin *duck*


Naja, ist mein erster Versuch. Es ist noch kein Meister vom Himmel gefallen. ;-)

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Neiennnnnnnnnnnnnnnnnnnnnnnn.............

Allgemein betrachtet ist ein Formular für sich bereits eine Anwendung die in einer anderen Anwendung läuft. Da nun aber mal die Welt zu 99.99999...% asynchron läuft gibt es keinen erkennbaren Grund warum immer nur ein Formular aktiv sein darf. Die Formularlogik läßt aber nichts anderes zu.

Bricht man das noch etwas herrunter ist auch eine beliebige Komponente (zusammengesetzte Komponente) ebenfalls eine Anwendung. Es gibt also keinen Grund, das die keine Daten empfängt während der Benutzer an einer anderen Komponente Daten eingibt oder sich welche besorgt. Als Formular kann sie das aber nur wenn sie auch aktiv ist. Ansonsten muß man dafür Umwege gehen die nicht nötig sind (Messagehandling).

Im speziellen Fall ist das dann eben ein IP-Server oder -Client von dem in einer Application mehrere aktiv sein dürfen ohne das man deswegen das Protokoll über nur eine IP-Server oder Clientkomponente auf die einzelnen Anwendungen (Formulare/Komponenten) verteilt. Das wäre erkennbar kompliziert und schwer überschneidungsfrei (gleiches Kommando in verschiedenen Komponenten haben eine andere Auswirkung) hinzukriegen.

Also ist es ja wohl naheliegend in diesem Fall eine IP-Komponente auf die Komponente zu legen und ihr einen speziellen Port zu verpassen. Dann gilt das vereinbarte Protokoll nur für diese Komponente und sie kann das unabhängig abarbeiten während der Benutzer an einer anderen Komponente oder Pseudoformular Eingaben vornimmt. Bei bestimmten Zuständen wird der Benutzer von der Komponente selbst auf das Ereignis aufmerksam gemacht, also zeitgleich. Zum Zeitpunkt des Eintreffens muß in diesem Fall die Komponente nicht einmal sichtbar sein und arbeitet trotzdem weiter.

Das sowas geht hab ich als Beispiel hier. Aber das funktioniert wegen der Entwicklung der Oberfläche eben nur auf Frames weil sich die als Komponente einhängen lassen. Zusätzlich hab ich an die IP-Komponente eine Kommando-Struktur gehängt, die es ermöglicht das Protkoll ebenfalls visuell zu erstellen. Man erzeugt ein Kommando, gibt den Command-String ein und läßt sich die Methode erzeugen. Dann baut man da nur noch die Verarbeitungslogik ein.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Benutzeravatar
theo
Beiträge: 10497
Registriert: Mo 11. Sep 2006, 19:01

Beitrag von theo »

Ich geb mich geschlagen.
An die Subtilität von Schnullerbacke's Formulierungen reicht meine Newsgroup-Dada-Kunst niemals heran.
Früher dachte ich immer, du hättest was geraucht. Ich hatte nicht erkannt, dass es eine Kunstform ist.

Also da bleibt mir nur zu sagen: "Chapeau!"

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Ganz einfach ausgedrückt,

wenn jemand einen fahren läßt stinkt der auch sofort ohne das du erst das "Riechformular" modal machst.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Ich geb mich auch geschlagen bis zu dem Posting dachte ich noch es geht ums docking in diesem Thread.

Da nun aber mal die Welt zu 99.99999...% asynchron läuft


Es wäre nett wenn du für uns armen leuts deine Posts synchron machen würdest. Ich kann die 10 verschiedenen Themen die du pro satz behandelst nicht verarbeiten.
Ich bin oft auch ganz froh darüber das Programmiersprachen sequenziell sind. Villeicht kann man ja aber nen parallelen Abkömmling von Brainfuck erstellen in dem Paralell programmiert wird in dem können wir dann auch ein Programm schreiben das diese Beiträge entziffern kann.

Naja villeicht kannst du 2 einfache Sachen mal jemand in deiner nähe erklären und ihn das posten lassen.

1. : was soll dein Programm machen wozu du Frames brauchst. Und ich will da nix von IP´s hören.

2. : wo ist das problem.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Antworten