none
[VB2005] Scrollbar verzögert Aktualisierung RRS feed

  • Frage

  • Ich habe hier ein seltsames Phänomen. Ich hab nun ein wenig mit meinem ScrollableControl herumgestrickt, das ich inzwischen in ein Panel geändert habe (kommt aber im Endeffekt aufs selbe raus, was das Ergebnis angeht, funktionert auch beides), und ändere nun die Scrollbar.Value-Werte abhängig davon, was ich gerade an Tasten drücke. So weit, so gut; klappt ansich auch. Jedenfalls führt der Tastendruck korrekt zum Aufruf der Sub, die dann die Scrollbar verschieben soll. Er setzt sogar die Werte (habe die per Timer mal laufend ausgegeben). Dummerweise zeigt er sie aber nicht an, aktualisiert also nicht den Inhalt passend zu den gesetzten Value-Werten der Scrollbar.

    Genauer gesagt zeigt er sie schon an, aber 1 Änderung zu spät. Heißt, was ich eben hätte sehen müssen, seh ich beim nächsten Tastendruck / bei der nächsten fälligen Änderung. Die korrekte Anzeige der nächsten Änderung erst, wenn die übernächste Taste gedrückt wird. Also irgendwo ist da ein Anzeige-Delay drin oder sowas.

    Auch ein Me.Refresh, oder ein Me.Invalidate oder dgl. brachten bisher keinen Erfolg. Ich weiß langsam nicht mehr, woran es noch liegen kann, oder wo die Ursache für diese "Verzögerte" Anzeige steckt ...

    *ratlos*

    LG, Dennis.

    Dienstag, 4. Januar 2011 10:41

Antworten

