Benutzer mit den meisten Antworten
[VB2005] Scrollbar verzögert Aktualisierung

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.
Antworten
-
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..::.ToolStripContentPanelDer 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
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) -
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
-
Hiho.
Najut, also konkret sieht das etwa so aus ...
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.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))
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. -
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.
-
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 SubNa 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 manMax(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) -
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"?Auch hier veranstaltest Du wieder reines Rätselraten.
Wie soll manMax(0, Min(MaxYStart, ActualY))
interpretieren?
Was sind das für Werte, die darin enthalten sind?
Woher kommen sie?Ob das wirklich so ist oder zumindest sein sollte, lässt sich
an dem, was Du hier zeigst beim besten Willen nicht erkennen.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?
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.
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.
-
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..::.ToolStripContentPanelDer 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
-
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
-
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.
-
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