LVOOP im Kommen!

' schrieb:Aber du stimmst zu, dass ein Objekt mehr Features anbietet als ein Cluster? Zumindest muss dein BD nicht riesig sein, wenn du eine größere Objekt-Konstante dort einfügst, was man bei einer Cluster-Konstante nur bedingt machen kann.

klar bietet es mehr Features, aber LVOOP ist halt in meinen Augen noch lang nicht fertig. Wie gesagt: sobald ich da mit (ggf. am Anfang auch "unter Schmerzen") eine MFC-like Struktur aufbauen kann, auf der alle meine zukünftigen Projekte aufbauen werd ich zum glühenden Anhänger von LVOOP werden

Ich hol mal aus:
ATM beginne ich ein neues Projekt so: ich hab ein Projekt-Template das aus ca 200 (selbstgeschriebenen) VIs besteht, ständig verbessert wird und viele Features enthält, die ich eig. in jedem Projekt verwende. Ich hab ein Tool, das diese Projekt-Template öffnet und die ganze VI-Hierarchie meines Templates unter neuem Namen in einen neuen Ordner kopiert. D.h. aber auch: jedesmal wenn ich ein neues Projekt beginne werden erstmal 200 VIs kopiert, um anschließend leicht modifiziert zu werden. Wenn ich etwas von den Features die mitkopiert wurden ganz bestimmt nicht brauche kann ich das dann aus dem Code rausnehmen, das geht deutlich schneller als wenn ich ein fehlendes Feature dazuprogrammieren würde.

Meine Idee ist es - diesen ganzen Mist mit der Kopiererei (geht halt ATM noch nicht anders) - durch LVOOP zu ersetzen, sprich ich hab irgendwo meine OOP-Project LIB, die zieh ich in ein neues Projekt, leite von meinen Projekt-Basis-Klassen die entsprechenden Klassen für das neue Projekt ab und feddicht ist die Laube. Sollte ich mal einen Bug in einer Basis-Klasse finden fixe ich den eben und alle Projekte, die darauf aufsetzen sind gleich mit gefixt ...

Wenn ich sowas realisieren kann, dann spart mir LVOOP eine MEEEEEEENNGE Zeit - und da bei mir Zeit = Geld ist bringt mir das einen echten Wettbewerbsvorteil => ich werd es seeeeeehr lieb haben:)und so lang das halt noch nicht der Fall ist fluch ich "as laut as possible" über LVOOP in der Hoffnung dass etwas davon an die Ohren von NI dringt und das Feature so weiterentwickelt wird dass ich Geld damit verdienen kann

Was man zur Zeit mit LVOOP machen kann, ist dass man einzelne Funktionen mit LVOOP implementieren kann. Aber sein Projekt entwickelt man eig. nach wie vor im "alten Stil". Die sinnvolle Nutzung von OOP im Projekt ist auf einige, wenige Fälle beschränkt, weil es ATM in meinen Augen (noch) sowas wie ein in Cluster mit ein paar intelligenten Features ist. Dabei mag ich gar nicht abstreiten, dass diese Features für den ein oder anderen mehr geschätzt werden als von mir. Aber für mich ist es ATM einfach nur eine Geschmacks-Frage ob man LVOOP mit im Projekt verwendet und sich darüber zu streiten ob es Sinn macht oder nicht, ist wie ein Streit ob man Himbeer-Marmelade roter schmeckt als Erdbeere.

Ich hab auch absolut nix gegen Aussagen wie "ich nutze es gerne" oder so, wo mir nur immer wieder der Kragen platzt ist, wenn LVOOP so beworben wird (von Nutzern oder von NI) als wäre es JETZT schon eine tragfähige Lösung für größere Projekte und noch roter seh ich wenn mir jemand erklären will es wäre notwendig für ein Projekt > 100 VIs. Letztere Aussage werte ich so wie den besonderen Geschmack der Carmagnola-minze

Klar, NI versucht die Entwickler zu motovieren es zu nutzen, darum kommen solche Aussagen wie "ab einer Projekt-Größe von 100 VIs sinnvoll" oder "LVOOP ist im kommen". Schließlich will NI Feedback darüber wie es genutzt wird damit es weiter entwickelt werden kann. Aber das ist nicht mein Job. Wenn NI eine Studie haben will, wie man es sinnvoll einsetzen und weiterentwickeln kann, dann sollen sie mich engagieren - mach ich gerne, und weil es mir später dann hoffentlich von großem Nutzen sein wird geh ich sogar mit dem Stundensatz runter- aber ich werd mich nicht zum unbezahlten Beta-Tester machen lassen und ein Feature in der Produktion einsetzen dass nicht hält was der Name und die Werbung verspricht.