Beim Klick auf das Icon in der Playliste zeigt sich das PFL-Fenster nur für Sekundenbruchteile und verschwindet dann wieder.
Funktion “Klick auf Icon schaltet Extra PFL ein oder aus ist aktiviert”.
Hmhm, das hatten wir schonmal… grübel
Könnte durch aus sein. In Build 506 oder ist es der 507 läuft das PFL bzw. Extra PFL noch/wieder
Moment einmal ExtraPFL läuft. Nur klick auf Note geht nicht. Fenster erscheint kurz
Michel
Ja, genau. Irgendwie hatten wir den Fehler in der v2.1 bzw v2.2 schonmal. Auch wenn ich gerade nichts darüber finde, weder im Forum noch im SVN-Log. Vielleicht hab ich es auch nur geträumt
Offenbar ein Bug im Virtual Treeview: http://support.soft-gems.net/forums/viewtopic.php?t=2103
(mAirList 2.2 benutzt VT 4.4.3, mAirList 3.0 den neuen VT 4.7.0.)
Das könnte es gewesen sein
Erstellst Du das change.log manuell? --> “svn log > changelog.txt” wäre eine Alternative
Die Changelog.txt erstelle ich manuell. Aber ich kann natürlich zu jeder Datei des Sourcecodes im SVN nachschauen, wann ich was geändert habe. Und auch wenn ich alleine an mAirList arbeite, ich bin trotzdem so diszipliniert, bei jedem Einchecken eine aussagekräftige Beschreibung anzugeben. Es gibt Tage, da wird es einem gedankt.
Ich wühle mich gerade durch den VT-Quelltext. Mal gucken, ob ich den Grund für den Bug finde.
Ach, da ist der alte Thread ja. Gut gemacht!
Schade, dass die Lösung damals war, ein Downgrade zu machen Das ist in diesem Fall nicht möglich, denn unter anderem werden jetzt die neuen Virtual Shell Tools verwendet, die den neuen VT brauchen (und den Bug mit den fehlenden Ordnern bei USB-Sticks hoffentlich nicht mehr haben).
Also mal weitersuchen…
Also bei manchen Dateien aus einer alten Playlist kommt folgendes. Aber auch nicht bei allen. Vielleicht hilft es ja.
[code]Range check error
Montag, 19. Januar 2009, 21:47:39
Program Version 3.0.0 Build 523
Call stack:
[0058BEAB] EditItem.TEditItemForm.FormCreate (Line 353, “EditItem.pas” + 109) + $C
[004030EE] System.ErrorAt + $16
[0058BEAB] EditItem.TEditItemForm.FormCreate (Line 353, “EditItem.pas” + 109) + $C
[00486FDD] Forms.TCustomForm.DoCreate + $31
[00486C99] Forms.TCustomForm.AfterConstruction + $11
[00404C0D] System.@AfterConstruction + $1D
[0058B17A] EditItem.DoToggleExtraPFL (Line 201, “EditItem.pas” + 1) + $15
[0058AEA8] EditItem…TEditItemForm + $900
[0058B037] EditItem.DoStartExtraPFL (Line 181, “EditItem.pas” + 1) + $17
[00596926] PlaybackTreeView.TPlaybackTreeView.HandleMouseDown (Line 1571, “PlaybackTreeView.pas” + 2) + $7
[004FF2F4] VirtualTrees.TBaseVirtualTree.HandleMouseUp (Line 21662, “VirtualTrees.pas” + 38) + $D
[004F5A58] VirtualTrees.TBaseVirtualTree.WMLButtonDown (Line 16942, “VirtualTrees.pas” + 5) + $13
[00472767] Controls.TControl.WndProc + $2BB
[004EA196] VirtualTrees.TVTHeader.HandleMessage (Line 10983, “VirtualTrees.pas” + 143) + $7
[00476118] Controls.TWinControl.IsControlMouseMsg + $60
[00476605] Controls.TWinControl.WndProc + $499
[00503E3A] VirtualTrees.TBaseVirtualTree.WndProc (Line 23976, “VirtualTrees.pas” + 9) + $3
[004723F4] Controls.TControl.Perform + $24
[004FCA42] VirtualTrees.TBaseVirtualTree.DragFinished (Line 20365, “VirtualTrees.pas” + 4) + $2
[004FC430] VirtualTrees.TBaseVirtualTree.DoValidateCache (Line 20197, “VirtualTrees.pas” + 67) + $1D
[0046E32F] Controls.TBaseDragControlObject.Finished + $17
[0046F4E1] Controls.DragDone + $299
[0046E16E] Controls.TDragObject.WndProc + $92
[0046E255] Controls.TDragObject.MainWndProc + $1D
[0042F688] Classes.StdWndProc + $14
[0048FCBC] Forms.TApplication.ProcessMessage + $FC
[0048FCF6] Forms.TApplication.HandleMessage + $A
[0048FF16] Forms.TApplication.Run + $96
[007A6AAD] CoreGUIMainWindows…TPlayoutMainWindowClass + $55
[00402F68] System.@GetMem + $4
[007A6BB1] CoreGUIMainWindows…TTagMainWindowClass + $5
[009720B8] InstanceBuilder.CreateInstance (Line 119, “InstanceBuilder.pas” + 73) + $E
[0097D148] mAirList.mAirList (Line 103, “” + 13) + $5
[/code]
Hm, das wiederum habe ich noch nicht beobachten können. Kann man irgendein Schema feststellen, bei welchen Elementen das passiert und bei welchen nicht?
Den eigentlichen Fehler, um den es in diesem Thread geht, habe ich jetzt jedenfalls abstellen können mit dem Vorschlag, der in dem VT-Forum genannt wurde. Ich hoffe, das macht sonst nichts weiter kaputt.
Habe mit google folgendes gefunden:
[i]Standardmäßig verhalten sich die Spalten-Header wie Buttons. Teste es selbst, indem du dein aktuelles Projekt kompilierst und mit der Maus auf die Spalten klickst. Dabei werden übrigens auch zwei Ereignisse ausgelöst: OnColumnClick bzw. OnColumnDblClick. Erstes wird beim einfachen Klick ausgelöst, letzteres bei einem Doppelklick. Der Procedurekopf des Event-Handler kann so aussehen:
procedure TForm1.vstColumnClick(Sender: TBaseVirtualTree; Column: Integer;
Shift: TShiftState);
Der Parameter Column enthält den Index der Spalte, auf die der Anwender geklickt hat. [/i]
Und siehe da, bei einem Doppelklick auf die Note, bleibt das Fenster offen!
Nee, ich befürchte, so einfach ist die Lösung nicht.
Wenn du dir den VT-Sourcecode anguckst, findest du das Problem in der Methode DragFinished. Es ist nämlich so, dass bei jedem Mausklick erstmal ein Drag&Drop vorbereitet wird. Sicherheitshalber, man weiß ja nie, ob der User jetzt die Maustaste gleich wieder loslässt oder doch das Element irgendwo hinziehen möchte. Es gab wohl eine Änderung im VT, die dazu führt, dass dieses Drag&Drop-Flag jetzt zu früh gelöscht wird. Dadurch wird die Methode HandleMouseUp jetzt zweimal “scharf” aufgerufen.
Soweit die Kurzfassung