Zoomen des Blockdiagramms

Hallo,
Ich fände es wesentlich angenehmer, wenn man das Blockdiagramm zoomen könnte, um größere Programme besser überblicken zu können.
Das Navigationsfenster ist meistens zu klein bzw. zu umständlich.

Mfg, Holger

Anzeige

Du sollst auch nicht größer programmieren als eine Bildschirmgröße.
Dafür gibt es ja SubVIs.

Gruß Markus

' schrieb:Hallo,
Ich fände es wesentlich angenehmer, wenn man das Blockdiagramm zoomen könnte, um größere Programme besser überblicken zu können.
Das Navigationsfenster ist meistens zu klein bzw. zu umständlich.

Mfg, Holger

' schrieb:Hallo,
Ich fände es wesentlich angenehmer, wenn man das Blockdiagramm zoomen könnte, um größere Programme besser überblicken zu können.
Das Navigationsfenster ist meistens zu klein bzw. zu umständlich.

Mfg, Holger

Finde ich für gute Idee ist aber bestimmt schwer zu realisieren, dazu müsste man ALLES im BD von Pixelgrafik auf Vektorgrafik umstellen.

' schrieb:Ich fände es wesentlich angenehmer, wenn man das Blockdiagramm zoomen könnte, um größere Programme besser überblicken zu können.

Mit Verlaub...das ist eine totale Quatsch-Idee!

Allerdings hatten diese Idee schon andere vor dir...und das Ergebnis war ein Kompromiss, nämlich das Navigationsfenster! :wall:Ich glaube, der Vorschlag war auch schon mal hier im Forum zu finden!

Wie Y-P schon sehr treffend gesagt hat: Nicht größer als "normale" Bildschirmgröße coden, und du bist alle Sorgen bezüglich einer evtl. Unübersichtlichkeit des BD los! Alles andere ist sehr schlechter Stil!

Ich hab noch nie ein BD gebraucht, das größer ist als Bildschirmgröße...gut, manchmal "überschreite" ich den Rand ein wenig, aber ich versuche das zu vermeiden! Die richtige Vorgehensweise sind SubVI's. Gewöhne dir eine modulare, strukurierte Programmierung an...das hilft auch beim Debuggen! Außerdem ist die Programmierung mit Zustandsautomaten ("State Machine") ein gutes Mittel, um Programmschritte voneinander zu trennen und den Code leicht lesbar und übersichtlich zu halten!

Ich hab das schon mal irgendwo hier im Forum erwähnt: Ich hab schon Block-Diagramme gesehen, die waren auf DIN A4 ausgedruckt so ca. 2x3 m groß...das ist ein absolutes NO-GO...da würd' ich mich einfach weigern, mich auch nur ansatzweiße mit diesem Mist (sorry...) zu beschäftigen, weil man das einfach nicht mehr überblicken kann!

Gruß
Achim

' schrieb:Mit Verlaub...das ist eine totale Quatsch-Idee!

Allerdings hatten diese Idee schon andere vor dir...

die Idee kommt seit Anno Dazumal mit schöner Regelmäßigkeit auf's Tablett und wird von NI mit ebensolcher schöner Regelmäßigkeit mit dem Argument "Lies den LabVIEW Styleguide und lern anständig programmieren ..." abgehandelt. Ok, die NI Sales Representatives drücken sich etwas gewählter aus

' schrieb:Hallo,
Ich fände es wesentlich angenehmer, wenn man das Blockdiagramm zoomen könnte, um größere Programme besser überblicken zu können.
Das Navigationsfenster ist meistens zu klein bzw. zu umständlich.

Also bei mir geht das, obwohl ich das nicht benutze oder brauche, das muß ja kein Feature von LV selbst sein. Es geht mit der Matrox-Graphikkarte bzw. mit der dazu mitgelieferten Treiber-Software. Und wenn es mit der Graphikkarte selbst nicht geht, dann gibt es doch genügend PC-Softwareangebote für Blinde/Lahme/Stumme/Taube, die man bei Bedarf benutzen könnte. Gehören nicht zu Windows selbst solche Funktionen?
Am einfachsten wäre aber die Anschaffung eines Standard- 19"-Monitors, der, weil er die gleiche Auflüsung wie ein 17" Monitor hat und nur vergrößert, speziell für Sehschwache geeignet ist.
Ein gutes Programm (LABView) ist immer ein Kompromiß von ausreichend großer Funktionalität und Weglassen von Überflüssigem. Dafür hat LV meiner Meinung nach ein gutes Händchen und ich möchte das nicht geändert haben.

