Wenn man im debugmode die Werte überprüfen will und bis in die Ebene eines Window’s steigt und dort auf Content schaut, dann kommt eine vollkommene ungeordnete Liste daher und bei umfangreichen Feldern und Labels muss man ganz lange suchen.
Das Sort funktioniert hier nicht mehr (eine stufe höher schon noch)
Ich habe das als Bug qualifiziert, doch es steht an Stelle 700 oder so.
Ich versteh nicht, dass das Anderen nicht auf die Nerven geht.
Sowas geht auf die Nerven.
Dafür kann man in den Code sich eine Abkürzung einbauen:
#if DebugBuild then
dim debugTextField1 as TextField = self.TextField1
#endif
und schon hat man eine lokale Variable für das Textfeld.
Es ist wirklich sehr störend. In Visual Studio Zeiten nutzte ich oft die Watch Möglichkeiten des Debuggers, um bestimmte Variablen einfach ins Watch Fenster zu ziehen. Auch die bedingten Breakpoints waren dort sehr hilfreich.
Ich habe schon aufgegeben daran zu glauben, dass diese Funktionen in nähere Zukunft in die IDE Einzug halten. Vielleicht bringt ja die Umstellung auf einen neuen Compiler auch hier noch Änderungen mit sich.
Soweit ich kapiert hab, wollen sie seit Jahren nix am Debugger ndern, sondern warten auf die Umstellung auf was neues nach dem LLVM Schritt.
Eine lokale Variable bilden ist keine Kunst, aber für alle Felder, die ich beobachten möchte - und dabei gehts eben um Fehlersuche, da weiss ich oft vorher nicht, was ich gerade anschauen muss - wird das mühsam.
Ich meine eine Sortfunktion im Debugger einbauen ist doch nicht so arg. Nur müssten mehr Leute diesen Fehler für wichtig erklären, dann käme das schon mal dran. Rank 768 ist natürlich aussichtslos
“Mach’s mit” 'nem schwebenden Fenster, in das du whrend des debuggens die Variablennamen und deren Werte reinschreibst.
wie meinst Du das?
Ein Fenster, Typ “Floating Window”, welches whrend der Laufzeit auf dem Bildschirm frei platzierbar ist, und in du das whrend des debuggens als Text die Namen der Variablen schreibst, und daneben deren Werte.
An entsprechenden Stellen in deinen Projekt schreibst du rein:
if debugbuild then
FloatingWndw.Textfield1.text="a="+str(a)
end if
Ich komme auch von VisualStudio. Dort ist ja das Debuging hervorragend gelöst, allein die Mouse-Over-Inline-Variablenprüfung bei Breakpoints sind eine riesen Hilfe. Bei Xojo muss man sich durch eine unübersichtliche Liste, die rein logisch für Hierarchien völlig ungeeignet ist, klicken.
Immer wenn ich von einem C# oder VB.NET-Projekt auf Xojo zurückwechsle sinkt allein deswegen meine Motivation.
Aushaltbar ist es nur, weil es immerhin noch schlimmer geht, wie bei reinen Webprojekten mit JS/ JQuery und PHP.
Man müsste Xojo mit VS schreiben können.
(btw: mich nervt es auch tierisch Variablen, Methoden etc. zusammen klicken zu müssen. Meine Maus glüht manchmal mehr als meine Tastatur.)
Der Feedback-Case für Tooltips wird bestimmt bald 10 Jahre alt: <https://xojo.com/issue/30> . Sogar VBA bekommt das hin.
Mein Graphik-Tablett ist wesentlich schneller als eine Maus. Muß das wegen meiner Arthritis verwenden. Die Umgewöhnungszeit ist allerdings heftig.
Habe mich vertan: ist schon über 10 Jahre alt!
Krass. Neja, Xojo ist halt nicht für Enterprise-Entwicklungen geeignet, sondern nur ein sehr umfangreiches Hobby-Tool.