' schrieb:1. "Wenn ein Schleife zu schnell ist..." -> Das Verhalten wurde mit einem VI nachgestellt, das nichts weiter enthält als das Darstellen einer Zahl. Mit einer Taktrate von 100ms.
2. Der Fehler tritt nicht auf, sobald man die Plotlegende 'rausnimmt. (so ein besonders schlaues Feature)
3. "Sobald eine Pause kommt..."?? -> Wenn man z.B. ein kleines Windows Fenster anfasst und es über das lückenhafte Diagramm 'drüberwischt, ist der Graph in Ordnung. (ist das nicht eine zusätzliche graphische "Belastung")
4. Nochmal : NI hat den Fehler bestätigt. CAR Nummer folgt.
Jetzt Du ! 
Eine Bestätigung des Fehlers sagt grundsätzlich nichts. Da wird nähmlich nicht gesagt, ja das ist ein Fehler und wir werden es morgen fixen. Ein CAR besagt nichts anderes als dass da jemand ein wenig Zeit reingesteckt hat um es zu reproduzieren und der Effekt grundsätzlich als nicht nur der Fantasie eines überarbeiteten Programmiers entsprungen akzeptiert wurde und glaube mir ich habe im technischen Support gearbeitet und da kommen manchmal Bug Reports rein von sogenannten "professionelen" Programmieren wo man sich fragt ob so jemand überhaupt weiss wo bei einer Maus vorne und hinten ist.
Was danach mit dem CAR geschieht kann sehr verschieden sein.
[Ironie]
1) Ein Developer findet es Wert um etwas Zeit zu investieren und kann mit 99%-er Sicherheit garantieren dass es keine unschönen Nebeneffekte in anderen Teilen von LabVIEW gibt und der Fehler ist in der nächsten Version behoben.
2) Ein Developer untersucht es und kommt zum Schluss dass es etwas ist das behoben werden sollte hat aber keine Zeit und/oder kann nicht ausschliessen dass dies an anderen Orten in LabVIEW komische oder gar schlechte Einflüsse haben könnte. -> Der Bug wird als offen klassiert und in eine laaaaaaaaaaaaaaange Liste von anderen Bugs gesetzt die von Zeit zu Zeit von jemandem mit etwas freiere Zeit (gibts bei Programmieren grundsätzlich nicht also macht es ein Produktmanager) durchsucht wird und nach Prioritäten sortiert wird. Optische Fehler haben dabei nicht gerade gute Karten um in die Top 10 zu kommen.
3) Ein Developer findet das einen von der Hardware und/oder Mondfase, Laune des Programmieres etc. abhängiges Problem. Im besten Fall wird es dann deferred (auf die lange Bank geschoben) oder aber gleich als NMP (not my problem) abgeschlossen.
4) Ein Developer findet das ein Feature (zum Beispiel CPU Belastung sparen) und es wird als NAB (Not a Bug) abgeschlossen.
[/Ironie]
Ist das schlimm? Mag für Dich so aussehen da dieser Bug für Deine Applikation das Killerargument ist. Im Grossen und Ganzen werden aber eher wenige Leute damit Probleme haben, da man halt nicht Elemente übereinander legen sollte.
Rolf Kalbermatter