Ich kann den Wunsch sehr wohl nachvollziehen. Allerdings nicht für -, sonder + Zoom.
Ich habe hier ein Notebock mit 15" und 1920*1200 Bildpunkten. Da ist nicht wirklich viel zu sehen und zu lesen. Wenn ich auf größere Schriften im Windows umstelle, verschieben sich leider sämtliche Dialogfelder und LV ist nicht mehr wirklich zu bedienen.

Also Fazit, eine Zoomfunktion im Blockdiagram macht durchaus Sinn, auch wenn das Frontpanel nur auf 1024 *768 erstellt wird.
Und die Icon in Vectorgrafiken umzuwandeln sollte nicht das Problem sein. Das wird solangesam Standart um Icons stufenlos zu zoomen.
Zur Not reicht ja auch ein doppelter oder dreifacher Iconsatz ... (unterschiedliche Größen) wie er bei diversen Betriebssystemen dabei ist.

' schrieb:Ich kann den Wunsch sehr wohl nachvollziehen. Allerdings nicht für -, sonder + Zoom.
Ich habe hier ein Notebock mit 15" und 1920*1200 Bildpunkten. Da ist nicht wirklich viel zu sehen und zu lesen. Wenn ich auf größere Schriften im Windows umstelle, verschieben sich leider sämtliche Dialogfelder und LV ist nicht mehr wirklich zu bedienen.

Also Fazit, eine Zoomfunktion im Blockdiagram macht durchaus Sinn, auch wenn das Frontpanel nur auf 1024 *768 erstellt wird.
Und die Icon in Vectorgrafiken umzuwandeln sollte nicht das Problem sein. Das wird solangesam Standart um Icons stufenlos zu zoomen.
Zur Not reicht ja auch ein doppelter oder dreifacher Iconsatz ... (unterschiedliche Größen) wie er bei diversen Betriebssystemen dabei ist.

15" bei 1920*1200!!!!!! Das ist ja absoluter Blödsinn. Das funktioniert nur mit einem OS dessen Bildschirmausgabe eben nicht pixelorientiert ist sondern auf einer viel grösseren virtuellen Auflösung basiert. Windows GDI kann das simpel nicht, MacOS ist da ein klein wenig besser und BeOS hatte das mal ganz genau so. Da war jedes Ausgabegerät prinzipiel ein Postscript Gerät mit einer virtuellen Auflösung von ich glaube mal 1 Mil oder so. Das wurde dann automatisch in die physikalische Auflösung des Zielgerätes umgerechnet und dadurch waren so Hacks als BigFonts wie sie Windows hat gar nicht notig.

Um das innerhalb der Applikation wieder zu fixen ist einfach viel Arbeit für ein Display das keinen Sinn macht unter Windows.

Rolf Kalbermatter

' schrieb:15" bei 1920*1200!!!!!! Das ist ja absoluter Blödsinn. Das funktioniert nur mit einem OS dessen Bildschirmausgabe eben nicht pixelorientiert ist sondern auf einer viel grösseren virtuellen Auflösung basiert. Windows GDI kann das simpel nicht, MacOS ist da ein klein wenig besser und BeOS hatte das mal ganz genau so. Da war jedes Ausgabegerät prinzipiel ein Postscript Gerät mit einer virtuellen Auflösung von ich glaube mal 1 Mil oder so. Das wurde dann automatisch in die physikalische Auflösung des Zielgerätes umgerechnet und dadurch waren so Hacks als BigFonts wie sie Windows hat gar nicht notig.

Um das innerhalb der Applikation wieder zu fixen ist einfach viel Arbeit für ein Display das keinen Sinn macht unter Windows.

Rolf Kalbermatter

Naja ganz so Blödsinn ist das nicht mit der Auflösung, wenn man mit CAD Programmen arbeitet ist das schon fein.
Für das OS ist es aber wirklich eine Herausforderung.

' schrieb:Naja ganz so Blödsinn ist das nicht mit der Auflösung, wenn man mit CAD Programmen arbeitet ist das schon fein.
Für das OS ist es aber wirklich eine Herausforderung.

Es spricht ja nichts gegen eine hohe Auflösung, aber hier wird die Auflösung eines 24" Monitors 1920*1200 (= 96dpi) auf 15" (entsprechend 150dpi) zusammengequetscht. Wenn man sich das antut damit zu arbeiten will, sei es mit CAD oder mit LabVIEW, dann ist eine Lupenfunktion allerdings unentberlich. Wie ich schon sagte, gibt dafür genügend Hilfsprogramme. Abwegig ist es aber, von LabVIEW (oder einer Cadsoftware) zu verlangen, solche Sonderfunktionen, die man nur für diese exotischen 150dpi braucht, von Haus aus mitzubringen.