Subobjekte aus eigener Komponente

[schnullerbacke]

...sind bei der Anwendung anwählbar. Die Subobjekte sind aber alle in der Package-Unit beim Objekt im private-Abschnitt deklariert. Sie sollten also, wie bei Delphi, bei Verwendung nicht mehr einzeln selektierbar sein. Dafür sind ja eigentlich die entsprechenden propertys im published zuständig.

Tatsache ist aber, das man das im Designmode trotzdem kann.

Kurz zum Objekt:

Es handelt sich um einen Ableger von TPanel der als Controlbar dienen soll. Es beinhaltet ein TImage für ein Icon, ein Panel für die Caption und ein weiteres Panel für Control-Buttons. Insgesamt soll es dazu dienen, ein Formular auf Basis eines TPanels aufzubauen. Die Control-Buttons übernehmen dabei Minimierung, Maximierung(in diesem Fall steuerbar, z.B. auf Panel-Größe verkleinern und wieder auf Ausgangsgröße zurück), Help aufrufen, schließen und auf Icon verkleinern. Andere Steuerungen können in abgeleiteten Objekten angefügt werden.

Die Idee dahinter, das so erzeugte Formular läßt sich problemlos in einer Scrollbox oder ähnlich unterbringen. Es bleibt dabei aber im Gegensatz zu normalen Formularen solange aktiv bis es explizit geschlossen wird. Man könnte also verschieden Datenbanksichten aufbauen und die Veränderungen der Datenbankinhalte, soweit einzelne Datenbankfelder in mehreren Formularen auftauchen, verfolgen.

Bsp. Lagerverwaltung steht auf Datensatz xy, VK-Dialog verkauft hiervon Ware ab. Beide Formulare sind in einer Scrollbox offen und sichbar. Bei Abverkauf ändert sich nahezu zeitgleich der Lagerbestand im Lagerformular.

Anderes Beispiel könnte eine Überwachung von bestimmten Artikeln in der DB sein. Alle Formulare werden in der Scrollbox geöffnet und bei Änderunge des Datenbestandes in das Blickfeld des geneigten Betrachters gerückt. Er kann aber auch nach Belieben scrollen.

Andere Möglichkeit wäre die Überwachung einzelner Clients in einem Netzwerk, z.B. mitschreiben der Aktivität und der Übertragungsraten.

Oder ganz gemein, Überwachung aller Mitarbeiter...

Da fragt sich nun ob ich nur zu blöd bin (in Delphi läuft das) oder ob ich da irgendwas übersehen hab? So ist das für den Entwickler jedenfalls kaum zu gebrauchen, der soll sich ja schließlich auf das Eigentliche konzentrieren und nich die gleiche Einstellung an 3 verschiedenen Stellen machen können.

[schnullerbacke]

@theo

Guckst Du hier!

Wenns fertig ist, sollen im rechten Panel entsprechende SpeedButtons rein. Damit kann man dann ein normales Panel bedienbar machen wie einen Dialog oder Formular, mit dem Unterschied das der Focus nicht wechselt. Damit kann man dann mehrere solche Pseudoformulare in einer Scrollbox oder ähnlich halten. Wenn Du das so in der IDE installierst und dann auf einem Formular verwendest kannst du trotzdem das CaptionPanel und ButtonPanel selektieren obwohl die eigentlich verborgen sein sollten. Für das IconImage gilt das Gleiche.

[Christian]

Hast du dir das vom Audio X abgeschaut oder hatten wir da nur die selbe idee ? Ich benutze soetwas schon fast 2 Jahre in meinen Applikationen macht sich wirklich schön auch wenn die leute beim ersten davorsitzen es nicht auf anhieb verstehen. Meine sind auch tatsächlich Fenster und keine Panels das hat den vorteil das man sie auch noch ausdocken kann und auf nen anderen Monitor schieben u.ä. ...

[schnullerbacke]

@Christian

Lol, da hatten wir wohl die gleiche Idee. Ich brauch das für ne Terminverwaltung beim Zahnarzt. Damit lassen sich alle Termine für den Tag in einem Grid anzeigen und bei Bedarf kann man sie öffnen. Im Grid werden sie dann auf Panelhöhe verkleinert, damit man die Informationen noch sehen kann. Im Endausbau sollen die beim Behandler direkt zum Behandlungsformular werden.

Bei sowas kann man mit dem MDI-Geschisse nichts anfangen, deswegen die Idee.

[theo]

@schnullerbacke: Tja, weiss ich jetzt auch nicht.
Hab im Moment den Kopf woanders.
Vielleicht kann Dir Christian Auskunft geben.

[schnullerbacke]

@Christian

Kann das sein das die LCL die Vererbung nicht sauber durchführt? Lies mal was ich theo dazu geschrieben hab. Danach sieht es ganz so aus als sei das so. Dann hätten wir allerdings einen ziemlich schweren Bug gefunden.

[Christian]

Kannst du das villeicht nochmal erklären so ganz weiss ich net was du willst theo hat nur geschrieben das er keine zeit hat ...

Du meinst das die codetools alle obekte anzeigen wenn du die code completion benutzt oder was ?

[schnullerbacke]

