Announcement

Collapse
No announcement yet.

Probleme mit Frames

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Probleme mit Frames

    Hallo zusammen,

    gibt es noch weitere Leute, die Probleme mit dem Einsatz von Frames haben oder mache ich etwas falsch?

    Ich habe immer wieder Probleme mit Komponenten, die in Forms fehlerfrei laufen, in Frames aber plötzlich entweder nicht funktionieren oder Exceptions hervorrufen. Dies betrifft oft Fremdkomponenten (bei Orpheus z.B. funktioniert die Hint-Belegung von Edit-Feldern zur Laufzeit aus einer Ressorcen-Datei nicht, bei Infopower führt ein TwwDBGrid mit einer verwendeten TwwDBLookupComboBox zu einer Exception). Diese Probleme gibt es bei der Verwendung der gleichen Komponenten in gleicher Konfiguration in Forms nicht!

    Gibt es eine Lösung?

    Mit besten Grüßen

    Uli

  • #2
    HI

    Ja, anstatt mit Frames zu arbeiten, leitet man von TForm eine neue Klasse ab. Durch das überschreiben weniger Messages/Methoden kann man diese Form-Klasse als "inplaced Panels" benutzen. Es läuft auf das gleiche wie Frames herraus, nur das die Vererbungshierearchie eine andere IST. Die "anfälligen" Controls versuchen nämlich auf das übergeordete Form, als Owner der Komponente, zuzugreifen. Anstatt aber ein TCustomForm vorzufinden, finden sie bei Frames ein TFrame vor. Und Bums, ohne Typüberprüfung, hast Du Deine Exceptions !!

    Die Frage ist nun,
    <li>hat Borland durch die unbedachte Vererbungsreihenfolge der TFrame's,
    <li>oder der Programmierer der Fremdkomonenten (durch die unberechtigte Annahmen das Componente.Owner is TCustomForm ist),

    an der Missere schuld.

    Gruß Hage

    Comment


    • #3
      Hallo Hagen,

      vielen Dank für den Tip, ich werde einige der Frames direkt umsetzen. Auf der anderen Seite können Frames durch die Vererbung aber auch so praktisch sein...

      Schade, dass sie nicht immer funktionieren. Ob ich die Vererbung bei "inplaced Panels" genauso nutzen kann, muss ich mir mal ansehen.

      Gruß

      Ul

      Comment


      • #4
        Natürlich ! Diese "inplaced Formulare" sind ja während der Designzeit ganz normale Forms, eben wie bei den Frames.

        Wobei ich aber auf diese "Vererbung" absolut verzichte, da das Streamingsystem arge Probleme hat, lieber kopiere ich den Mist oder lege ein TCustomModule an.

        Gruß Hage

        Comment


        • #5
          Hallo,

          Wenn es bei uns mit der Verwendung von Frames nicht zu Exceptions kommt, so funktionieren Sie bei uns teilweise einfach nicht. So werden z.B. Messages von DnD Operationen schlichtweg unterschlagen.

          Was wohl wieder mal bleibt bleibt, ist die Bestätigung der Erfahrung auf "neumodischen" Kram zu verzichten.

          Oder ist jemand den Anomalien von Frames mal näher zu Leibe gerückt ??

          Gruß Gesin

          Comment


          • #6
            Hallo Hagen,<br>hättest Du mal ein Beispiel für "inplaced Panels" ?:-) Jens Schuman

            Comment


            • #7
              Hi

              <a href="/webx?50@@.ee70f9e/8">Hagen Reddmann "Verankern eines Formulars auf einem Nicht-VCL-Window" 20.03.2001 19:47</a>

              http://www.entwickler-forum.de/webx?128@@.ee6ff76

              Gruß Hage

              Comment


              • #8
                Hallo Hagen,<br>das klingt hier so interessant, dass ich es gleich mal ausprobiert habe. Grundsätzlich klappt auch alles. Aber wenn ich BorderStyle z.B. auf bsSizeable setze, erhält das Form nicht mehr den Fokus. Was kann ich denn dagegen tun?<br>:-) Jens Schuman

                Comment


                • #9
                  Hi

                  BorderStyle eines "inplaced" Formulars ? Warum ? entweder inplaced oder nicht ist die Deviese. Natürlich gibts auch Möglichkeiten das zu ändern, ABER rel. kompliziert. Grundsätzlich ist das Flag ws_Child entscheidend. Alle Forms mit einer Caption oder einem Rahmen, also einem NC-Bereich (Non-client) können NICHT ws_Child sein, also sind z.b. ws_Overlapped oder ws_Popup. Nun, abhängig von ws_Child ändert Windows das komplette Fensterverhalten ! Es gibt Zwitter, also ws_Child fenster MIT einem Non-client bereich, diese sind aber die Ausnahmen.

                  Gruß Hage

                  Comment


                  • #10
                    Hallo,

                    Falls man den FormStyle zur Laufzeit setzt, kam Windows schon immer und auch heute noch leicht aus dem Tritt.

                    Gruß Gesin

                    Comment


                    • #11
                      Hallo Hagen,<br>ich dachte, ich hätte mit dieser Methode einen Ersatz für MDI Anwendungen gefunden.<br>:-) Jens Schuman

                      Comment


                      • #12
                        @Jens,
                        leider nicht, höchstens ein Ansatz für "floating Toolbars"

                        @Gesine,
                        grundsätzlich entstehen solche "Probleme" durch die Methode .RecreateWnd. Diese Methode zerstört das Fensterhandle und erstellt sofort ein neues mit den neuen Einstellungen. Das ist absolut richtig und notwendig. Die Probleme entstehen NICHT durch den Borland source oder das Windowssystem, sondern eher durch Fremdkomponenten. Der meiste Fehler der gemacht wird ist, das einfach angenommen wird das die Lebenszeit eines Fensterhandle identisch mit dem der Controlkomponente ist. Der obige Fall wird aber mit solch einer "Recreation" ohne Schwierigkeiten fertig. Natürlich wird es IMMER Darstellungproblem o.ä. geben wenn der Anwender ohne tiefes Wissen solche Eigenschaften ändert. Ein TForm sollte also unsichtbar sein wenn man BorderStyle ändert, logisch wenn man überlegt das das aktuelle hWnd zerstört und durch ein neues ersetzt wird -> dann kann es ja nur flackern.
                        Beim FormStyle ist es nocheinmal komplizierter, da direkt das Streaming System betroffen ist.

                        Der "weitreichenstens Bug"/"Designfehler" auf Borlands Seite ist das während des Ladeprozesses (z.B. als DFM) die Größenverhältnisse berechnet werden. Nun, dafür wird die eingestellte Fontgröße mit einer in der DFM abgespeicherten verglichen, der Unterschied bildet dann das Ratio für ScaleBy(). Das Problem ist das das Form zu diesem Zeitpunkt KEIN Fensterhandle besitzt und besitzen darf, da noch nicht alle Komponenten komplette geladen wurden. Borland greift aber auf Form.Font und Form.Canvas um die Fontdimensionen zu berechnen. ABER, Form.Canvas ist ein TControlCanvas, und dieses Object benötigt bei Zugriff das das zugeordnetet Control ein Handle besitzt, ruft also Control.HandleNeeded !!
                        Endresultat: Der Entwickler designt mit kleinen Schriftarten, in der DFM ist das vermerkt, das Form soll autom. scaliert werden. Auf einem Usersystem mit identischen Fontgröße läufts ganz normal. Auf einem Usersystem mit anderer Fontscalierung passiert nun folgendes:
                        Mitten im Laden der DFM wird die Fontgrößen mit der abgespeicherten verglichen, diese sind unterschiedlich. Nun, das Form versucht die aktuelle Bildschirm Fontgröße zu ermitteln mit Form.Canvas.TextHeight() usw. Borland hat aber vergessen das Canvas ein TControlCanvas ist und immer intern Control.HandleNeeded == Form.HandleNeeded aufruft. D.h. in diesem Moment wird ein Fensterhandle erstellt !! Diese Erstellung benötigt aber z.b. FormStyle und BorderStyle und diese Eigenschaften wurden NOCH NICHT aus der DFM gelesen. Ein Form wird alsu IMMER die Standardwert für das Fenster nutzen und nach dem ganzen kram werden diese Eigenschaften gelesen, sind natürlich unterschiedlich, heist jedesmal wird .RecreateWnd das hWnd zerstören und wieder anlegen.

                        Analysiert man die originalsourcen, so stellt man fest das dieser "bug" in alle VCL Version vorhanden ist.

                        Gruß Hage

                        Comment


                        • #13
                          Hallo Hagen,

                          Das Problem ist durchaus auf dem Mist von MS gewachsen. Denn wenn ich in meinem Objektmodell Methoden anbiete, die das ganze dahinterhängende Objekt "abhängt", dann war ich -als es um den Begriff Kapselung ging- immer Kreide holen.

                          Gruß Gesin

                          Comment


                          • #14
                            Hi

                            Halt, die Kapselung kapselt die Windows Fensterfunktionalität = procedural orientiert, in der VCL in die bekannten objectorientierten TControls usw. NUN, M$ hat aber NICHT für Borland diese Kapselung programmiert sondern die VCL ist eine Borland Angelegenheit.
                            Wenn es also durch diese Kapselung zu ungereimtheiten kommt dann ist das nicht M$ Schuld.
                            Ich will hier kein Anwalt für MS sein, aber was Recht ist muss schon Recht bleiben.

                            Die Methode .RecreateWnd, die "das dahinterliegende Object abhängt" ist auch eine Borland Erfindung und ist ein Versuch eine per Design festgelegte "Schwäche" der Windows-Fenster auszugleichen.

                            Es gibt nämlich beim Erstellen von Fenstern bestimmte Einstellungen die NUR am ANFANG festgelegt werden können. Und genau hier betrifft das solche Eigenschaften wie BorderStyle/FormStyle usw.

                            Aber, jetzt stellt sich die Frage was ist sinnvoll und was nicht.
                            Im Normalfall wird der Typ/Grunddesign eines Fenster fest vorgegeben, also wird es größenveränderbar/MDI etc.

                            Gruß Hage

                            Comment

                            Working...
                            X