Alle Antworten

  • Hallo Dennis,

    Ich habe hier ein seltsames Phänomen. Ich hab nun ein wenig mit
    meinem ScrollableControl herumgestrickt, das ich inzwischen in
    ein Panel geändert habe (kommt aber im Endeffekt aufs selbe
    raus, was das Ergebnis angeht, funktionert auch beides), und
    ändere nun die Scrollbar.Value-Werte abhängig davon, was ich
    gerade an Tasten drücke. So weit, so gut; klappt ansich auch.

    Hmmm....????
    Fröhliches Rätselraten?
    Ohne ein paar Zeilen relevanten Codes kann man sich darunter
    alles oder nichts vorstellen.

    Jedenfalls führt der Tastendruck korrekt zum Aufruf der Sub,
    die dann die Scrollbar verschieben soll.

    Und was macht diese Sub konkret wie (Code)?

    Er setzt sogar die Werte (habe die per Timer mal laufend
    ausgegeben). Dummerweise zeigt er sie aber nicht an,
    aktualisiert also nicht den Inhalt passend zu den gesetzten
    Value-Werten der Scrollbar.

    Wer ist "er"?
    Welche "Werte" setzt "er"?

    ... schnipp ...

    Wie schon angdeutet, kann man mit Hilfe Deiner Beschreibung
    nicht wirklich erkennen, was Du da machst, bzw. machen möchtest.
    Du kennst Deinen relevanten Code, vermutlich alle die Dein Posting
    hier lesen aber nicht.

    Gruß aus St.Georgen
    Peter Götz
    www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

    Dienstag, 4. Januar 2011 10:54
  • Hallo Dennis,

    mir geht es wie Peter: Ohne wenigstens etwas Code kann man sich unter Deiner Beschreibung alles oder nichts vorstellen.

    Der Satz "Genauer gesagt zeigt er sie schon an, aber 1 Änderung zu spät." verleitet zu der Vermutung,
    dass Du nach einen Off-By-One-Fehler suchen solltest (aber das ist nur geraten).

    Bedenke: .NET arbeitet durchweg 0-basiert, bei VB6 war das nicht (überall) so.

    Gruß Elmar

    Dienstag, 4. Januar 2011 12:32
    Beantworter
  • Hiho.

    Najut, also konkret sieht das etwa so aus ...

      Protected Overrides Sub OnKeyDown(ByVal e As System.Windows.Forms.KeyEventArgs)
        Select Case e.KeyCode
          Case Keys.PageUp
            'später
          Case Keys.PageDown
            'später
    ....
    ....
          Case Keys.Down
    '
    ' Hier ruft "er" (bei mir is "er" immer der doofe PC :-)
    ' jetzt eine Sub auf, die meinen Scrollbalken neu positioniert
    ' (s.u.)
    '
    ...
    ...
      End Sub
    
    Aufruf:
            Me.VerticalScroll.Value = Max(0, Min(MaxYStart, ActualY))
    
    
    
    So, und wenn ich das richtig versteh, müsste durch das neu positionieren des Balkens (neuer Value Wert) doch dann auch der Fensterausschnitt verschoben und teilweise neu gezeichnet werden. Instant.

    Das "verzögern" meint jetzt, dass wenn ich 2 Tasten drücke (also 2 mal obige Keydings durchlaufe), und beidesmal Verschiebungen im Fenster passieren (müssten), er beim 2. Tastendruck erst die Änderug anzeigt, die der 1. Druck schon auslösen hätte müssen.

    Tests ergaben, dass auch wirklich "Me.VerticalScroll.Value = ..." durchlaufen wird, also beide Male tatsächlich der Wert neu bestimmt wird. Auch ist beide Male das Offset verändert, also der Clipbereich des Controls wirklich echt verschoben worden. Dennoch zeichnet das Control nix neu und der Balken bleibt unbewegt (beim ersten Tastendruck), und erst beim 2. Druck bewegt er sich (gerade soweit, wie er es hätte beim ersten tun müssen). ...

    Wenn ich den Scrollbalken hingegen mit der Maus manuell bewege, ist alles wie gewünscht ... nur das Setzen "vom Code aus" klappt irgendwie nicht, bzw. führt verspätet erst zu (dann natürlich falschen) Resultaten.

    Hoffe es ist jetzt etwas klarer was ich meine ...

    LG, Dennis.
    Dienstag, 4. Januar 2011 14:19
  • Ach so ... was den +-1 Fehler angeht, habe ich (meines Wissens nach) alles bereits 20, 30 vielleicht 40 Mal durchgecheckt ... genau weil ich diese Art Fehler kenn und sich bei verschiedenen Zählarten (mal 1 basierend, etwa bei TextPosition, mal 0 basierend, wie bei *.Count bzw *.Index) gern mal was einschleicht. Aber mir ist trotz vielfachen durchdenkens, und teilweise neuschreibens und vergleichens kein solcher Fehler aufgefallen. Ich würde diese Kategorie Fehler also mal "eher ausschließen". (Es sei denn ich bin inzwischen ganz blind, was meinen Code angeht :D ).

    Ich vermute eher irgendwas in die Richtung Fehler beim Redraw oder beim Ableiten oder so ... oder einen Verständnisfehler was die Funktionsweise des Basiscontrols (Panel) angeht. Weil die entscheidenden Stellen, wo Werte verändert werden sollen (incl. dem, wo der Scrollbar.Value verändert wird), werden durchlaufen. Es scheint alles korrekt. Und lustigerweise funktioniert es ja irgendwie auch teilweise ...

    wenn ich beispielsweise

    - eine Taste drücke (s.o.) und der Aufruf zum Verändern des Value Wertes erfolgt

    - und dann (weil sich am Ausschnitt nix tut, und nix neu gezeichnet wird) das Fenster leicht resize

    zeichnet er neu.

    wenn ich

    - zweimal die Taste drücke und zweimal der Valuewert verändert wird, so dass zwei mal der Controlausschnitt gescrollt werden sollte

    seh ich die Änderung, wie sie nach dem erstem mal hätte passieren sollen.

    Wenn ich das Fenster (mit dem Control drin) MINIMAL vergrößere, aktualisiert sich das Control und es ist alles korrekt (was mir irgendwie das Gefühl gibt, dass die internen Werte eigentlich stimmen, und meine Routine korrekt arbeiten SOLLTE!), auch der Scrollbalken, auch der Clippingausschnitt. Aber irgendwie aktualisiert es eben nicht sofort, wenn ich den Wert verändere (also ...Scroll.Value = xy) ...

    *rätselhaft* :-(

    LG, Dennis.

    Dienstag, 4. Januar 2011 14:34
  • Hallo Dennis,

    Najut, also konkret sieht das etwa so aus ...

     Protected Overrides Sub OnKeyDown _
            (ByVal e As System.Windows.Forms.KeyEventArgs)

       Select Case e.KeyCode
         Case Keys.PageUp
           'später
         Case Keys.PageDown
           'später
    ....
    ....
         Case Keys.Down
    '
    ' Hier ruft "er" (bei mir is "er" immer der doofe PC :-)
    ' jetzt eine Sub auf, die meinen Scrollbalken neu positioniert
    ' (s.u.)
    '
    ...
    ...
     End Sub

    Na ja, "konkret" ist aber schon was anderes.
    Was soll man mit diesem Codefragment anfangen?
    Um wessen KeyDown-Ereignis handelt es sich hier?
    Was bedeutet " 'später"?

    Aufruf:
           Me.VerticalScroll.Value = Max(0, Min(MaxYStart, ActualY))

    Auch hier veranstaltest Du wieder reines Rätselraten.
    Wie soll man

        Max(0, Min(MaxYStart, ActualY))

    interpretieren?
    Was sind das für Werte, die darin enthalten sind?
    Woher kommen sie?

    ]So, und wenn ich das richtig versteh, müsste durch das
    neu positionieren des Balkens (neuer Value Wert) doch
    dann auch der Fensterausschnitt verschoben und teilweise
    neu gezeichnet werden. Instant.

    Ob das wirklich so ist oder zumindest sein sollte, lässt sich
    an dem, was Du hier zeigst beim besten Willen nicht erkennen.

    Das "verzögern" meint jetzt, dass wenn ich 2 Tasten drücke
     (also 2 mal obige Keydings durchlaufe), und beidesmal
    Verschiebungen im Fenster passieren (müssten), er beim
    2. Tastendruck erst die Änderug anzeigt, die der 1. Druck
    schon auslösen hätte müssen.

    Tests ergaben, dass auch wirklich "Me.VerticalScroll.Value = ..."
    durchlaufen wird, also beide Male tatsächlich der Wert neu
    bestimmt wird.

    Um diese Änderung am Bildschirm sichtbar zu machen
    muss Windows auch Gelegenheit bekommen, das Neuzeichnen
    des betr. Bildschirmbereiches auch wirklich auszuführen.
    Ohne zu Wissen, was Dein Code wirklich macht (irgendwelche
    Schleifen, sonstige recheninstensive Abläufe usw.), kann
    man das von hier aus nicht beurteilen.

    Auch ist beide Male das Offset verändert, also der Clipbereich
    des Controls wirklich echt verschoben worden.

    Wie, womit stellst Du das fest?

    Dennoch zeichnet das Control nix neu und der Balken bleibt
    unbewegt (beim ersten Tastendruck), und erst beim 2. Druck
    bewegt er sich (gerade soweit, wie er es hätte beim ersten
    tun müssen). ...

    Wenn ich den Scrollbalken hingegen mit der Maus manuell
    bewege, ist alles wie gewünscht ... nur das Setzen
    "vom Code aus" klappt irgendwie nicht, bzw. führt verspätet
    erst zu (dann natürlich falschen) Resultaten.

    Wie schon erwähnt kann man mit dem was Du hier als
    "konkreten Code" anbietest, nicht auf ein mögliches
    Problem schliessen.

    Hoffe es ist jetzt etwas klarer was ich meine ...

    Nein, eigentlich kein bisschen.

    Gruß aus St.Georgen
    Peter Götz
    www.gssg.de (mit VB-Tipps u. Beispielprogrammen)

    Mittwoch, 5. Januar 2011 08:20
  • Na ja, "konkret" ist aber schon was anderes.
    Was soll man mit diesem Codefragment anfangen?
    Um wessen KeyDown-Ereignis handelt es sich hier?
    Was bedeutet " 'später"?

    Naja das von meinem Control, also von der Klasse, abgeleitet von ScrollableControl bzw. Panel (im Grunde wurscht, weil beide Male funktioniert es identisch bzw. produziert den selben Fehler, und von welchem von beiden ich ableiten soll/will, bin ich mir irgendwie unsicher. Auch Recherchen dazu fördern komplett unterschiedliche Meinungen/Empfehlungen zutage)

    Auch hier veranstaltest Du wieder reines Rätselraten.
    Wie soll man

        Max(0, Min(MaxYStart, ActualY))

    interpretieren?
    Was sind das für Werte, die darin enthalten sind?
    Woher kommen sie?

    Max/Min sind eigene kleine Funktionen (Maximum/Minimum zweier Werte halt). MaxYStart ist der maximale Y-Offset fürs Scrollen, ActualY eben der aktuelle (im idealfall erhöhte) Y Wert des Clipping-Ausschnittes. Es ist halt eine Sichtfläche, die ein Teil einer größere Fläche is, und die ich scrollen will, abhängig von Tastatureingaben bzw. Werteveränderungen in einer Art Cursor.

    Ob das wirklich so ist oder zumindest sein sollte, lässt sich
    an dem, was Du hier zeigst beim besten Willen nicht erkennen.

    Naja, nimm irgendein Control, das Scrollbars hat. Machs so klein, dass auch wirklich Scrollbars angezeigt werden, und verändere durch den Code den Scrollbar.Value-Wert. Dann sollte man doch annehmen, dass dann das Ding auch beginnt zu scrollen an die neue Position, heißt: Bildinhalt neuzeichnen (teilweise oder ganz, je nachdem wohin man scrollt) und die Scrollbar selbst wird auch neu gezeichnet, weil der Balken ja woanders ist. Oder nicht? Das Problem is irgendwie auch, dass das ScrollableControl mir nur sehr wenige Zugriffsmöglichkeiten auf den Scrollbalken gibt. Eigentlich an relevanten Dingen nur den Wert, SmallChange, LargeChange. Und das Scroll.Ereignis, was ich abfange bzw. erbe und darin auch den Ausschnitt neu zeichne. Das ist aber alles im Lot. Wie oben beschrieben ist beim manuellen (maus-gesteuerten) Scrollen ja alles prima.

    Um diese Änderung am Bildschirm sichtbar zu machen
    muss Windows auch Gelegenheit bekommen, das Neuzeichnen
    des betr. Bildschirmbereiches auch wirklich auszuführen.
    Ohne zu Wissen, was Dein Code wirklich macht (irgendwelche
    Schleifen, sonstige recheninstensive Abläufe usw.), kann
    man das von hier aus nicht beurteilen.

    Also ich habe keine langwierigen Berechnungen oder Schleifen drin. Die einzige Schleife ist vergleichsweise rasend schnell. Auch keine weiteren Rechenabläufe. Geschwindigkeit ist nicht das Problem. Ich setze ja nur eine Art Grafikcursor an eine neue Position und will den Inhalt dementsprechend scrollen.

    Auch ist beide Male das Offset verändert, also der Clipbereich
    des Controls wirklich echt verschoben worden.

    Wie, womit stellst Du das fest?

    Naja, durch ausgeben halt. :-) Ich lass mir die Werte an mehreren Stellen anzeigen. Da sieht alles richtig aus, der Überlauf wird erkannt, die Position des Cursors wird verändert. Ich raff nicht, wieso er einfach bei den selben Ausgangswerten einmal den Scrollwert ändert und einmal nicht.

    Wie schon erwähnt kann man mit dem was Du hier als
    "konkreten Code" anbietest, nicht auf ein mögliches
    Problem schliessen.

    Naja, da kann ich theoretisch gleich meine ganze Klasse schicken ... :-(

    Hoffe es ist jetzt etwas klarer was ich meine ...

    Nein, eigentlich kein bisschen.

    Verdammt. :-D

    Also gut, hier einmal meine komplette Sub zum Cursor versetzen ... auf die Gefahr hin, dass danach alles noch unklarer ist. :-)

      Function CursorZeile(ByVal N As Integer) As Boolean
        Dim OK As Boolean = True
        Dim FL As Integer = FirstShownLine()
        Dim NosL As Integer = NumberOfShownLines()
        frmMain.TextBox1.Text = ""
        If (MyCursor.Y + N) >= 0 And (MyCursor.Y + N) <= MyText.Zeilen.Count - 1 Then
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MyC.Y vor allem: " & Str(MyCursor.Y) & vbCrLf
          MyCursor.Y = MyCursor.Y + N
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "FL / NosL / VScrV vorher: " & Str(FL) & " / " & Str(NosL) & " / " & Str(Me.VerticalScroll.Value) & vbCrLf
          If MyCursor.X > MyText.Zeile(MyCursor.Y).Text.Length Then
            MyCursor.X = MyText.Zeile(MyCursor.Y).Text.Length
            frmMain.TextBox1.Text = frmMain.TextBox1.Text & "Cursor X wird korrigiert" & vbCrLf
          End If
          'If Me.VerticalScroll.Enabled Then
          'MsgBox(Str(TextEnde.Left) & Str(TextEnde.Top))
          'MyCursor.Y*ZeilenHoehe ' <--TopY der aktuellen Zeile
          '0' <--- Absolut Y-Minimum des Ausschnitts
          'Mytext.zeilen.count-Nosl*Zeilenhoehe'<---- max TopY des Abschnitts
          '
          '
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MyC.Y nach Step 1: " & Str(MyCursor.Y) & vbCrLf
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "FL / NosL / VScrV nach Step1: " & Str(FirstShownLine) & " / " & Str(NumberOfShownLines) & " / " & Str(Me.VerticalScroll.Value) & vbCrLf
          If MyCursor.Y > FL + NosL - 1 Then
            Dim MaxYStart As Integer = (MyText.Zeilen.Count - NosL) * ZeilenHoehe()
            Dim ActualY As Integer = (MyCursor.Y - NosL + 1) * ZeilenHoehe()
            'MyBase.RaisePaintEvent(Me, New PaintEventArgs(MyBase.CreateGraphics, MyBase.ClientRectangle))
            frmMain.TextBox1.Text = frmMain.TextBox1.Text & "Werte aus Step1: " & Str(0) & " < " & Str(ActualY) & " < " & Str(MaxYStart) & " ?" & vbCrLf
            Me.VerticalScroll.Value = Max(0, Min(MaxYStart, ActualY))
            'Me.Update()
            frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MYCursor Y größer als FL+NosL-1" & vbCrLf
          End If
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MyC.Y nach Step 2: " & Str(MyCursor.Y) & vbCrLf
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "FL / NosL / VScrV nach Step2: " & Str(FirstShownLine) & " / " & Str(NumberOfShownLines) & " / " & Str(Me.VerticalScroll.Value) & vbCrLf
          If MyCursor.Y < FL Then
            Dim MaxYStart As Integer = (MyText.Zeilen.Count - NosL) * ZeilenHoehe()
            Dim ActualY As Integer = MyCursor.Y * ZeilenHoehe()
            'MyBase.RaisePaintEvent(Me, New PaintEventArgs(MyBase.CreateGraphics, MyBase.ClientRectangle))
            Me.VerticalScroll.Value = Max(0, Min(MaxYStart, ActualY))
            'Me.Update()
            frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MYCursor Y kleiner FL" & vbCrLf
          End If
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "MyC.Y nach allem: " & Str(MyCursor.Y) & vbCrLf
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "FL / NosL / VScrV nach allem: " & Str(FirstShownLine) & " / " & Str(NumberOfShownLines) & " / " & Str(Me.VerticalScroll.Value) & vbCrLf
          'End If
        Else
          OK = False
          frmMain.TextBox1.Text = frmMain.TextBox1.Text & "OK False" & vbCrLf
        End If
        Return OK
      End Function
    

    Mitsamt aller ausgaben (frmMain.Textbox ist halt eine TB zum Ausgeben der ganzen relevanten Variablen ...). Die Auskommentierten Zeilen warn Versuche irgendwas zu verbessern, aber das half alles nix. Genausowenig wie irgend ein refresh, oder invalidating ... grml.

    Hilft das dir mein Problem zu verstehen? Langsam glaub ich mein VB will mich veräppeln. ;-)

    LG, Dennis.

    Mittwoch, 5. Januar 2011 09:40
  • Naja das von meinem Control, also von der Klasse, abgeleitet von ScrollableControl bzw. Panel (im Grunde wurscht, weil beide Male funktioniert es identisch bzw. produziert den selben Fehler, und von welchem von beiden ich ableiten soll/will, bin ich mir irgendwie unsicher. Auch Recherchen dazu fördern komplett unterschiedliche Meinungen/Empfehlungen zutage)

    Hallo Dennis,

    ich glaube Du hast es noch nicht wirklich verstanden. Es gibt schon ein Grund warum "2 Controls" gibt. ScrollableControl ist eigentlich die Basisklasse für ein bzw. Panel.

    So steht in der MSDN zu ScrollableControl:

    Definiert eine Basisklasse für Steuerelemente, die den automatischen Bildlauf unterstützen.

    und zu Panel:

    Wird zum Gruppieren von Auflistungen von Steuerelementen verwendet.

    Und bleiben wir bei Panel, so schau Dir mal die Vererbungshierarchie an:

    System..::.Object
      System..::.MarshalByRefObject
        System.ComponentModel..::.Component
          System.Windows.Forms..::.Control
            System.Windows.Forms..::.ScrollableControl
              System.Windows.Forms..::.Panel
                Microsoft.Web.Management.Client.Win32..::.ManagementPanel
                System.Windows.Forms.Design..::.ComponentEditorPage
                System.Windows.Forms..::.FlowLayoutPanel
                System.Windows.Forms..::.SplitterPanel
                System.Windows.Forms..::.TableLayoutPanel
                System.Windows.Forms..::.TabPage
                System.Windows.Forms..::.ToolStripContentPanel

    Der Umgang mit der Basisklasse ScrollableControl ist eigentlich sehr simpel, wenn man weiß was man tut. Bei Dir glaube ich das allerdings nicht.

    Die Steuerung des Bildlaufes wird bei ScrollableControll nicht über die Bildlaufleisten(ScrollBars) realisiert sondern über die AutoScrollPosition-Eigenschaft. Refreshes oder Invalidates kann man sich dann sparen, weil das Control weiß das es sich neu zu zeichnen hat. Zusätzliche und damit unnötige Aufrufe bedeuteten nur mehr Laufzeit, fast zu "komischen" Seitenefekten führt.

    Und was das "veräppeln" betrifft, so machst Du das selber schon ganz gut. ;=) Denn wenn ich Deine Code richtig deute,bist Du auf dem völlig falschem Weg.

    Ich kann Dir an dieser Stelle nicht weiter helfen, aber Dir auf jeden Fall verraten das Dein Ansatz falsch ist.

    --

    Gruß Scotty

    • Als Antwort markiert Dennis Becker Montag, 10. Januar 2011 13:50
    Donnerstag, 6. Januar 2011 12:01
  • Hi Karsten,

    also das mit Panel vs. ScrollableControl war mir schon klar, dass das erstere eher ein Container ist. Und da ich (im Moment) nicht beabsichtige Objekte einzubetten, ist es genaugenommen das falsche Basiscontrol. Soweit ist mir das schon klar. Darum war ich zunächst auch vom ScrollableControl ausgegangen. Die Idee mit dem Panel kam hier in einem anderen Thread mal auf (glaube von Elmar), und begegnete mir stichwortartig auch in anderen Quellen im Web beim Suchen. Dass sich an meinem bisherigen Control nichts funktional änderte, mag schlicht daran liegen, dass Panel ja auch nur von ScrollableControl erbt und ich nicht auf die spezifischen Änderungen des Panels eingegangen bin bisher.

    Was ich etwas verwirrend finde ist, dass die Scrollbars (auch im ScrollableControl) erst dann aktiv werden, wenn es eingebettete Objekte außerhalb des sichtbaren Bereichs gibt. Dass dort irgend etwas gezeichnet wurde, reicht nicht. Also ein Bild als Hintergrund zu nehmen, das übergroß ist, führt glaube ich nicht zu Scrollleisten. Oder auch ein Textschriftzug, der über den Rand hinaus geht.

     

    Ein sehr interessanter Punkt ist das mit dem AutoScrollPosition. Das muss ich mir mal genauer durchlesen in der Hilfe. Eine direkte Frage dazu vielleicht aber schon: Wenn ich AutoScrollPosition.X und .Y setze, manuell durch den Code, verändert sich dann auch der Ausschnitt bzw. scrollt das Control dann entsprechend? Sind diese Werte auch zum Setzen gedacht? Weil mir kommt es langsam so vor, als wäre das, was das Control "scrollable" macht, eher für den maustechnischen Scroll-Aspekt, also für das bedienen mit der Maus, um zusätzliche Inhalte "zu erreichen". Nicht so sehr um durch den Code auf das Scrolling einzuwirken (z.B. weil man Tasten Bild-Hoch/-Runter drückt, oder weil timer-gesteuert irgendwie der Inhalt "vorsichhinscrollt"). Kann das sein?

     

    Last but not least, bezweifel ich auch gar nicht, dass mein Ansatz in gewissen Punkten falsch ist (oder sein könnte). Genau das beabsichtige ich ja hier herauszufinden, wo er das vielleicht ist, um ihn zu korrigieren. :-)

    Aber schonmal Danke für die Anregung mit dem "autoscrollposition".

    LG, Dennis.

    • Als Antwort markiert Dennis Becker Montag, 10. Januar 2011 13:49
    • Tag als Antwort aufgehoben Dennis Becker Montag, 10. Januar 2011 13:49
    Freitag, 7. Januar 2011 09:14
  • Hi Karsten, Hi ihr Übrigen.

    Also das mit dem Autoscrollposition ist noch etwas verwegen ... vor allem, wieso ich positive Zahlen setzen kann ... hingegen aber immer negative zurückbekomme ...

    Also etwa MyScroll.autoscrollposition = new point(50,50)

    Ausgabe bei

    Msgbox(str(MyScroll.autoscrollposition.x)) => ergibt -50

    Vielleicht kennt ja da noch jemand den Grund für ... mir erschließt er sich nicht.

    Aber auf jeden Fall ist mein Scrollingproblem damit GELÖST. Alles funktioniert im Moment prächtig und ich bin ganz happy. :-)

    LG, Dennis.

    Montag, 10. Januar 2011 13:49
  • Hallo Dennis,

    verabschiede Dich erst malvon allen Vorstellungen, die ScrollableControll-Class ist alles als einfach wen man sie nicht verstanden hat. Diese Klasse ist kein Control und genauso wenig die Control-Klasse. Diese Klassen bieten nur eine Grundlage und den erforderlichen Device-Context damit darauf etwas darstellen kann. Beide kalssen sind ähnlich nur das ScrollableControl noch die Funkion des Scrollens mitbringt. Ansonsten sind die Klassen aber "nackt", sie besitzen keine besondere Funktion, dafür bist Du als Developer verantwortlich.

    Da wir hier aber nicht über Control sondern über ScrollableControl sprechen will ich auf Control nicht weiter eingehen und bei ScrollableControl bleiben.

    ScrollableControl ist keine Klasse die man direkt aus dem Designer benutzt, Dafür gibt es schon abgeleitete Klasse(Panel, GroupBox etc.). Viele List- und Table-Sichten sind ebenfalls von ScrollableControl abgeleitet, das soll uns aber nicht stören.

    Wie Scrollable schon aussagt ist es eine Klasse die uns die Logik über die ScrollBars abnehmen soll, und genau das tut sie auch. Deswegen das "Auto" vor den entsprechenden Eigenschaften. Du hast eine AutoScrollPosition und eine AutoScrollMinSize-Eigenschaft. Stell Dir das jetzt so vor, das Du eine Blatt in der Größe eines DinA5 hast, es ist die Größe Deine Controls. Das Dokument ist aber DinA3 also vielzu groß für Dein Control. Nun wird also die AutoScrollMinSize-Eigenschaft auf die Größe den DinA3-Dokuments gesetzt. Das ScollableControll "verpasst dann der Oberfläche" die ScrollBars. Die Scrollbars funktionieren auch, Du kannst die Position über die AutoScrollPosition abfragen. Diese kann eigentlich nur negative Werte annehmen, deswegen ist Deine Beobachtung richtig und sollte nicht zur Verwirrung führen. Eine Positionierung auf positive Koordinaten sollte ohne Erfolg bleiben, die Position sollte auf max. 0 jeder Koordinate stehen bleiben.

    Bei weiteren Fragen stehe ich gerne zur Verfügung

    --

    Gruß Scotty

     

    Dienstag, 11. Januar 2011 19:14