Nee, im Entwurfs-Modus sind die Einzelnen Objekte die im private-Abschnitt deklariert sind alle selektierbar. Die sollten aber in diesem Fall nur noch angezeigt werden, dürfen aber im Objekt-Inspektor keine Rückgabe liefern. Bei Delphi klappt das auch richtig so, im Lazarus kann man sie erstaunlicherweise trotzdem selektieren und damit auch die Eigenschaften ändern. Das soll aber eigentlich nur noch über das Hauptobjekt möglich sein, dafür hat es ja die Eigenschaften veröffentlicht und stellt die Behandlungs-Prozeduren zur Verfügung...

[Christian]

Ich verstehs immernoch nicht
1. der Objectinspector zeigt nur propertys an diese sind aber nicht in private deklarierbar (glaub ich ...)
2. der Objektinspector zeigt nur published propertys an ...

[schnullerbacke]

@Christian

Nochmal nacheinander. Ich bau mir ein eigenes visuelles Objekt. Dafür verwende ich vorhandene Standardobjekte. Die verwendeten Objekte werden im Zielobjekt private oder protected deklariert. Damit wird das Zielobjekt Eigentümer. Das Zielobjekt wird in der IDE installiert und nun im Entwurfsmodus auf ein beliebieges Objekt, das kann ein Formular, Dialog, Panel, Scrollbox oder ähnlich sein, eingehängt. Da nun aber das neue Objekt (TCaptionPanel ind diesem Fall) in der uses des Interfaces aufgenommen wird, darf nur TCaptionPanel als gesamtes Objekt selektierbar sein, die in TCaptionPanel verwendeten Subobjekte dürfen nicht mehr selektierbar sein, dies deshalb nicht, als TCaptionPanel der Eigentümer ist und nicht das Zielobjekt auf dem ich das einhänge.

Das heißt die Subobjekte FIconImage, FOwnerCaption, FButtonPanel dürfen im Zielobjekt nicht mehr einzeln selektierbar sein, schon garnicht dürfen sie ihre Eigenschaften im Objektinspektor anzeigen. TCaptionPanel stellt die Eigenschaften für diese Subobjekte published zur Verfügung und nur über diese Eigenschaften darf das Verhalten der Subobjekte eingestellt werden. Im Falle von FIconImage wird das Image über die entsprechende Eigenschaft von TCaptionPanel eingestellt (in diesem Fall das Icon). So wie das in der LCL läuft, kann ich aber FIconImage selektieren und erhalte im Objektinspektor die Eigenschaften von FIconImage. Das ist nach den Vererbungsregeln falsch, das Zielformular darf von der Anwesenheit von FIconImage garnichts wissen, da es in TCaptionPanel private delariert ist. Das entspricht den Vererbungsregeln, die in der LCL aber offensichtlich nicht eingehalten werden.

Oder ganz tief rein, die LCL veröffentlicht offenbar den öffentlichen Teil der VMT der privaten Objekte eines Kombinationssteuerelementes. Sie dürfte aber nur die öffentlichen Eigenschaften des Kombinationssteuerelementes öffentlich machen. Das ist aber ein grober Verstoß gegen die Vererbungsregeln, dadurch kann man keine Kombinationssteuerelemente für den Programmierer zur Verfügung stellen, die aus mehreren Standardobjekten zusammengesetzt werden. Schließlich sollen ja die Vererbungsregeln sicherstellen, das man die komplexe Struktur des verwendeten Objektes in diesem Fall eben gerade nicht sieht und demgemäß auch die Eigenschaften der Subobjekte nicht ändern kann, das übernimmt das zusammengesetzte Objekt und läßt nur noch das zu, was auch verändert werden darf. Sonst macht die ganze Vererbung keinen Sinn mehr.

Im speziellen Fall heißt das, die Eigenschaft Align von FIconImage darf nicht geändert werden, weil hierfür das Eigentümerobjekt TCaptionPanel verantwortlich ist und diese Eigenschaft auch nicht offenlegt. Das Gleiche für FButtonPanel, dessen Breite und Position wird von TCaptionPanel nach Anzahl der Buttons bestimmt. So wie das in der LCL läuft könnte man die Position von FIconImage und FButtonPanel im Zielobjekt verändern, mithin genau das tun, was eben gerade durch TCaptionPanel verhindert werden soll.

[Christian]

Jetzt weiss ich was du willst aber auch erst nachdem ich den quatsch tatsächlich installiert habe in deinem package sind keine pfade eingetragen (fehlt ..\..\) und

Code: Alles auswählen

{$ENDIF};

soetwas ist nich pascal conform und zumindest mit dem fpc 2.1.1 nicht kompilierbar nur so nebenbei...

Joa hast recht poste doch mal nen bugreport dazu fällt aber auch schon bei TUpDown z.b. auf und mich persönlich störts z.b. nicht da dieser fehler
1. eh nur zur designtime auftreten kann
2. man sowas in einer komponente nicht unbedingt macht (nicht gerad resourcenshonend)

[schnullerbacke]

Na nun, soll ich da vielleicht erst wieder mit nem Canvas rummachen und das Rad neu erfinden, das kanns ja nun auch nicht sein. Beschränkt sich ja in aller Regel auf nur wenige Objekte.

[schnullerbacke]

@Christian

{$ENDIF};

Da haste wohl was in den falschen Hals gekriegt, das schließt nicht das Pragma ab, das Semikolon beendet die uses-Liste. Dann derf mer des.

[Christian]

bloss gut das da gar keine uses drüber ist lol noch nichtmal die implementation

[schnullerbacke]

Wo haste das denn gefunden, in CaptionPanel.pas jedenfalls nicht?