Von VB6 zu VB.Net
Detlef Jäger
so langsam manifestiert sich bei mir der Gedanke einer zwingenden
Umstellung von VB6 auf VB.Net.
Ich bin in einer sehr kleinen Softwarefirma (Chef und ich) als
Supportmitarbeiter und Entwickler beschäftigt. Allerdings bin ich
Quereinsteiger und habe mir das Programmieren unter VB6 im Verlaufe
meiner Tätigkeit selbst beigebracht.
In diesem Umfeld habe ich mich gut eingearbeitet und arbeite auch
effektiv.
Unsere Hauptanwendung (eine Auftragsbearbeitung) ist mittlerweile ein
wirklich sehr komplexes Programm, das unseren Anwender nahezu alles
bietet und einen hohen Anspruch pflegt. Daneben gibt es zahlreiche
Tools und weitere Anwendungen (Kalender, Projektplaner, Kassenlösung,
diverse Schnittstellen zu Fremdprogrammen) – also wirklich eine Menge
an selbst entwickelten Zusatzanwendungen.
Das ganze nun erfolgreich und „nebenbei“ auf VB.NET umzustellen,
bereitet mir große Sorgen. Ich bin jetzt schon mit dem Support und der
Weiterentwicklung unseren Anwendern mehr als am Limit. Finanziell ist
ein weiterer Mitarbeiter jedoch definitiv nicht drin - wir haben eine
Branchenanwendung mit relativ kleiner Zielgruppe.
Eine Umstellung auf VB.NET würde daher zwangsweise den Support und die
Weiterentwicklung lahm legen, was definitiv nicht unserem Anspruch und
dem unserer Kunden gerecht wird. Ein echtes Dilemma.
Dazu kommt noch, dass ich nicht abschätzen kann, ob alle unsere hart
erarbeiteten Sonderlösungen und Workarounds in dieser Form noch unter
VB.NET realisierbar sind. Und davon gibt es gefühlt Tausende.
Wir setzten auch (leider) zahlreiche Drittkomponenten ein, so dass
auch hier vermutlich ein hoher Aufwand und diverse „Überraschungen“
entstehen können.
Vielleicht war oder ist jemand in einer ähnlichen Situation und kann
von seinen Erfahrungen oder Plänen berichten.
Irgendwie brauche ich vorab einfach etwas Feedback.
Viele Grüße...
Thorsten Doerfler
> so langsam manifestiert sich bei mir der Gedanke einer zwingenden
> Umstellung von VB6 auf VB.Net.
Worin siehst Du zwingende Gründe zur Umstellung von VB6 auf VB.NET?
> Unsere Hauptanwendung (eine Auftragsbearbeitung) ist mittlerweile ein
> wirklich sehr komplexes Programm, das unseren Anwender nahezu alles
> bietet und einen hohen Anspruch pflegt. Daneben gibt es zahlreiche
> Tools und weitere Anwendungen (Kalender, Projektplaner, Kassenlösung,
> diverse Schnittstellen zu Fremdprogrammen) – also wirklich eine Menge
> an selbst entwickelten Zusatzanwendungen.
Sind das tatsächlich eigenständige Module/Komponenten/Anwendungen?
Vielleicht nimmst Du Dir einfach mal eine kleinere Komponente vor,
stellst sie auf VB.NET um und schaffst entsprechende Schnittstellen zu
Deiner bestehenden Hauptanwendung, soweit erforderlich. Damit kannst Du
ein Gespür bekommen, wo eine Umstellung Vorteile bringen kann und wo
Probleme zu erwarten sind. Auf dem Weg dürfte auch Dir selber eine
Einschätzung leichter fallen.
> Dazu kommt noch, dass ich nicht abschätzen kann, ob alle unsere hart
> erarbeiteten Sonderlösungen und Workarounds in dieser Form noch unter
> VB.NET realisierbar sind.
Die andere Frage wäre, ob sie noch notwendig sind. Aber das wird Dir ein
Außenstehender ohne Kenntnis Deiner Anwendung schwer beantworten können.
> Wir setzten auch (leider) zahlreiche Drittkomponenten ein, so dass
> auch hier vermutlich ein hoher Aufwand und diverse „Überraschungen“
> entstehen können.
Definitiv. Aber auch hier stellt sich wieder die Frage, ob diese alle in
der Form noch notwendig wären.
Es ist sicher nicht verkehrt, wenn Du zunächst unabhängig vom
Migrationsszenario Erfahrungen mit VB.NET sammelst, sofern Du das nicht
schon gemacht hast. Denn sonst ist die Gefahr groß, dass Du mit dem
üblichen VB6 Horizont Deine Anwendung in VB.NET abbilden möchtest, was
eher hinderlich wäre und unterm Strich kaum einen Vorteil brächte.
Unabhängig von meiner Eingangsfrage oben, welche zwingenden Gründe Du
siehst.
Thorsten Dörfler
--
Microsoft MVP Visual Basic
vb-hellfire visual basic faq | vb-hellfire - einfach anders
http://vb-faq.de/ | http://www.vb-hellfire.de/
Anton Azubi
ein Dotnet wäre, genauso optimiert wie jetzt als VB6?
Was würde es denn dem Kunden bringen?
Wir konnten uns diese Frage beide Male mit 'nix' beantworten - und wozu
sollten wir für 'nix' investieren?
Man muß sehen, wohin die Reise geht: MS hat einfach kein Interesse mehr an
Miniklitschen mit ausgeklügelter Software, also werden sie ihre Compiler
auch nicht dafür weiterentwickeln, daß immer leichter immer stabilere
Software gebaut werden kann, sondern sie werden alle paar Jahre eine neu
lackierte Versionssau durchs Dorf treiben, auf daß das B2B-Geschäft mit den
Huschhusch-Hinklatsch-Experten blüht.
Wer glaubt, DotNet sei das Ende der Fahnenstange, hält auch ein Hamsterrad
für eine Leiter.
Mein Rat:
Nach und nach auf sämtliche quellcodelosen Third-Party-Controls verzichten
(mühsam, aber praktikabel) und nur noch 'simplen', modularisierten Code
schreiben, der sich auch in anderen Programmiersprachen ausdrücken läßt.
Wenn das nicht geht, 'Tricks' in zentralen Modulen zusammenfassen, dann
fällt später eine Umstellung leichter.
Do it yourself heißt die Maxime. Dann spielt die Farbe der nächsten durchs
Dorf gejagten Sau kaum eine Rolle mehr.
Just my 2c.
Peter Fleischer
ergänzend zu den beiden anderen Beiträgen solltest Du berücksichtigen, dass
bei intensiver Beschäftigung mit der Laufzeitumgebung von VB.NET mindestens
3 Monate erforderlich sind sie zu verstehen, in denen Du keine Zeit hast,
Dich mit der vorhandenen VB6-Lösung zu beschäftigen.
Wie Anton geschrieben hat, solltest Du grundsätzliche Funktionalitäten
kapseln und von allen "Tricks" und Drittanbieter-Komponenten befreien.
Solche Funktionalitäten lassen sich dann recht einfach auch nach VB.NET
konvertieren bzw. in VB.NET nutzen. Außerdem gibt es Möglichkeiten, gemischt
zu arbeiten. Beim gemischten Betrieb wäre eine parallele Nutzung der alten
Funktionalitäten mit neuen in VB.NET erstellten Funktionalitäten innerhalb
einer Anwendung möglich.
Nach meiner Erfahrung lohnt sich ein Umstieg nur, wenn die neue Lösung neue
Funktionalitäten bieten soll, die in VB6 nur mit erhöhtem Aufwand erstellbar
sind. Das sind vor allem WPF-Oberflächen und Datenbankzugriffe. Da bietet
VB.NET mit dem Framework Möglichkeiten, sehr produktiv auf hohem
Aggregationsniveau Anwendungen zu erstellen.
--
Viele Grüße
Peter
Dieter Strassner
> Das ganze nun erfolgreich und „nebenbei“ auf VB.NET umzustellen,
> bereitet mir große Sorgen. Ich bin jetzt schon mit dem Support und der
> Weiterentwicklung unseren Anwendern mehr als am Limit. Finanziell ist
> ein weiterer Mitarbeiter jedoch definitiv nicht drin - wir haben eine
> Branchenanwendung mit relativ kleiner Zielgruppe.
>
> Eine Umstellung auf VB.NET würde daher zwangsweise den Support und die
> Weiterentwicklung lahm legen, was definitiv nicht unserem Anspruch und
> dem unserer Kunden gerecht wird. Ein echtes Dilemma.
>
> Dazu kommt noch, dass ich nicht abschätzen kann, ob alle unsere hart
> erarbeiteten Sonderlösungen und Workarounds in dieser Form noch unter
> VB.NET realisierbar sind. Und davon gibt es gefühlt Tausende.
> Wir setzten auch (leider) zahlreiche Drittkomponenten ein, so dass
> auch hier vermutlich ein hoher Aufwand und diverse „Überraschungen“
> entstehen können.
>
> Vielleicht war oder ist jemand in einer ähnlichen Situation und kann
> von seinen Erfahrungen oder Plänen berichten.
>
> Irgendwie brauche ich vorab einfach etwas Feedback.
Eine Umstellung muß dem Kunden Nutzen bringen. Es kostet euch Zeit+Geld und
den Kunden Zeit+Geld.
Also erstmal die Fragen stellen und beantworten: Wo ist der Mehrnutzen
versteckt?
Wie vermarktet und verkauft Ihr die Software heute/morgen/übermorgen?
Wäre DotNet ein Verkaufsargument?
Wäre die neue Oberfläche ein Verkaufsargument?
Zusätzliche Feature?
Fahrt zweigleisig:
Baut mit der neuen Technik ein AddOn zu eurem bisherigen oder für eine ganz
neue, bzw. ähnliche Zielgruppe ein "Miniprodukt" das sich mittelfristig
trägt. Das könnte die Basis für eine komplette Umstellung sein. Oder geht in
die Cloud!
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Thorsten Albers
<822a7cc1-3b77-4414...@39g2000yqa.googlegroups.com>...
> so langsam manifestiert sich bei mir der Gedanke einer zwingenden
> Umstellung von VB6 auf VB.Net.
Bei dem von Dir beschriebenen Szenario wäre VB.NET wirklich das letzte, was
ich als Zielsprache in's Auge fassen würde. Wenn Du Dir schon die Mühe des
Umstieges machen willst, dann nimm lieber eine Sprache wie C/C++, die Dir
die Mühen dann auch gleich noch mit leichterer Portierbarkeit auf andere
Platformen lohnt. Alle COM-Komponenten von Drittherstellern kannst Du dort
zunächst einmal weiterverwenden und dann nach und nach durch eigene
ersetzen.
--
Thorsten Albers
gudea (a) gmx.de
Detlef Jäger
vielen lieben Dank an alle Antworten und die damit verbundene Zeit!
Nach euren Antworten merke ich mal wieder deutlich, dass ich als
„Quereinsteiger“ erhebliche Defizite habe, da ich mich zudem ja nur in
VB6 eingearbeitet habe.
Gleichzeitig bin ich sehr überrascht über eure Antworten, da diese in
eine etwas andere Richtung gehen, als ich erwartet habe.
Zu den Fragen:
Ich kenne das Potential von neueren Entwicklungsumgebungen nicht
wirklich.
Es besteht auch momentan kein funktionaler Anreiz für einen Umstieg
auf VB.NET.
Der einige Grund (bzw. Sorge) ist, rechtzeitig zu wechseln, um nicht
in vielleicht 5 Jahren vor einem technisch unlösbaren Problem zu
stehen, bei dem unsere Anwendungen durch ein neues Betriebssystem
nicht mehr richtig lauffähig sind.
Der Gedanke zu wechseln ist keine Anforderung unsere Kunden, sondern
lediglich der unterschwellige Druck, dass VB6-Anwendungen langfristig
nicht mehr von den Betriebssystemen einwandfrei unterstützt werden.
DotNet ist definitiv kein Verkaufsargument. Die Oberflächen unserer
Anwendung haben wird mittels Drittkomponenten „modernisiert“.
Cloud ist sicherlich eine interessante Entwicklung, jedoch momentan
kein wirkliches Thema für unsere Kunden.
Unsere „Nebenanwendungen“ probeweise umzustellen, wäre sicherlich
zeitlich machbar.
Hier sind es zum Teil auch sehr kleine Projekte, die sich sehr gut zur
Einarbeitung eignen würden. Einen funktionalen Vorteil durch VB.NET
würde sich jedoch auch hier nicht ergeben. Aber das wäre ja auch nicht
zwingend notwendig.
Die Hauptanwendung ist jedoch wirklich ein enorm großer Brocken. Und
nur diese macht mir Sorgen.
Zwar haben wir vielen wichtige Funktionen in Klassen und Modulen
gekapselt (Datenbankzugriff, Druckroutinen, etc.), aber letztendlich
ist es doch nur ein Bruchteil.
Meine Aufgabe wird es jetzt wohl sein, mich zunächst mit weiteren
Sprachen zu beschäftigen, um dann überhaupt eine Entscheidung treffen
zu können.
Parallel dazu könnte ich mich jetzt etwas entspannt mit VB.NET
beschäftigen und eines unserer Tools umstellen um Erfahrungen zu
sammeln.
Außerdem will ich mal prüfen, inwieweit wir unseren Quellcode für eine
eventuelle Portionierung optimieren können. Ich glaube hier ist der
Zeitaufwand überschaubar und am Sinnvollsten angelegt.
Gibt es denn diesbezüglich gute Literatur oder Quellen im Internet?
Die momentan verwendeten Third-Party-Controls lassen sich meiner
Ansicht nach ohne weiteres nicht ersetzen. Sicherlich würden aber
einige auch (zum Glück) wegfallen (alle GUI-betreffenden).
Viele Grüße und nochmals herzlichen Dank für euer ausführliches
Feedback.
Georg Jung
GUI macht. Ich warte ab und hoffe dass Mono irgendwann ausgereift(er)
ist und lerne mich dann nicht in .NET ein sondern speziel in Mono.
Ich fand Anton Azubis Kommentare echt gut BTW! Ich versuche auch alles
in leicht abzuändernde Methoden zu packen, ich habe sogar das Abfragen
von Werten aus Combos in eigene Funktionen ausgelagert und verwende nach
Möglichkeit keine Private Declares mehr sondern nur noch Public Declares
so dass ich Funktionen im Notfall nicht zehnfach umschreiben muss.
Notfall wäre: Microsoft kündigt an dass das neue Betriebssystem kein VB6
mehr unterstützt, aber ich denke, so 10 Jahre haben wir mindestens noch?!
Ich zögere die Umstellung auf irgendetwas anderes als VB6 so lange raus
wie es nur geht damit ich dann einen klareren Blick auf die dann
bereitstehenden Möglichkeiten habe. So habe ich glücklicherweise auch
schon etliche totgegangene Mono-ähnliche Projekte "verschlafen".
Thorsten Albers
<ie2s0o$3mj$00$1...@news.t-online.com>...
> Leichte Portierbarkeit sehe ich bei C++ nicht gegeben wenn man etwas mit
> GUI macht.
Nicht "leichte" sondern "leichtere". Wenn's Linux, Unix, Mac etc. sein
soll, ist das immer noch der beste Weg. Außerdem kannst Du für die GUI auch
unter Windows Bibliotheken verwenden, die zumindest auf Linux/Unix
ebenfalls zur Verfügung stehen.
Wolf Wiegand
nur ergänzend zu den anderen Antworten:
Am 11.12.2010 12:37, schrieb Detlef Jäger:
> Dazu kommt noch, dass ich nicht abschätzen kann, ob alle unsere hart
> erarbeiteten Sonderlösungen und Workarounds in dieser Form noch unter
> VB.NET realisierbar sind. Und davon gibt es gefühlt Tausende.
> Wir setzten auch (leider) zahlreiche Drittkomponenten ein, so dass
> auch hier vermutlich ein hoher Aufwand und diverse „Überraschungen“
> entstehen können.
Ich kenne natürlich Eure Anwendung nicht, aber ich vermute, dass die
Sonderlösungen, Workarounds und Drittkomponenten hauptsächlich die
Benutzungsoberfläche betreffen. In diesem Fall bietet sich evtl. die
Möglichkeit, bei einer Migration auf eine andere Programmiersprache alle
Oberflächen-Komponenten unverändert zu lassen, und erst einmal nur die
'Arbeitskomponenten' in eigene Projekte auszulagern, die dann mit einer
anderen Programmiersprache umgesetzt werden. Das setzt natürlich eine
recht gute Trennung von Oberfläche und Geschäftslogik voraus.
Falls das nicht gegeben ist, würde ich (ähnlich wie von Thorsten
vorgeschlagen) erst einmal bei den Tools und Zusatzanwendungen ansetzen.
Vielleicht möchten ja in naher Zukunft ein oder zwei Kunden eine neue
Funktionalität haben, die sich gut über eine neue Zusatzanwendung
realisieren ließen. Das wäre ein guter Zeitpunkt, diese Anwendung in
einer neuen Sprache zu implementieren. Je nachdem, wie eng ihr mit den
Kunden zusammenarbeitet, ist evtl. auch ein Angebot "Wir probieren jetzt
mal neue Technologie aus, könnte am Anfang nicht so gut wie gewohnt
funktionieren, dafür ist es günstiger/umsonst" denkbar.
Bzgl. Deiner Sorgen um die Zukunftsfähigkeit der VB6-Software: Ich wäre
da vorsichtig optimistisch. Der Tod dieser Software wurde schon 2002
vorausgesagt, und trotzdem sind die Probleme unter Windows7 und W2k8
überschaubar, so weit ich das als nicht-VB6-Entwickler beurteilen kann.
Und Microsoft hängt üblicherweise die Abwärtskompatibilität sehr hoch;
Ich habe gerade mal zum Spaß probiert, das CorelDraw3-Setup (1993!)
unter Windows7 zu starten. Bis zum "CorelDRAW! kann installiert werden"
lief alles ohne Probleme, dann hat mich der Mut verlassen :-)
hth und viel Erfolg -
Wolf
Wolf Wiegand
Am 13.12.2010 22:42, schrieb Wolf Wiegand:
> [...]
einen Punkt habe ich gerade noch vergessen. Um besser beurteilen zu
können, wo sich eine (Weiter-)Entwicklung mit .NET lohnt, ist es
natürlich hilfreich, sich etwas mit dem .NET-Framework
auseinanderzusetzen und zu lernen, was es besser kann, auch wenn man es
erst einmal nicht für Kundenprojekte einsetzt. Steuerelemente, die sich
automatisch an die Formulargröße anpassen: Für die meisten Zwecke unter
.NET ein Kinderspiel. Endloses Left$/Right$/Mid$-Gehampel, um
Zeichenketten auseinanderzunehmen: Reguläre Ausdrücke sind nach einer
kurzen Eingewöhnungsphase eleganter und weniger fehleranfällig.
Werttypen (Integer, Boolean), die auch den Zustand 'nicht belegt'
annehmen können (Nullable(Of Werttyp)): Ich könnte nicht mehr ohne
auskommen. Ansprechen von Webservices: So gut wie eingebaut. Und sicher
noch einiges mehr, was Dir wichtig sein könnte.
Wolf
--
"Menschen. Es geht nicht mit ihnen, es geht nicht ohne sie", seufzte der
Computer. (Stefan Froehlich in d.a.s.r.)
Oliver Dietz
> Bzgl. Deiner Sorgen um die Zukunftsfähigkeit der VB6-Software: Ich wäre da
> vorsichtig optimistisch. Der Tod dieser Software wurde schon 2002
> vorausgesagt, und trotzdem sind die Probleme unter Windows7 und W2k8
> überschaubar, so weit ich das als nicht-VB6-Entwickler beurteilen kann.
Die Runtime wird ja auch auf Windows 7 supported:
http://msdn.microsoft.com/en-us/vbasic/ms788708
---
As detailed in this document, the core Visual Basic 6.0 runtime will be
supported for the full lifetime of Windows Vista, Windows Server 2008 and
Windows 7, which is five years of mainstream support followed by five years
of extended support
---
Alles was danach kommt ist ungewiss - wer dann noch nicht soweit ist, wird
vielleicht gezwungen auf virtuelle XP/Windows 7 - Rechner auszuweichen. So
wie es aktuell mit 16-Bit - Programmen auf Windows 7 64-Bit ist. Gut, ist
nicht direkt vergleichbar, weil da die Prozessorarchitektur mitspielt ...
... aber mit VB6 muss man sich jedes Jahr mit größeren Einschränkungen
abfinden. Egal ob es XP-Themes sind oder andere neuere Schnittstellen zum
Betriebssystem (Aero, die neuen Taskleisten-Optionen, Directory-Listener,
Webservices usw.). Der GUI-Designer machte schon mit XP-Themes Zicken, mit
Aero unter Win 7 gibt es noch mehr Probleme. Unter aktuellen
Programmierumgebungen bekommt man die SDKs frei Haus mit Beispielcode ...
unter VB6 ist viel Handarbeit angesagt. Komponentenhersteller haben den
VB6-Support auch mehr oder weniger aufgekündigt - ein Ribbon-Menü für VB6 zu
finden, das auch stabil läuft, wird schon schwerer. Neue Mitarbeiter finden,
die sich in VB6 einarbeiten wollen oder schon 1a auskennen ist auch nicht
möglich ... in der Summe fordert eine VB6-Anwendung immer höhere
Investitionen um am Ball zu bleiben.
... deshalb hält sich mein Optimismus in Grenzen und die Migration auf
neuere Entwicklungsplattformen muss vollzogen werden. Panik ist noch nicht
angesagt, aber VB6 ist eine Einbahnstraße, die nicht mehr ausgebaut wird.
Man kann sich nur noch aussuchen wann man abbiegt und wohin, um dann auch
wieder schneller vorwärts zu kommen ...
Es würde mich aber trotzdem freuen wenn VB6 noch lange Supported wird.
Viele Grüße,
Oliver
Frank Müller
> Endloses
> Left$/Right$/Mid$-Gehampel, um Zeichenketten auseinanderzunehmen:
> Reguläre Ausdrücke sind nach einer kurzen Eingewöhnungsphase
> eleganter und weniger fehleranfällig. Werttypen (Integer, Boolean),
> die auch den Zustand 'nicht belegt' annehmen können (Nullable(Of
> Werttyp)): Ich könnte nicht mehr ohne auskommen.
Das ist doch kein Argument, Reguläre Ausdrücke gibt es schon lange,
nicht nur in VB6 sondern generell. Man kann sie schon seit Ewigkeiten
in sowohl in VB6 als auch sonstigen Sprachen verwenden. Das ist
gar kein Argument für micht um auf .NET umsteigen zu wollen.
Natürlich musste man sich auch "damals" schon da einarbeiten,
die Regular Expressions waren immer schon mächtiger als
reine String Manipulationen, wer es gemacht hat weiß die
Vorteile zu schätzen, wer nicht, der halt nicht.
Scheint mir so, dass du dich erst seit deinem Umstieg
damit beschäftigt hast.
Gruß,
Frank
Frank Müller
> Die Runtime wird ja auch auf Windows 7 supported:
> http://msdn.microsoft.com/en-us/vbasic/ms788708
> Alles was danach kommt ist ungewiss - wer dann noch nicht soweit ist,
> wird vielleicht gezwungen auf virtuelle XP/Windows 7 - Rechner
> auszuweichen. So wie es aktuell mit 16-Bit - Programmen auf Windows 7
> 64-Bit ist. Gut, ist nicht direkt vergleichbar, weil da die
> Prozessorarchitektur mitspielt ...
Na ja, das ist schon vergleichbar, denn heute ist es ja auch schon so,
dass viele Leute für diverse Programme (Nicht nur VB6 Programme)
auf den XP-Modus umschalten der unter Win7 im Gegensatz
zu Vista verfügbar ist. Oder gar komplett damit arbeiten, auch
im gewerblichen Bereich.
> ... aber mit VB6 muss man sich jedes Jahr mit größeren Einschränkungen
> abfinden. Egal ob es XP-Themes sind oder andere neuere Schnittstellen
> zum Betriebssystem (Aero, die neuen Taskleisten-Optionen,
> Directory-Listener, Webservices usw.). Der GUI-Designer machte schon
> mit XP-Themes Zicken, mit Aero unter Win 7 gibt es noch mehr
> Probleme.
Das mag je nach Programm oder Branche stimmen, ist aber kein
generelles Argument für eine große Anwendung. Denn grade
der "Klicki-Bunti-Faktor" ist bei gewerblichen Kunden eher
nicht gegeben, ich habe keinen Kunden der Aero usw. eingeschaltet
hat. Und schon gar nicht bei Kunden die eine VB6 Software
viele Jahre nutzen wo es solche Sachen noch gar nicht gab.
> Unter aktuellen Programmierumgebungen bekommt man die SDKs
> frei Haus mit Beispielcode ... unter VB6 ist viel Handarbeit
> angesagt.
SDKs gab es immer schon, sind auch in der MSDN integriert
schon seit was ich wann.
> Komponentenhersteller haben den VB6-Support auch mehr oder
> weniger aufgekündigt
Viele Hersteller von Komponenten haben aber auch
.NET Versionen im Programm. Die Komponenten die früher
notwendig waren und jetzt ohne Komponente machbar sind
wurden / werden logischerweise nicht weiter entwickelt
vom Hersteller der Komponente.
> - ein Ribbon-Menü für VB6 zu finden, das auch
> stabil läuft, wird schon schwerer.
Wer will so etwas? Selbst wenn es eines gäbe,
ich würde es nicht in meine VB6 Programme einbauen
und auch nicht in neue Programme die ich mit .NET
schreibe integrieren. Die Anwender würden mich
"killen" wenn ich denen anstatt der jahrelang
gewohnten GUI jetzt Ribbons vorsetzten würde.
> Neue Mitarbeiter finden, die sich
> in VB6 einarbeiten wollen oder schon 1a auskennen ist auch nicht
> möglich ... in der Summe fordert eine VB6-Anwendung immer höhere
> Investitionen um am Ball zu bleiben.
Es gibt genug qualifizierte Leute die sich in VB6 auskennen, da
sehe ich eher kein Problem.
> ... deshalb hält sich mein Optimismus in Grenzen und die Migration auf
> neuere Entwicklungsplattformen muss vollzogen werden.
Richtig, und das ist auch meistens kein Problem wenn man
sauber Programmiert hat in der Vergangenheit.
>Panik ist noch
> nicht angesagt, aber VB6 ist eine Einbahnstraße, die nicht mehr
> ausgebaut wird. Man kann sich nur noch aussuchen wann man abbiegt und
> wohin, um dann auch wieder schneller vorwärts zu kommen ...
Ja, aber aus Panik jetzt mal schnell abzubiegen ist nicht der richtige
Weg. Wohin die Reise geht ist klar, die Einbahnstrasse ist lang, da
gibt es viele Kreuzugen an denen man in "verschiedene Richtungen"
abbiegen kann. Wohin man dann fährt wird sich für jeden
Autofahrer oder Programmierer zeigen. Das muss nicht unbedingt
.NET sein.
> Es würde mich aber trotzdem freuen wenn VB6 noch lange Supported wird.
Wird es ja nicht mehr, aber VB6 Programme laufen ja noch ziemlich lange.
Und never change an running system kann man so oder so auslegen.
Gruß,
Frank
P.S, ich weiß schon welche Links jetzt dazu kommen
W. Wolf
>
> Na ja, das ist schon vergleichbar, denn heute ist es ja auch schon so,
> dass viele Leute für diverse Programme (Nicht nur VB6 Programme)
> auf den XP-Modus umschalten der unter Win7 im Gegensatz
> zu Vista verfügbar ist. Oder gar komplett damit arbeiten, auch
> im gewerblichen Bereich.
>
Da gäbe es dann noch die App-Virtualisierung.
Habe gehört dass bei VM-Ware so was wie eine
Personal-Edition in Vorbereitung ist. Mittelfristig
werden aber sicher auch die Preise für die große
Schwester fallen. Das ist eine sehr elegante
Möglichkeit ältere Programme und "neue Alte" wohlbehalten
zu erhalten. Microsoft hat diesbezüglich mit App-V
auch ein Produkt am Start. Wäre gelacht, wenn gerade
Microsoft Produkte, zu denen ich im entferntesten
Sinne auch unsere Anwendungen zähle, unter dieser
Virtualisierung nicht laufen würden. Andere Hersteller
(Xenocode, Symantec) folgen und beflügeln und die Konkurrenz.
Der Aufwand der Virtualisierung ist für uns
Entwickler überschaubar, einmal konfiguriert reicht
ein Paketierungs-Vorgang, vergleichbar mit einer
Kompilierung. Es entsteht eine Exe, welche alle
Abhängigkeiten enthält. Der Kunde muß nichts mehr
tun, gar nichts mehr. Selbst ein Start von Stick
ist möglich. Das ist echtes Copy&Run.
Was damit nicht geht ist das Bunte. Aber auch hier
sehe ich VB nicht als Sackgasse. Das was uns Olaf
gezeigt hat, sieht verdammt gut aus. Die von dir
erwähnten Kreuzungen könnten sogar Zollübergänge
zu anderen Betriebssystemen sein. Ich nenne es bewusst
Zollübergänge, weil wir sicher nicht alles mitnehmen
können (dürfen). Wir werden Zoll bezahlen müssen (z.B.
statt der Access-DB eine Lite-SQL nutzen).
Schönen Gruß
W. Wolf
Thorsten Albers
<8mni9r...@mid.individual.net>...
> Und Microsoft hängt üblicherweise die Abwärtskompatibilität sehr hoch;
> Ich habe gerade mal zum Spaß probiert, das CorelDraw3-Setup (1993!)
> unter Windows7 zu starten. Bis zum "CorelDRAW! kann installiert werden"
> lief alles ohne Probleme, dann hat mich der Mut verlassen :-)
Das ist nun aber nicht gerade vergleichbar: Es handelt sich dabei um eine
16 Bit-Version, die entsprechend auch in der 16 Bit-Umgebung von Windows
läuft. Daß sich an der von Windows-Version zu Windows-Version nichts mehr
oder nicht mehr viel ändert, ist ja logisch - es gibt sie entweder immer in
der - mehr oder weniger - gleichen Form oder überhaupt nicht mehr.
Bei 32 Bit-Anwendungen sieht das etwas anders aus.
Thorsten Albers
> Steuerelemente, die sich
> automatisch an die Formulargröße anpassen: Für die meisten Zwecke unter
> .NET ein Kinderspiel.
Und wo besteht da ein Unterschied zu VB? Auch dort ist das ein
'Kinderspiel'
> Endloses Left$/Right$/Mid$-Gehampel, um
> Zeichenketten auseinanderzunehmen:
Wie bitte? Diesen Anweisungen mußt Du lediglich den Namen des Strings,
ggfs. die Posisition, ab der gearbeitet werden soll, und die Länge des
abzuarbeitenden Stringteils übergeben - wie in jeder anderen
Programmiersprache auch; was ist da ein Gehampel?
> Reguläre Ausdrücke sind nach einer
> kurzen Eingewöhnungsphase eleganter
Das ist eine sehr pesönliche Einschätzung...
> und weniger fehleranfällig.
...und das auch.
> Werttypen (Integer, Boolean), die auch den Zustand 'nicht belegt'
> annehmen können (Nullable(Of Werttyp)): Ich könnte nicht mehr ohne
> auskommen.
Das spricht nicht für die Programmiersprache sondern gegen Dich.
> Ansprechen von Webservices: So gut wie eingebaut. Und sicher
> noch einiges mehr, was Dir wichtig sein könnte.
Tja, wer's braucht. Für jemanden, der seine Programme bisher in VB
programmieren konnte, ist das sicherlich kein Umstiegsgrund.
Lars P. Wolschner
> Wolf Wiegand <wo...@kondancemilch.de> schrieb im Beitrag
> <8mnjpl...@mid.individual.net>...
>> Endloses Left$/Right$/Mid$-Gehampel, um Zeichenketten
>> auseinanderzunehmen:
>
> Wie bitte? Diesen Anweisungen mußt Du lediglich den Namen des
> Strings, ggfs. die Posisition, ab der gearbeitet werden soll,
> und die Länge des abzuarbeitenden Stringteils übergeben - wie in
> jeder anderen Programmiersprache auch; was ist da ein Gehampel?
Der Satz, auf den Du entgegnest, ist ein wenig pauschal. Solange
man den String in konstant längen- bzw. positionsmäßig festzu-
machende Teile zerlegt, sind Left(), Mid() und Right() passend und
es ist nicht zu erkennen, wie .NET das besser machen will. Häufig
werden die Positions- und Längengrößen aber erst durch Suchvorgänge
beispielsweise mit InStr() gewonnen. Das könnte man dann schon mal
als Gehampel bezeichnen und kann durch reguläre Ausdrücke eleganter
bewerkstelligt werden.
Allerdings dürften reguläre Ausdrücke langsamer abzuarbeiten sein
als Left(), Mid() oder Right() im Zusammenhang mit InStr().
>> Reguläre Ausdrücke sind nach einer
>> kurzen Eingewöhnungsphase eleganter
>
> Das ist eine sehr pesönliche Einschätzung...
>
>> und weniger fehleranfällig.
>
> ...und das auch.
In der Tat; Lesbarkeitspreise gewinnen reguläre Ausdrücke
sicherlich nicht.
>> Werttypen (Integer, Boolean), die auch den Zustand 'nicht
>> belegt' annehmen können (Nullable(Of Werttyp)): Ich könnte
>> nicht mehr ohne auskommen.
>
> Das spricht nicht für die Programmiersprache sondern gegen Dich.
Das kommt auf den Anwendungsfall an.
--
Mit freundlichen Grüßen
Lars P. Wolschner
Thorsten Albers
<4d077947$0$6773$9b4e...@newsspool3.arcor-online.net>...
> Das könnte man dann schon mal
> als Gehampel bezeichnen und kann durch reguläre Ausdrücke eleganter
> bewerkstelligt werden.
Mir ist schon klar, was Wolf meinte.
Ihm dagegen scheint nicht klar zu sein, daß er da Äpfel mit Birnen
vergleicht: Für seine regulären Ausdrücke verwendet er - offensichtlich
unbewußt - eine zusätzliche Bibliothek, die halt nur in VB.NET bzw. im
.NET-Framework bereits integriert ist. In VB läßt sich genauso eine externe
Bibliothek referenzieren, mit deren Hilfe das möglich ist. Mit Left$() etc.
hat das also überhaupt nichts zu tun. Außerdem kann man natürlich auch mit
den VB-Statements ohne Probleme derartiges realisieren, in eine
Klassenbibliothek o.dgl. packen - nichts anders ist ja bei der Bibliothek,
die er unter VB.NET verwendet, gemacht worden.
> Allerdings dürften reguläre Ausdrücke langsamer abzuarbeiten sein
> als Left(), Mid() oder Right() im Zusammenhang mit InStr().
ACK. Und sehr häufig für den Zweck auch völlig überdimensioniert sein.
> >> Werttypen (Integer, Boolean), die auch den Zustand 'nicht
> >> belegt' annehmen können (Nullable(Of Werttyp)): Ich könnte
> >> nicht mehr ohne auskommen.
> > Das spricht nicht für die Programmiersprache sondern gegen Dich.
> Das kommt auf den Anwendungsfall an.
Nö. Ob nun von der 'Sprache' selbst festgelegt wird, welcher 'Wert' einer
Variablen für 'nicht belegt' steht oder vom Programmierer, das ist völlig
egal. Wenn er also nicht mehr mit VB programmieren könnte, weil VB ihm
diese ungeheure Arbeit nicht automatisch abnimmt, dann ist das sein Problem
und nicht ein Problem von VB.
.NET-Programmierer setzen Bequemlichkeit immer gerne gleich mit 'tolle
Features', 'wahsinnig modern' und 'anderen Sprachen überlegen', und
ignorieren gerne, daß sie sich damit in eine m.E. ungute Abhängigkeit von
der von ihnen verwendeten Programmiersprache bzw. -platform begeben.
Lars P. Wolschner
> Lars P. Wolschner <lars.wo...@nexgo.de> schrieb im Beitrag
> <4d077947$0$6773$9b4e...@newsspool3.arcor-online.net>...
>> Das kommt auf den Anwendungsfall an.
>
> Nö. Ob nun von der 'Sprache' selbst festgelegt wird, welcher
> 'Wert' einer Variablen für 'nicht belegt' steht oder vom
> Programmierer, das ist völlig egal.
hmm. Nehmen wir mal an, es geht um eine eine ganze Zahl. Nicht immer
kann man einen ganzzahligen Wert sinnvoll herausgreifen und mit einer
Sonderrolle belegen, vor allem dann nicht, wenn man wegen einer
fremden oder vom Hersteller gelieferten Bibliothek gar nicht alleine
über den zulässigen Wertebereich bestimmt. An sich könnte man dann
als Variant deklarieren und hätte so neben den Long-Werten auch noch
die Möglichkeit, Empty zuzuweisen. Empty wäre auch der Zustand eines
Variant unmittelbar nach Deklaration. Effizient wäre das nicht, vor
allem nicht in hochiterierenden Schleifen, in denen ein Variant
langsamer bearbeitet würde als eine Long-Variable.
Eine For-Schleife, die einen Long von 1 bis 100.000 hochzählt,
braucht auf meinem Centrino-Notebook 0,0014 sec, für einen Variant an
gleicher Stelle wird dagegen 0,0025 sec benötigt. Jedenfalls mit VB
for MS Access.
Obendrein könnte dem Variant auch jeder andere Datentyp zugewiesen
werden, ohne daß der Debugger den Fehler schon bei der Zuweisung
bemerken würde.
Tatsächlich könnte man auch an einem Punkt angelangt sein, an dem man
ganzzahlige Werte wieder in Long-Variablen verstaut und lieber eine
Klasse formuliert, die den Undefiniert-Zustand zuverlässig
anderweitig feststellt, ohne die eigentlichen Long-Berechnungen zu
verlangsamen.
> Wenn er also nicht mehr mit VB programmieren könnte, weil VB ihm
> diese ungeheure Arbeit nicht automatisch abnimmt, dann ist das
> sein Problem und nicht ein Problem von VB. .NET-Programmierer
> setzen Bequemlichkeit immer gerne gleich mit 'tolle Features',
> 'wahsinnig modern' und 'anderen Sprachen überlegen', und
> ignorieren gerne, daß sie sich damit in eine m.E. ungute
> Abhängigkeit von der von ihnen verwendeten Programmiersprache
> bzw. -platform begeben.
Vor allem muß auch .NET die Möglichkeit eines zusätzlichen
Undefinidert-Wertes berücksichtigen und das verlangsamt unweigerlich
auch unter .NET die Abarbeitung aller Variablen mit einer derartigen
Eigenschaft. Wenn ich dieses Feature dann obendrein noch immer dabei
habe, selbst in den Fällen, in denen ich es gar nicht brauche und ein
solcher Wert daher auch gar nicht zur zulässigen Wertemenge zählt -
prost Mahlzeit.
Peter Götz
>> Steuerelemente, die sich automatisch an die
>> Formulargröße anpassen: Für die meisten Zwecke unter
>> .NET ein Kinderspiel.
>
> Und wo besteht da ein Unterschied zu VB? Auch dort ist
> das ein 'Kinderspiel'
Na ja, ich denke zwischen einer einmaligen
Control-Eigenschaftseinstellung in .net wie
Control.Dock = Fill ' (Left, Top, Right, Bottom)
oder
Control.Anchor = Left ' (Or Top or Right or Bottom)
und einem bei jedem (VB6-) Form_Resize für
alle Controls auszuführenden
Control.Move L, T, W, H
und/oder ständigen Zuweisungen von
Control.Left, Control.Top
Control.Width, Control.Height
ist schon ein spürbarer Unterschied.
Bei allen meinen Anwendungen wird die Grösse von Controls
und entsprechend deren Anordnung und Abstand zueinander
programmatisch an die jeweiligen vom Benutzer gewählten
Schriftgrössen sowie an die jeweils vom Benutzer eingestellte
Formgrösse angepasst und das gestaltet sich mit VB.net
schon erheblich einfacher und damit auch deutlich übersichtlicher
als dies noch bei meinen VB6-Anwendungen zu lösen war.
Im Beispiel unter
www.gssg.de -> Visual Basic -> VBclassic
-> Datenbank
-> ADO DemoMu 2002
gibt es in frmMain.frm die Sub Ausrichten(), die dafür sorgt,
dass alle Controls auf dieser Form bei Formgrössenänderungen
oder Änderung der Schriftgrössen entsprechend angepasst
werden. Selbst bei dieser relativ einfachen Benutzeroberfläche
ist das ein doch schon recht beträchtlicher Programmieraufwand.
Mit .net - Mitteln gestaltet sich sowas schon spürbar einfacher.
>> Endloses Left$/Right$/Mid$-Gehampel, um
>> Zeichenketten auseinanderzunehmen:
>
> Wie bitte? Diesen Anweisungen mußt Du lediglich den Namen
> des Strings, ggfs. die Posisition, ab der gearbeitet werden soll,
> und die Länge des abzuarbeitenden Stringteils übergeben -
> wie in jeder anderen Programmiersprache auch; was ist da
> ein Gehampel?
Ich würde nicht von "Gehampel" reden, meine aber schon,
dass die umfangreichen Eigenschaften und Methoden des
.net - String-Objektes und des StringBuilders vieles vereinfachen.
... schnipp ...
>> Werttypen (Integer, Boolean), die auch den Zustand 'nicht belegt'
>> annehmen können (Nullable(Of Werttyp)): Ich könnte nicht mehr ohne
>> auskommen.
>
> Das spricht nicht für die Programmiersprache sondern gegen Dich.
Hier würde mich das "konkrete Warum" schon interessieren?
Ich bin auch der Meinung, dass man sich schon sehr genau
überlegen sollte, ob es lohnt eine bestehende und stabil laufende
VB6-Anwendung nach .net umzustellen, solange die Anwendung
die Anforderungen des Anwenders erfüllt und evtl. noch erforderliche
Anpassungen/Erweiterungen mit VB6-Mitteln zufriedenstellend
machbar sind. Aber ich würde nicht behaupten wollen, dass VB.net
gegenüber VBclassic keine oder nur geringe Vorteile brächte.
Schau Dir mal
www.gssg.de -> Visual Basic -> VB.net
-> Multimedia / Midi
-> MidiOrchestra
an. Da würde mich interessieren, wie Du den Aufwand für ein
Programm mit gleicher Funktionalität und Benutzeroberfläche
in VBclassic einschätzen würdest, bzw. wie weit Du es überhaupt
mit VBclassic für realisierbar hältst.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Ahmed Martens
auch ich bin ein komplett Autodidakt und habe mir alles selbst
beigebracht. Auch ich möchte langsam von VB6 auf VBNet wechseln. Dabei
lasse ich aber meine bestehenden Programme unangetastet, da diese in
unserem Büro einwandfrei arbeiten. Ledigliche neue Tools werden jetzt in
VBNet entwickelt.
Zu VBNet kann ich nur soviel sagen, es ist unglaublich was alles möglich
ist. Für eine VB6ler kommt es wie ein Märchen vor. Ich habe z. B. vor
kurzem eine kleines Desktop-Notizprogramm mit Datenbankanbindung
erstellt. Dabei werden Formulare halbtansparent, MouseEnter- und
MouseLeave-Aktion sind so simpel, dass es schon peinlich ist. So etwas
in VB6 sind dageben unweit schwerer. Gleiches gilt für das Andocken und
automatische resizen von Steuerlementen. In VB6 ist allein dafür schon
ein kleines Programm nötig. In VBNet sind das lediglich ein paar
Mausklicks.
Aber wo Licht ist, ist auch Schatten. Ich tue mich z. B. extrem schwer
mit den Datenbankzugriffen. Ich kann mich ehrlich gesagt nicht von
meinen DAO-Zugriffen (Recordsets) lösen. Hier muss ich noch eine Menge
lernen.
Aber ich glaube der Umstieg wird schon lohnen. Aber nur für meine neuen
Tools.
Gruß Ahmed
--
Antworten bitte nur in der Newsgroup
Peter Götz
> Ich kenne das Potential von neueren Entwicklungsumgebungen
> nicht wirklich.
Zwischen VBclassic und VB.net gibt es nicht nur einen beachtlichen
Unterschied in der Entwicklungsumgebung, sondern auch einen
deutlichen Unterschied in den gebotenen Funktionaliäten welche
das .net-Framework gegenüber VBclassic bietet.
> Es besteht auch momentan kein funktionaler Anreiz für einen
> Umstieg auf VB.NET. Der einige Grund (bzw. Sorge) ist,
> rechtzeitig zu wechseln,
Na ja, den Begriff "rechtzeitig" würde ich in diesem Zusammenhang
nicht mehr wählen. Das wäre vor 10 oder sogar noch mehr Jahren
angebracht gewesen.
> um nicht in vielleicht 5 Jahren vor einem technisch unlösbaren
> Problem zu stehen, bei dem unsere Anwendungen durch ein
> neues Betriebssystem nicht mehr richtig lauffähig sind.
Wie Du ja schon den anderen Antworten entnehmen konntest,
gibt es bis einschl. Windows7 und Server2008 keine wirklich
unüberwindlichen Probleme für VB6-Anwendungen. Was
danach kommt ist allerdings reine Spekulation.
> Der Gedanke zu wechseln ist keine Anforderung unsere
> Kunden, sondern lediglich der unterschwellige Druck,
> dass > VB6-Anwendungen langfristig nicht mehr von den
> Betriebssystemen einwandfrei unterstützt werden.
Die Unterstützung von VB6 wird wie schon bisher mit jeder
neuen Systemversion Einschränkungen erfahren. Der
Aufwand diese zu umgehen könnte irgendwann unangemessen
hoch werden. Ob und wann dies ist, bleibt aber eben reine
Spekulation.
> DotNet ist definitiv kein Verkaufsargument.
Sofern der Anwender nicht auch Sourcecode mitgeliefert
bekommt, trifft dies weitgehend zu.
> Die Oberflächen unserer Anwendung haben wird mittels
> Drittkomponenten „modernisiert“.
Damit habe ich mir vor vielen Jahren mit den damaligen
VB-Tools gehörig die Finger verbrannt, nachdem der
Anbieter dieser Controlsammlung von der Bildfläche
verschwunden war. Es hat mich eine Menge Zeit und
Geld gekostet, die entspr. Anwendungen von diesen
Controls zu "reinigen" um sie weiterhin zufriedenstellend
pflegen zu können. Für mich waren ab diesem Zeitpunkt
Controls und sonstige Komponenten von Drittanbietern
tabu.
... schnipp ...
> Unsere „Nebenanwendungen“ probeweise umzustellen, wäre
> sicherlich zeitlich machbar.
> Hier sind es zum Teil auch sehr kleine Projekte, die sich sehr
> gut zur Einarbeitung eignen würden. Einen funktionalen Vorteil
> durch VB.NET würde sich jedoch auch hier nicht ergeben.
Das lässt sich erst wirklich beurteilen, wenn man das .net-
Framework gründlich kennengelernt hat. Es gibt da schon einiges,
was man in VBclassic gar nicht oder nur mit unvertretbarem
Aufwand lösen konnte und deshalb dem Anwender eben erst
gar nicht angeboten hat.
> Aber das wäre ja auch nicht zwingend notwendig.
Notwendig sind sicher stabiles Laufzeitverhalten und
Erfüllung der Anforderungen des Anwenders. Wenn
darüberhinaus auch noch ein "Mehr" an Komfort geboten
wird, ist das sicher kein Nachteil.
> Die Hauptanwendung ist jedoch wirklich ein enorm großer
> Brocken. Und nur diese macht mir Sorgen.
> Zwar haben wir vielen wichtige Funktionen in Klassen und
> Modulen gekapselt (Datenbankzugriff, Druckroutinen, etc.),
> aber letztendlich ist es doch nur ein Bruchteil.
Der zu diesem Bruchteil verbleibende Rest könnte eine
Umsetzung nach .net sehr wohl erschweren.
> Meine Aufgabe wird es jetzt wohl sein, mich zunächst mit
> weiteren Sprachen zu beschäftigen, um dann überhaupt
> eine Entscheidung treffen zu können.
> Parallel dazu könnte ich mich jetzt etwas entspannt mit
> VB.NETbeschäftigen und eines unserer Tools umstellen
> um Erfahrungen zu sammeln.
Eine einfachere, überschaubare Anwendung ist sicher ein
geeignetes Übungsobjekt
> Außerdem will ich mal prüfen, inwieweit wir unseren Quellcode
> für eine eventuelle Portionierung optimieren können. Ich glaube
> hier ist der Zeitaufwand überschaubar und am Sinnvollsten
> angelegt.
Mit dem Ausdruck "Portieren" sollte man vorsichtig sein.
Man gerade beim ersten Umstieg von VBclassic nach .net
sehr leicht versucht, Code weitgehend 1 zu 1 umzusetzen,
was sehr leicht dazu führt, dass man bessere Lösungen,
die erst das .net-Framework ermöglicht, erst gar nicht
in Betracht zieht.
> Gibt es denn diesbezüglich gute Literatur oder Quellen
> im Internet?
Wie Du ja schon an dieser Diskussion siehst, gibt es dazu
sehr vielfältige und unterschiedliche Meinungen. Letztlich
aber führt kein Weg daran vorbei, sich gründlich in das
.net-Framework einzuarbeiten, wenn man damit produktiv
einsetzbare Anwendungen erstellen will. In wenigen Tagen
oder Wochen ist das bei den vielen tausend Objekten, welche
das .net-Framework bietet nicht möglich.
> Die momentan verwendeten Third-Party-Controls lassen sich
> meiner Ansicht nach ohne weiteres nicht ersetzen.
Ich bin in den vergangenen 15 Jahren sehr gut ohne
solche augekommen, nachdem ich wie oben schon erwähnt
kräftig "Lehrgeld" gezahlt hatte.
Seit ich das .net-Framework nutze, gibt es für mich eine
Notwendigkeit für Controls von Drittanbietern noch viel
weniger.
Bei solchen Controls besteht nicht nur die Gefahr, dass sie
eines Tages nicht mehr verfügbar sind bzw. weitergepflegt
werden.
Ich hatte nicht selten auch Ärger, wenn Fehler in solchen
Controls erst nach langem Hin- und Her mit dem Hersteller
oder gar nicht behoben wurden. Fehler in eigenem Code
kann man schnell lokalisieren und entsprechend auch
schnell beheben.
Peter Götz
> Aber wo Licht ist, ist auch Schatten. Ich tue mich z. B. extrem
> schwer mit den Datenbankzugriffen.
Ursache hierfür ist aber, dass Du noch zu sehr an die von
VBclassic her gewohnten engen Bindung zwischen Anwendung
und Datenbankhintergrund gewohnt bist.
> Ich kann mich ehrlich gesagt nicht von meinen DAO-Zugriffen
> (Recordsets) lösen.
Auch bei VB6 gehörte DAO schon zum "alten Eisen". ADO
mit seinen ersten Ansätzen von verbindungslosem Arbeiten
ist da schon sehr viel näher an der Arbeitsweise in .net.
> Hier muss ich noch eine Menge
> lernen.
Du musst einfach nur mal verinnerlichen, dass es zwischen
der eigentlichen Anwendung und irgendeiner Datenquelle,
egal ob Datenbank oder sonstige Datenquelle eine klare
Trennungslinie gibt. Für eine gut konzipierte .net-Anwendung
ist es völlig egal woher die zu verarbeitenden Daten kommen
und wo sie wieder gespeichert werden. Weder der Typ des
Datenspeichers noch die Art der Datenbank müssen hier
eine Rolle spielen. Sind die Daten erst mal in lokalen
DataTables resp. in einem lokalen Dataset, ist die Art
der verwendeten Datenbank weitgehend unbedeutend.
> Aber ich glaube der Umstieg wird schon lohnen. Aber
> nur für meine neuen Tools.
Ja, genau so.
Detlef Jäger
wenn es ausschließlich um eine bessere Programmierbarkeit, dem Wegfall
von nicht mehr notwenigen Drittkomponenten und potentiell mehr
Möglichkeiten unter einer neueren Programmiersprache ginge, so würde
ich recht entspannt sein.
Das alles sind zwar durchaus positive Argumente, die einen Wechsel
potentiell interessant machen, jedoch rechtfertigen sie den
Portionierungsaufwand einer sehr großen Anwendung in unserer Situation
nicht.
Der Umstieg auf eine andere Programmierumgebung würde uns sicherlich
für 2 Jahre weitestgehend in einen unproduktiven Zustand versetzen.
Die Produktivität ist jedoch einer unserer großen Vorteile, die unsere
Kunden sehr schätzen und uns von Mitbewerbern unterscheidet.
In diesem Zusammenhang nehme ich auch gerne in Kauf, dass ich für die
Weiterentwicklung unserer Anwendungen unter VB6 mehr Zeit benötige,
jedoch zeitgleich die aktuelle Leistungsfähigkeit unserer Firma
aufrecht erhalten kann.
Ich bin auch nicht zu bequem mich in eine neue Sprache einzulernen,
sondern es geht eben wirklich darum, den momentanen Status quo
hinsichtlich des Kundenservices beibehalten zu können.
Insofern ist eine zwangsweise Umstellung bei mir erst einmal mit
berechtigten Sorgen verbunden. Wir müssen in unserer Situation
vorausblickend (2 Jahre) planen. Wenn beispielsweise in 3 Jahren ein
neues Betriebssystem von Windows veröffentlicht wird, das VB6
Anwendungen nicht mehr unterstützt, dann müssten wir jetzt so langsam
einmal handeln. Ich gehe aber davon aus, dass VB6-Anwendungen auch
unter dem nächsten Betriebssystem von Windows problemlos lauffähig
sind (mit Windows 7 hatten wir übrigens keinerlei Probleme). Aber wer
weiß dass schon.
Ich denke es lohnt sich, dass wir jetzt unsere Erfahrungen mit VB.NET
sammeln und vielleicht unsere bestehenden Anwendungen unter VB6
versuchen zu optimieren.
In einem Jahr kann ich dann vielleicht abschätzen, inwieweit sich
unsere Anwendungen problemlos umstellen lassen und welcher Aufwand
damit verbunden ist.
Detlef Jäger
deine Ausführungen decken sich mit meiner bisherigen Einschätzung.
Um langfristig Produktiv sein zu können, ist ein Umstieg sicherlich
unumgänglich. Ich sehe natürlich auch enormes eigenes Potential in
VB.NET, ohne das dies jetzt zwangsläufig für unsere Kunden direkt
einen Mehrwert bedeuten muss, aber sicherlich auch sein kann.
Eine ähnliche Erfahrung mit Controls von Drittanbietern hatten wir
selbst auch schon. Seit dem sind wir entsprechend sensibilisiert und
würden auch gerne ohne auskommen.
Wir müssen aber unter VB6 bestimmte Kompromisse machen – meist
aufgrund nicht vorhandener Zeit für eigene Lösungen. Man muss hier
aber auch feststellen, dass es durchaus auch „seriöse“ Anbieter gibt,
die einen hohen Qualitätsanspruch haben und einem unterm Strich viel
Arbeit abnehmen (Beispiel List&Label von combit).
>> Die Hauptanwendung ist jedoch wirklich ein enorm gro er
>> Brocken. Und nur diese macht mir Sorgen.
>> Zwar haben wir vielen wichtige Funktionen in Klassen und
>> Modulen gekapselt (Datenbankzugriff, Druckroutinen, etc.),
>> aber letztendlich ist es doch nur ein Bruchteil.
>Der zu diesem Bruchteil verbleibende Rest k nnte eine
>Umsetzung nach .net sehr wohl erschweren.
Die gekapselten Funktionen sind lediglich ein Bruchteil. Der Rest ist
der, der sehr aufwändig sein wird.
W. Wolf
[...]
>
> Damit habe ich mir vor vielen Jahren mit den damaligen
> VB-Tools gehörig die Finger verbrannt, nachdem der
> Anbieter dieser Controlsammlung von der Bildfläche
> verschwunden war. Es hat mich eine Menge Zeit und
> Geld gekostet, die entspr. Anwendungen von diesen
> Controls zu "reinigen" um sie weiterhin zufriedenstellend
> pflegen zu können. Für mich waren ab diesem Zeitpunkt
> Controls und sonstige Komponenten von Drittanbietern
> tabu.
>
Ich habe mir wohl auch mit einem einzigen Anbieter eines
großen Controls Namens VB6 die Finger verbrannt, nachdem
dieser Anbieter sein Control von der Bildfläche verschwinden ließ.
Für mich ist dieser Anbieter auch ziemlich tabu. Wo ist da denn
der Unterschied zu deinen Drittanbietern? Ich wünschte ich und Detlef
und viele andere müssten in unserer Software auch lediglich ein paar
lumpige Controls austauschen.
Ich wäre dir auch dankbar, wenn du ab und zu einen Blick auf
das Thema dieser NG werfen könntest. Nicht dass wir noch
so was von OT in dieser NG werden.
Schönen Gruß
W. Wolf
Wolfgang Enzinger
>Tatsächlich könnte man auch an einem Punkt angelangt sein, an dem man
>ganzzahlige Werte wieder in Long-Variablen verstaut und lieber eine
>Klasse formuliert, die den Undefiniert-Zustand zuverlässig
>anderweitig feststellt, ohne die eigentlichen Long-Berechnungen zu
>verlangsamen.
Noch ein bisschen abgespeckt, und wir kommen für solche Fälle bei einem recht
archaischen, sehr performanten und dabei (für VB-Verhältnisse) typsicheren
Konstrukt raus:
Public Type LongExt
Value As Long
IsValidValue As Boolean
End Type
Ganz ohne Variant-, COM- oder .NET-Overhead. :-)
--
Viele Grüsse,
Wolfgang
http://www.enzinger.net
Wolfgang Enzinger
>Auch bei VB6 gehörte DAO schon zum "alten Eisen".
Dieses alte Eisen ist aber noch heute in manchen Fällen die erste Wahl - und
da bin ich mir offensichtlich mit MSFT einig, auch wenn die das so deutlich
niemals sagen würden.
Thorsten Albers
> hmm. Nehmen wir mal an, es geht um eine eine ganze Zahl. Nicht immer
> kann man einen ganzzahligen Wert sinnvoll herausgreifen und mit einer
> Sonderrolle belegen
Wann denn nicht? Der einzige Fall, der mir da in den Sinn kommt, wäre, daß
man sämtliche Werte des möglichen Wertebereiches benötigt - siehe dafür
aber unten.
> vor allem dann nicht, wenn man wegen einer
> fremden oder vom Hersteller gelieferten Bibliothek gar nicht alleine
> über den zulässigen Wertebereich bestimmt.
Dann liegt die Aufgabe bei dem dafür zuständigen Programmierer. Unter
VB.NET ist es nicht anders, da kannst Du auch nicht sicher davon ausgehen,
daß bei Dritten wirklich alle nicht verwendeten Variablen als 'nicht
initialisiert' gekennzeichnet sind.
> An sich könnte man dann
> als Variant deklarieren und hätte so neben den Long-Werten auch noch
> die Möglichkeit, Empty zuzuweisen. Empty wäre auch der Zustand eines
> Variant unmittelbar nach Deklaration. Effizient wäre das nicht, vor
> allem nicht in hochiterierenden Schleifen, in denen ein Variant
> langsamer bearbeitet würde als eine Long-Variable.
>
> Tatsächlich könnte man auch an einem Punkt angelangt sein, an dem man
> ganzzahlige Werte wieder in Long-Variablen verstaut und lieber eine
> Klasse formuliert, die den Undefiniert-Zustand zuverlässig
> anderweitig feststellt, ohne die eigentlichen Long-Berechnungen zu
> verlangsamen.
Reicht der Wertebereich einer Variable nicht aus, um den Zustand 'nicht
initialisiert' zu definieren, kann man statt mit einem Variant oder einer
Klasse ohne Probleme mit einem benutzerdefinierten Typ arbeiten - einfach
ein Boolean-Feld 'fIsInitialized' dazu setzen.
> Vor allem muß auch .NET die Möglichkeit eines zusätzlichen
> Undefinidert-Wertes berücksichtigen und das verlangsamt unweigerlich
> auch unter .NET die Abarbeitung aller Variablen mit einer derartigen
> Eigenschaft. Wenn ich dieses Feature dann obendrein noch immer dabei
> habe, selbst in den Fällen, in denen ich es gar nicht brauche und ein
> solcher Wert daher auch gar nicht zur zulässigen Wertemenge zählt -
> prost Mahlzeit.
ACK - eben Abhängigkeiten, von denen man dann generell oder in besonderen
Fällen nicht loskommt.
Thorsten Albers
<ie883k$cmp$1...@news.albasani.net>...
> Na ja, ich denke zwischen einer einmaligen
> Control-Eigenschaftseinstellung in .net wie
>
> Control.Dock = Fill ' (Left, Top, Right, Bottom)
> oder
> Control.Anchor = Left ' (Or Top or Right or Bottom)
>
> und einem bei jedem (VB6-) Form_Resize für
> alle Controls auszuführenden
>
> Control.Move L, T, W, H
> und/oder ständigen Zuweisungen von
> Control.Left, Control.Top
> Control.Width, Control.Height
>
> ist schon ein spürbarer Unterschied.
'Dock' und 'Anchor' sind Methoden, hinter denen entsprechender Code steht.
Ich habe in VB keinerlei Probleme, mir einmal immer wiederverwendbare
Methoden zu schreiben, die genau das gleiche machen. Der spürbare
Unterschied besteht darin, daß der .NET-Programmierer darauf verzichtet,
den Code selbst zu schreiben, und lieber alles einem Framework überläßt,
wobei er darauf hoffen und sich darauf verlassen muß, daß diese Methoden so
auch in Zukunft zur Verfügung stehen.
> Mit .net - Mitteln gestaltet sich sowas schon spürbar einfacher.
Ich schreibe nur Code, denken tut .NET für mich...
> Ich würde nicht von "Gehampel" reden, meine aber schon,
> dass die umfangreichen Eigenschaften und Methoden des
> .net - String-Objektes und des StringBuilders vieles vereinfachen.
Wie gesagt, mit zusätzlichen Bibliotheken auch in VB 6 kein Problem. Viele
VB.NET-Programmierer scheinen zu denken, das seien tolle Features von
VB.NET, und vergessen offensichtlich gerne, daß dahinter zig MBs an
Bibliotheken stehen.
> Hier würde mich das "konkrete Warum" schon interessieren?
Weil es unter VB nun wirklich keinen besonderen Aufwand darstellt, eine
entsprechende Information mit den Variablen zu verwalten, sei es durch
einen definierten Wert des Wertebereiches, sei es durch eine zusätzliche
Variable.
> Aber ich würde nicht behaupten wollen, dass VB.net
> gegenüber VBclassic keine oder nur geringe Vorteile brächte.
Die Vorteile bietet nicht VB.NET sondern eine dicke fette
Bibliothekensammlung namens Framework, die bei den regelmäßigen Updates von
MS - 'mal so nebenbei erwähnt - inzwischen geschätzte 1/3 des Umfanges
ausmacht.
Der eigentliche und tatsächlich einzige Vorteil ist, daß man vieles nicht
mehr selbst programmieren bzw. sich nicht Komponenten von Dritten besorgen
muß (MS ist ja bekanntlich kein Dritter sondern gehört voll und ganz zur
Familie). Mich wundert immer, daß die gläubigen .NET-Programmierer noch
nicht dazu übergegangen sind, ihre Programme mit 'MS inside' oder 'pure MS'
zu zertifizieren.
> Schau Dir mal
> www.gssg.de -> Visual Basic -> VB.net
> -> Multimedia / Midi
> -> MidiOrchestra
> an. Da würde mich interessieren, wie Du den Aufwand für ein
> Programm mit gleicher Funktionalität und Benutzeroberfläche
> in VBclassic einschätzen würdest, bzw. wie weit Du es überhaupt
> mit VBclassic für realisierbar hältst.
Mit entsprechenden von einem selbst oder anderen geschriebenen Bibliotheken
läßt sich in VB alles verwirklichen, was in .NET verwirklicht werden kann,
was nicht heißen soll, daß jede dieser Bibliotheken in VB geschrieben
werden könnte - genau wie bei .NET.
Lars P. Wolschner
> Lars P. Wolschner <lars.wo...@nexgo.de> schrieb im Beitrag
> <4d0796bb$0$6769$9b4e...@newsspool3.arcor-online.net>...
>> hmm. Nehmen wir mal an, es geht um eine eine ganze Zahl. Nicht
>> immer kann man einen ganzzahligen Wert sinnvoll herausgreifen
>> und mit einer Sonderrolle belegen
>
> Wann denn nicht? Der einzige Fall, der mir da in den Sinn kommt,
> wäre, daß man sämtliche Werte des möglichen Wertebereiches
> benötigt - siehe dafür aber unten.
Genau diesen Fall meinte ich. Es ist auch guter Stil, die Möglich-
keiten einer aufgerufenen, genutzten Schicht im Aufrufer zu
erhalten und nicht einfach wegzukappen.
>> vor allem dann nicht, wenn man wegen einer
>> fremden oder vom Hersteller gelieferten Bibliothek gar nicht
>> alleine über den zulässigen Wertebereich bestimmt.
>
> Dann liegt die Aufgabe bei dem dafür zuständigen Programmierer.
... der aber leider nicht immer greifbar ist, etwa weil er bei
Microsoft sitzt.
> Unter VB.NET ist es nicht anders, da kannst Du auch nicht sicher
> davon ausgehen, daß bei Dritten wirklich alle nicht verwendeten
> Variablen als 'nicht initialisiert' gekennzeichnet sind.
Ich arbeite bei VBA gern mit Indexierungen, die bei 1 beginnen,
auch die VBA.Collection beginnt ihren numerischen Index bei 1.
Standardmäßig habe ich globale Konstanten lNoIndex (Long) und
iNoIndex (Integer), die mit dem Wert 0 definiert sind. 0 ist
nämlich auch der Wert, den Long- und Integer-Variablen nach ihrer
Deklaration automatisch vom Laufzeitsystem bekommen, so daß ver-
gessene Initialisierungen keine Fehler auslösen werden. Optionale
Parameter belege ich dann mit lNoIndex bzw. iNoIndex vor und komme
so mit einem einfachen und daher performant zu verarbeitenden
Datentyp aus, kann aber dennoch die An- bzw. Abwesendheit eines
Aktualparameters erkennen. IsMissing() funktioniert nämlich nur mit
den fetten Variants.
DAO beginnt aber leider schon bei 0, das erste Field eines
DAO.Recordset hat also den Index 0. Mittlerweile ist das Angebot
meiner im Laufe der Jahre entstandenen Basisfunktionen umfangreich
genug, daß man damit auskommt, so daß ich dem Aufrufer gegenüber
wieder bei 1 beginnen könnte. Da viele meiner Funktionen neben
einzelnen Daten auch Arrays und teilweise auch noch kommaseparierte
Strings (Feldlisten) verarbeiten können, stellt sich die Frage, wie
das Resultat indiziert werden sollte. Hier reproduziere ich dann
den Index der hereingegebenen Daten oder beginne mit 0, weil der
Aufrufer das von DAO so gewohnt sein wird. Warum Microsoft bei DAO-
Objekten mit 0 beginnt, habe ich aber nie verstanden.
>> An sich könnte man dann
>> als Variant deklarieren und hätte so neben den Long-Werten auch
>> noch die Möglichkeit, Empty zuzuweisen. Empty wäre auch der
>> Zustand eines Variant unmittelbar nach Deklaration. Effizient
>> wäre das nicht, vor allem nicht in hochiterierenden Schleifen,
>> in denen ein Variant langsamer bearbeitet würde als eine
>> Long-Variable.
>>
>> Tatsächlich könnte man auch an einem Punkt angelangt sein, an
>> dem man ganzzahlige Werte wieder in Long-Variablen verstaut und
>> lieber eine Klasse formuliert, die den Undefiniert-Zustand
>> zuverlässig anderweitig feststellt, ohne die eigentlichen
>> Long-Berechnungen zu verlangsamen.
>
> Reicht der Wertebereich einer Variable nicht aus, um den Zustand
> 'nicht initialisiert' zu definieren, kann man statt mit einem
> Variant oder einer Klasse ohne Probleme mit einem
> benutzerdefinierten Typ arbeiten - einfach ein Boolean-Feld
> 'fIsInitialized' dazu setzen.
... was aber ihren Speicherbedarf erhöht und ebenso die
Verarbeitung verlangsamt. Außerdem kann ich benutzerdefinierte
Typen auch nur in genauso spezifizierten Parametern übergeben,
Variants können benutzerdefinierte Typen nicht tragen. Ihr
Anwendungsbereich ist daher zumindestens in meiner Praxis recht
begrenzt.
Frank Müller
> Das ist nun aber nicht gerade vergleichbar: Es handelt sich dabei um
> eine 16 Bit-Version, die entsprechend auch in der 16 Bit-Umgebung von
> Windows läuft. Daß sich an der von Windows-Version zu Windows-Version
> nichts mehr oder nicht mehr viel ändert, ist ja logisch - es gibt sie
> entweder immer in der - mehr oder weniger - gleichen Form oder
> überhaupt nicht mehr.
> Bei 32 Bit-Anwendungen sieht das etwas anders aus.
Das ist zwar nicht direkt, aber indirekt schon vergleichbar.
Mit VB6 kann man halt nur 32 Bit Anwendungen schreiben,
die wird auch irgendwann "unten raus fallen" so wie jetzt
die 16er Programme nicht mehr direkt unterstützt werden.
Jetzt haben wir 64er Betriebssyteme, 32er Anwendungen laufen
noch, aber was ist wenn wir irgendwann mal 128er oder
256er haben? Ob dann die 32er Anwendungen noch unterstützt
werden ist fraglich.
Aber auch jetzt bekommt man durch Virtualisierung die
16er Programme wie Corel 3 noch zum laufen. Die Frage ist
halt nur ob man das möchte oder nicht. Selbst heute gibt
es noch C64 Emulatoren usw. Die funktionieren auch noch.
Ich plädiere natürlich nicht dafür eine jetzt bestehende Anwendung
auf "alle Ewigkeit" mit VB6 weiter entwickeln zu wollen,
aber einen kurzfristigen Handlungsbedarf eine solche auf .NET
umstellen zu müssen sehe ich nicht. Schon gar nicht wenn es
es sich um eine z.B. Branchensoftware handelt.
Aber für die Umstellung haben wir noch viele Jahre Zeit
meiner Meinung nach.
Gruß,
Frank
Schmidt
"Lars P. Wolschner" <lars.wo...@nexgo.de> schrieb im Newsbeitrag
news:4d07f81f$0$6772$9b4e...@newsspool3.arcor-online.net...
> Ich arbeite bei VBA gern mit Indexierungen, die bei 1 beginnen,
> auch die VBA.Collection beginnt ihren numerischen Index bei 1.
> Standardmäßig habe ich globale Konstanten lNoIndex (Long) und
> iNoIndex (Integer), die mit dem Wert 0 definiert sind.
>...
> Optionale Parameter belege ich dann mit lNoIndex bzw.
> iNoIndex vor ...
> ...
> DAO beginnt aber leider schon bei 0, das erste Field eines
> DAO.Recordset hat also den Index 0.
Warum dann nicht bei diesen "typischen Index-Variablen" [0..n_positiv]
bzw. [1..n_positiv] Deine globalen NoIndex-Konstanten als:
Public Const lNoIndex As Long = -2147483648
bzw.
Public Const iNoIndex As Integer = -32768
vorbelegen?
Damit geht der jeweilige Datentyp (im jeweiligen Kontext)
nur seines kleinsten darstellbaren Werts verlustig + keine
Probleme mehr mit der "Vorbelegung" optionaler Parameter,
die (normalerweise) ZeroBased Indexes transportieren.
Also Szenarien, wo ein "Nullable of WertTyp" irgendwie
"kriegsentscheidend" wäre, wollen mir nicht so recht
einfallen - zum einen gibt es Enums - dann gibt es
TypeDefs - dann gibt es "Nullable" bzw. "Emptyable"
Variants - oder so Sachen wie oben dargestellt, wenn
man z.B. sicher weiss, dass Index-Bereiche eigentlich
nur >= 0 sind, dann hat man im Negativ-Bereich eines
"signed Typs" einfach "einen ganzen Haufen Platz für
alles Mögliche" (sogar das Mapping kompletter Enums).
Olaf
Frank Müller
[Virtualisierungsmöglichkeiten]
> Der Aufwand der Virtualisierung ist für uns
> Entwickler überschaubar, einmal konfiguriert reicht
> ein Paketierungs-Vorgang, vergleichbar mit einer
> Kompilierung. Es entsteht eine Exe, welche alle
> Abhängigkeiten enthält. Der Kunde muß nichts mehr
> tun, gar nichts mehr. Selbst ein Start von Stick
> ist möglich. Das ist echtes Copy&Run.
ACK
> Was damit nicht geht ist das Bunte. Aber auch hier
> sehe ich VB nicht als Sackgasse. Das was uns Olaf
> gezeigt hat, sieht verdammt gut aus.
Richtig, aber "Das Bunte" ist ja nur eine
Randerscheinung bei kommerzieller Software.
Da wäre es nicht weiter schlimm wenn das
nicht mit übernommen werden könnte.
Was Olaf macht darfst du aber bitte nicht
nur auf "das Bunte" reduzieren, da steckt viel
mehr dahinter. Aber du hast recht, das ist ein
Weg in die Zukunft für VB6 Anwendungen.
> Die von dir
> erwähnten Kreuzungen könnten sogar Zollübergänge
> zu anderen Betriebssystemen sein. Ich nenne es bewusst
> Zollübergänge, weil wir sicher nicht alles mitnehmen
> können (dürfen). Wir werden Zoll bezahlen müssen (z.B.
> statt der Access-DB eine Lite-SQL nutzen).
Richtig und das nicht nur zu anderen Betriebssystemen
sondern auch zu anderer Hardware beim User usw.
Der Begriff Zoll ist zutreffend, aber da gibt es auch
die Schmuggler usw. sowohl aus User- als auch aus
Anwendersicht. Wer sich heute ein Win7 System und
den XP-Mode installiert macht das deswegen um sich
seine "alten" Anwendungen rüber schmuggeln zu können.
Und dann kommt noch die Zollfahndung ins Spiel,
die besteht dann darin, dass es dann doch evtl. nicht
zu 100% so funktioniert wie vorher. Die Strafe
für das "erwischt werden" besteht dann darin, dass
sich die User halt mit ihrem neuen BS beschäftigen
müssen. (Die Entwickler natürlich auch)
Gruß,
Frank
Thorsten Albers
<ie92dl$fhr$00$1...@news.t-online.com>...
> Das ist zwar nicht direkt, aber indirekt schon vergleichbar.
Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise die
Abwärtskompatibilität sehr hoch" - da 16 Bit-Programme als Beispiel
anzuführen, ist nicht sinnvoll, weil die 16 Bit-Kompatibilität seit Windows
95/NT 3.5 eigentlich mehr oder weniger die gleiche ist, und MS diese nicht
jedes Mal an die neue Windows-Version anpassen muß. 32 Bit-Kompatibilität
bestimmter Bereiche fortzuführen ist für MS wesentlich komplexer und
keineswegs so sicher wie 16 Bit-Kompatibilität. Solange neuere
Windows-Versionen 16 Bit-Kompatibilität mitbringen, ist es
wahrscheinlicher, Kompatibilitätsprobleme mit einem 32 Bit-Programm denn
mit einem 16 Bit-Programm zu bekommen.
Oliver Dietz
> ich habe keinen Kunden der Aero usw. eingeschaltet
> hat. Und schon gar nicht bei Kunden die eine VB6 Software
> viele Jahre nutzen wo es solche Sachen noch gar nicht gab.
Aero ist mittlerweile auf einem mittelklasse Büro-PC automatisch aktiviert.
Inklusive 125% DPI-Schriftauflösung wenn das TFT groß genug ist.
>> Unter aktuellen Programmierumgebungen bekommt man die SDKs
>> frei Haus mit Beispielcode ... unter VB6 ist viel Handarbeit
>> angesagt.
>
> SDKs gab es immer schon, sind auch in der MSDN integriert
> schon seit was ich wann.
ja klar. Die SDKs werden aber für .NET (oder C) geschrieben (Beispiele,
Quellcodes, vorausgesetzte Hilfsfunktionen). Unter VB6 kannst du die
vielleicht verwenden ... aber unter .NET bist du schneller produktiv.
>> Komponentenhersteller haben den VB6-Support auch mehr oder
>> weniger aufgekündigt
>
> Viele Hersteller von Komponenten haben aber auch
> .NET Versionen im Programm.
Die du unter VB6 nicht verwenden kannst?!
>> - ein Ribbon-Menü für VB6 zu finden, das auch
>> stabil läuft, wird schon schwerer.
>
> Wer will so etwas?
Wer will ein Mausrad?
(das von VB6-Usercontrols nicht von Haus aus unterstützt wird)
Wer will 125% DPI Textauflösung (was Windows 7 manchmal automatisch
einstellt).
Wer will fremde Webservices anbinden?
Wer will PNG-Dateien öffnen?
Wer will Try-Catch-Blöcke?
Wer will Vererbung nutzen?
Wer will ...
Nochmal: Es sind nur Beispiele die vielleicht in deinem konkreten Fall nicht
von Bedeutung sind und es ist auch alles mit VB6 lösbar. Effizienter ist es
aber unter .NET, weil dort nicht nur die Technologien von 1998 unterstützt
werden (und der Rest selbst programmiert werden muss) ... und jedes Jahr
kommt etwas mehr dazu, das unter VB6 mühsam und unter .NET easy ist ... wann
die Vorteile überwiegen und das Support-Risiko zu groß wird muss jeder
selbst entscheiden.
"Noch" gibt es eine "Just-Works"-Support-Zusage von MS ...
Viele Grüße,
Oliver
Schmidt
"Peter Götz" <gssg_...@gssg.de> schrieb im Newsbeitrag
news:ie8bhq$i55$1...@news.albasani.net...
> > Es besteht auch momentan kein funktionaler Anreiz für
> > einen Umstieg auf VB.NET. Der einige Grund (bzw.
> > Sorge) ist, rechtzeitig zu wechseln,
>
> Na ja, den Begriff "rechtzeitig" würde ich in diesem
> Zusammenhang nicht mehr wählen. Das wäre vor 10
> oder sogar noch mehr Jahren angebracht gewesen.
Aber wieso denn.
Wenn der Trend hin zu browserbasierten Anwendungen
(in Verbindung mit immer besseren Javascript-Engines
bzw. -Frameworks) weiter so geht wie bisher, dann gibt
es künftig (3-4 Jahre) eine Menge mehr als nur *.asp oder
*.aspx zur Auswahl (an leistungsfähigen "Web-Frameworks").
Jede Investition in ".NET-basierte Fat-Clients" (reine
Desktop-Anwendungen, als "Zwischenversion, die man
sich 'on top of VB6' noch unbedingt geben muss") wäre
dann rausgeschmissenes Geld gewesen.
Und selbst wenn "neu zu schreibende App XY" wieder
ein FAT-Client werden soll (von mir aus auch in .NET),
dann ist doch die Frage, ob nicht z.B. das Auslassen des
Erwerbs von z.B. WinForms-KnowHow (wie z.B. in
Deinem MIDI-Client zu sehen) und das sofortige
Beginnen mit WPF nicht unter'm Strich effizienter wäre.
Genauso gut kann man aber auch Python in Verbindung
mit QT oder GTK hernehmen und ansprechende (und
plattformunabhängige) Desktop-GUIs damit bauen.
Warum diese "wir wollen weg von VB6"-Diskussion immer
automatisch in die "man nimmt natürlich VB.NET, bist eh'
spät dran"-Richtung läuft, versteh ich nicht ganz.
Ein Neuschreiben auf Basis neu zu lernender Begleit-
Bibliotheken! (dafür geht doch die meiste Zeit drauf, und
nicht für die Sprachsyntax) steht doch ohnehin an, da
1:1 (wie Du selbst sagst) nicht geht, bzw. empfehlenswert ist.
Und ob man diese Zeit nun in Python + neu zu lernende QT-
Klassen investiert, oder in VB.NET + neu zu lernende
"WPF/WCF-Klassen", wird sich am Ende nicht viel geben -
ausser dass man sich mit der einen Geschichte "ziemlich
festlegt" (auf eine Plattform und einen Library-Hersteller,
der auf vorhandene Code-Investitionen erwiesenermaßen
keine Rücksict nimmt) -
während die andere Variante wesentlich krisenfester ist
(da von Communities getragene, offene Quellen existieren -
sowohl für die Sprache, als auch die verwendeten Frame-
work-libs).
Olaf
Schmidt
> Schau Dir mal
>
> www.gssg.de -> Visual Basic -> VB.net
> -> Multimedia / Midi
> -> MidiOrchestra
>
> an. Da würde mich interessieren, wie Du den Aufwand für ein
> Programm mit gleicher Funktionalität und Benutzeroberfläche
> in VBclassic einschätzen würdest, bzw. wie weit Du es
> überhaupt mit VBclassic für realisierbar hältst.
Nix gegen die Anwendung selbst, die ist gut gemacht, sieht
hübsch aus usw. (hab's gerade ausprobiert) - aber was genau
wäre jetzt mit VBclassic nicht realisierbar - bzw. (Deiner
Meinung nach) "schwer umzusetzen"?
Olaf
W. Wolf
>> Was damit nicht geht ist das Bunte. Aber auch hier
>> sehe ich VB nicht als Sackgasse. Das was uns Olaf
>> gezeigt hat, sieht verdammt gut aus.
>
> Richtig, aber "Das Bunte" ist ja nur eine
> Randerscheinung bei kommerzieller Software.
> Da w�re es nicht weiter schlimm wenn das
> nicht mit �bernommen werden k�nnte.
>
> Was Olaf macht darfst du aber bitte nicht
> nur auf "das Bunte" reduzieren, da steckt viel
> mehr dahinter. Aber du hast recht, das ist ein
> Weg in die Zukunft f�r VB6 Anwendungen.
>
Du hast vollkommen recht und ich m�chte mich aus-
r�cklich bei Olaf f�r "das Bunte" entschuldigen.
Wenn die Finger schneller sind als das Denken,
dann kommen halt solche Spr�che dabei heraus. Nat�rlich
will ich mit meiner Aussage Olafs Arbeit nicht auf
die Oberfl�chengestaltung mittels Cairo reduzieren.
Das was Olaf macht, k�nnte eine (R)Evolution f�r das
ganze VB sein. Es k�nnte das VB werden, von dem ich
seit dem Erscheinen von VB4 tr�ume. Dazu nur
folgende Stichw�rter: RPC, Regless, Multithreading,
SQLLite-Zugriff oder die Mozilla-Adaption.
Und ja, ich befahre diese "Einbahnstra�e" weil ich
darin auch kein gr��eres Risiko sehe als auf der
Dauerbaustelle Autobahn.
Sch�nen Gru�
W. Wolf
Ahmed Martens
Am Tue, 14 Dec 2010 19:14:03 +0100 schrieb Peter G�tz:
>> Aber wo Licht ist, ist auch Schatten. Ich tue mich z. B. extrem
>> schwer mit den Datenbankzugriffen.
>
> Ursache hierf�r ist aber, dass Du noch zu sehr an die von
> VBclassic her gewohnten engen Bindung zwischen Anwendung
> und Datenbankhintergrund gewohnt bist.
ich gebe Dir ja recht. Aber da ich mir alles selbst (nat�rlich mit Eurer
Unterst�tzung) erlerne, ben�tige ich zumindest einmal leicht
nachvollziehbare Beispiele.
Also ein einfaches Dataview/Datatables usw. mit einem simplen Beispiel,
wie die Daten editiert, gel�scht oder angef�gt werden k�nnen. Daran kann
ich mich dann wenigstens einmal entlang hangeln. Die Hilfe ist alles
andere als eine Hilfe. Hier drehe ich mich immer wieder im Kreis.
Deine Beispiele auf Deiner Webseite sind absolut umfangreich. Hier
werden aber alle Zugriffe und Methoden derart gekapselt, dass ich damit
total �berfordert bin.
Vielleicht k�nntest Du mir einfach einmal so ein Beispiel zur Verf�gung
stellen.
> > Ich kann mich ehrlich gesagt nicht von meinen DAO-Zugriffen
> > (Recordsets) l�sen.
>
> Auch bei VB6 geh�rte DAO schon zum "alten Eisen". ADO
> mit seinen ersten Ans�tzen von verbindungslosem Arbeiten
> ist da schon sehr viel n�her an der Arbeitsweise in .net.
Ich programmiere ja nicht nur in VB6 sondern auch in Access. Und hier
ist MS von ADO wieder zur�ck auf DAO gewechselt. Von daher bin ich in
der alten DAO-Welt einfach heimischer. :-)
Gru� Ahmed
--
Antworten bitte nur in der Newsgroup.
Peter Götz
>> Na ja, den Begriff "rechtzeitig" würde ich in diesem
>> Zusammenhang nicht mehr wählen. Das wäre vor 10
>> oder sogar noch mehr Jahren angebracht gewesen.
> Aber wieso denn.
> Wenn der Trend hin zu browserbasierten Anwendungen
> (in Verbindung mit immer besseren Javascript-Engines
> bzw. -Frameworks) weiter so geht wie bisher, dann gibt
> es künftig (3-4 Jahre) eine Menge mehr als nur *.asp oder
> *.aspx zur Auswahl (an leistungsfähigen "Web-Frameworks").
>
> Jede Investition in ".NET-basierte Fat-Clients" (reine
> Desktop-Anwendungen, als "Zwischenversion, die man
> sich 'on top of VB6' noch unbedingt geben muss") wäre
> dann rausgeschmissenes Geld gewesen.
Ich höre wohl auch, dass immer wieder von browserbasierten
Anwendungen gesprochen wird, nur sehe ich bei meinen
Kunden (grosse Industrieunternehmen der Elektro-/Elektronik-
branche und div. Behörden) so gut wie keine.
> Und selbst wenn "neu zu schreibende App XY" wieder
> ein FAT-Client werden soll (von mir aus auch in .NET),
> dann ist doch die Frage, ob nicht z.B. das Auslassen des
> Erwerbs von z.B. WinForms-KnowHow (wie z.B. in
> Deinem MIDI-Client zu sehen) und das sofortige
> Beginnen mit WPF nicht unter'm Strich effizienter wäre.
Was meinst Du mit "Auslassen des Erwerbs von
z.B. WinForms-KnowHow"?
> Genauso gut kann man aber auch Python in Verbindung
> mit QT oder GTK hernehmen und ansprechende (und
> plattformunabhängige) Desktop-GUIs damit bauen.
Kommt bei meinen Kunden nicht vor.
> Warum diese "wir wollen weg von VB6"-Diskussion immer
> automatisch in die "man nimmt natürlich VB.NET, bist eh'
> spät dran"-Richtung läuft, versteh ich nicht ganz.
Ich sage keineswegs, dass der Nachfolger von VB6
unbeding VB.net sein müsste.
Wenn jemand sagt, er müsse einen Umstieg mindestens 2
bis 3 Jahre vorausplanen, dann denke ich aber schon, dass
er mit einem Umstieg auf .net eben um 10 Jahr zu spät
daran ist.
> Ein Neuschreiben auf Basis neu zu lernender Begleit-
> Bibliotheken! (dafür geht doch die meiste Zeit drauf, und
> nicht für die Sprachsyntax) steht doch ohnehin an, da
> 1:1 (wie Du selbst sagst) nicht geht, bzw. empfehlenswert ist.
Richtig, 1:1 macht in den seltensten Fällen Sinn, da es eben
kaum zu optimalen Lösungen führt. Natürlich muss man
für einen Umstieg nach .net eine Vielzahl neuer Bibliotheken
kennenlernen, eben wie für jede andere Programmierumgebung
auch. Das alleine spricht aber doch weder für oder gegen die
eine noch die andere Sprache. Wenn ich aber ausschliesslich
SW für Windows entwickle, weil Kunden das so wünschen,
dann macht es schon Sinn ein hierzu passendes, vom
Betriebssystemhersteller kommendes Programmierwerkzeug
zu nutzen. Die Entscheidung ob Windows oder ein anderes
Betriebssystem ist bei allen meinen Kunden längst gefallen,
ich bin also gar nicht in der Situation, darüber zu diskutieren.
> Und ob man diese Zeit nun in Python + neu zu lernende QT-
> Klassen investiert, oder in VB.NET + neu zu lernende
> "WPF/WCF-Klassen", wird sich am Ende nicht viel geben -
s.oben:
Meine Kunden bekommen die von mir entwickelte SW inkl.
Sourcecode und hier wird eben VB.net oder teilweise auch
C++ gewünscht.
> ausser dass man sich mit der einen Geschichte "ziemlich
> festlegt" (auf eine Plattform und einen Library-Hersteller,
> der auf vorhandene Code-Investitionen erwiesenermaßen
> keine Rücksict nimmt) -
Auch hierzu kann ich nur sagen:
Bei meinen Kunden gibt es nur eine Plattform namens
Windows, Ausnahmen sind hier lediglich einige sehr
wenige Sonderlösungen.
> während die andere Variante wesentlich krisenfester ist
> (da von Communities getragene, offene Quellen existieren -
> sowohl für die Sprache, als auch die verwendeten Frame-
> work-libs).
Auch hier ist meine Erfahrung eine andere.
Meine Kunden planen ihre Systeme über Zeiträume von
5 Jahren und auch mehr. So war bei diesen nun lange Zeit
Win XP das Betriebssystem für alle Büro- und Fertigungs-
arbeitsplätze. Vista wurde übersprungen und ist nun
gerade der Umstieg nach Win7 weitgehend abgeschlossen,
aber eben keiner nach Linux oder sonstige Unix-Abkömmlinge.
Peter Götz
> 'Dock' und 'Anchor' sind Methoden, hinter denen entsprechender
> Code steht.
... der bestens optimiert ist und den ich nicht mehr selbs
schreiben muss.
> Ich habe in VB keinerlei Probleme, mir einmal immer
> wiederverwendbare Methoden zu schreiben, die genau
> das gleiche machen.
Natürlich ist auch das möglich, aber eben mit
erhöhtem Arbeitsaufwand, den irgendjemand (z.B. der
Kunde) bezahlen muss.
> Der spürbare Unterschied besteht darin, daß der
> .NET-Programmierer darauf verzichtet, den Code
> selbst zu schreiben, und lieber alles einem Framework
> überläßt, wobei er darauf hoffen und sich darauf
> verlassen muß, daß diese Methoden so auch in
> Zukunft zur Verfügung stehen.
Nun haben wir ja schon eine ganze Reihe von .net-Versionen
hinter uns, aber .Dock und .Anchor sind immer noch vorhanden
und werden es ganz sicher auch in künftigen Versionen sein.
Da habe ich dann schon deutlich grössere Probleme mit
Controls für VBclassic von Drittherstellern, bei denen es
schon erheblich mehr als einmal vorkam, dass solche
Hersteller plötzlich vom Markt verschwunden waren.
>> Mit .net - Mitteln gestaltet sich sowas schon spürbar einfacher.
>
> Ich schreibe nur Code, denken tut .NET für mich...
>
>> Ich würde nicht von "Gehampel" reden, meine aber schon,
>> dass die umfangreichen Eigenschaften und Methoden des
>> .net - String-Objektes und des StringBuilders vieles vereinfachen.
>
> Wie gesagt, mit zusätzlichen Bibliotheken auch in VB 6 kein Problem.
Eben schon ein Problem. Solche Bibliotheken fallen nicht vom
Himmel. Sie müssen geplant, geschrieben und gründlichst
ausgetestet werden. Das kostet Zeit und Geld und beeinflusst
somit den Preis einer dem Kunden anzubietenden Software.
> Viele VB.NET-Programmierer scheinen zu denken, das
> seien tolle Features von VB.NET, und vergessen offensichtlich
> gerne, daß dahinter zig MBs an Bibliotheken stehen.
Natürlich gibt es in .net jede Menge "tolle Features" und natürlich
stehen dahinter umfangreiche Bibliotheken, die es aber schon
gibt und die ich nicht auf eigene Kosten selbst entwickeln muss.
>
>> Hier würde mich das "konkrete Warum" schon interessieren?
> Weil es unter VB nun wirklich keinen besonderen Aufwand darstellt, eine
> entsprechende Information mit den Variablen zu verwalten, sei es durch
> einen definierten Wert des Wertebereiches, sei es durch eine zusätzliche
> Variable.
Eben das Wörtchen "zusätzlich" macht den Unterschied. Natürlich
kann ich auch in VB6 alles Möglich und Unmögliche machen, aber
eben immer mit dem Zusatz "zusätzlich", der Zeit und Geld kostet.
Für den Hobbyisten mag das keine Rolle spielen, bei kommerzieller
SW-Entwicklung gelten dafür schon etwas andere Gesetzmässigkeiten.
>
>> Aber ich würde nicht behaupten wollen, dass VB.net
>> gegenüber VBclassic keine oder nur geringe Vorteile brächte.
>
> Die Vorteile bietet nicht VB.NET sondern eine dicke fette
> Bibliothekensammlung namens Framework, die bei den
> regelmäßigen Updates von MS - 'mal so nebenbei erwähnt -
> inzwischen geschätzte 1/3 des Umfanges ausmacht.
Dieses Framework ermöglicht es aber eben auch mit
den verschiedensten Programmiersprachen (VB.net, C#
usw.) zu arbeiten und diese auch gemischt einsetzen zu
können.
> Der eigentliche und tatsächlich einzige Vorteil ist, daß man vieles
> nicht mehr selbst programmieren
s.oben:
Was eine deutlich Reduzierung an Aufwand und damit
Kosten zur Folge hat.
> bzw. sich nicht Komponenten von Dritten besorgen muß
Bei denen ein schneller oft sofort gewünschter Support
oft zu wünschen übrig lässt und damit zu aufwändigen
und zeitintensiven Workarounds führen kann.
> (MS ist ja bekanntlich kein Dritter sondern gehört voll
> und ganz zur Familie).
Wenn die vom Kunden vorgegebene Systemplattform
Window heisst, dann ist das so.
> Mich wundert immer, daß die gläubigen .NET-Programmierer
> noch nicht dazu übergegangen sind, ihre Programme mit
> 'MS inside' oder 'pure MS' zu zertifizieren.
Na ja, ich denke, diesen Vorwurf richtest Du bei mir
an den falschen. Ich habe sogar noch einen Kunden
der mit MS-Dos seine Sudkesselanlagen steuert und
damit nach wie vor ein vorzügliches Bier braut. Es
gibt für diesen Anwender nicht den geringsten Grund
dies zu ändern und ich sehe das ganz genauso.
>> Schau Dir mal
>> www.gssg.de -> Visual Basic -> VB.net
>> -> Multimedia / Midi
>> -> MidiOrchestra
>> an. Da würde mich interessieren, wie Du den Aufwand für ein
>> Programm mit gleicher Funktionalität und Benutzeroberfläche
>> in VBclassic einschätzen würdest, bzw. wie weit Du es überhaupt
>> mit VBclassic für realisierbar hältst.
>
> Mit entsprechenden von einem selbst oder anderen geschriebenen
> Bibliotheken läßt sich in VB alles verwirklichen, was in .NET
> verwirklicht werden kann, was nicht heißen soll, daß jede dieser
> Bibliotheken in VB geschrieben werden könnte - genau wie bei .NET.
Dann hast Du Dir den Code dieses Programmes aber offensichtlich
noch nicht so ganz genau angesehen und ich würde schon ganz
gerne sehen, wie und mit welchem Aufwand Du den Zugriff auf
das SDK von Creative realisieren würdest.
Peter Götz
> ...
> Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise
> die Abwärtskompatibilität sehr hoch" - ....
Hier lobst Du, dass Microsoft die Abwärtskompatibilität sehr
hoch hält, in einem Deiner anderen Postings argumentierst
Du gegen .Anchor und .Dock genau gegenteilig und bezweifelst,
dass diese Eigenschaften irgendwann einmal nicht mehr
verfügbar sein könnten.
Meinst Du nicht auch, dass Du Dir hier selbst ziemlich heftig
widersprichst?
Peter Götz
> Der Umstieg auf eine andere Programmierumgebung würde
> uns sicherlich für 2 Jahre weitestgehend in einen unproduktiven
> Zustand versetzen.
2 Jahre sind durchaus realistisch, wenn man das .net Framework
wirklich umfassend kennenlernen und optimal einsetzen will.
Ob man in dieser Zeit vollkommen oder weitgehend unproduktiv
ist, ist eine Frage des vorhandenen Personals.
> Die Produktivität ist jedoch einer unserer großen Vorteile,
> die unsere Kunden sehr schätzen und uns von Mitbewerbern
> unterscheidet. In diesem Zusammenhang nehme ich auch
> gerne in Kauf, dass ich für die Weiterentwicklung unserer
> Anwendungen unter VB6 mehr Zeit benötige,
"Mehr Zeit für die Weiterentwicklung benötigen" ist aber
ein Widerspruch zu hoher "Produktivität".
> jedoch zeitgleich die aktuelle Leistungsfähigkeit unserer Firma
> aufrecht erhalten kann.
> Ich bin auch nicht zu bequem mich in eine neue Sprache einzulernen,
> sondern es geht eben wirklich darum, den momentanen Status quo
> hinsichtlich des Kundenservices beibehalten zu können.
s.oben:
Das ist wohl mehr eine Frage des verfügbaren Personals.
> Insofern ist eine zwangsweise Umstellung bei mir erst einmal mit
> berechtigten Sorgen verbunden. Wir müssen in unserer Situation
> vorausblickend (2 Jahre) planen.
Einen Umstieg auf .net konnte man bereits vor mehr als
10 Jahren planen und auch beginnen. MS war sehr grosszügig
mit der Bereitstellung schon der ersten Beta- und sogar Vorbeta-
Versionen von VB.net bzw. des .net-Frameworks.
> Wenn beispielsweise in 3 Jahren ein neues Betriebssystem von
> Windows veröffentlicht wird, das VB6 Anwendungen nicht mehr
> unterstützt, dann müssten wir jetzt so langsam einmal handeln.
Da ich nicht weiss, wie lange VB6 von künftigen Windowsversionen
noch unterstützt wird und das auch schon vor 10 Jahren nicht
wusste, war für mich bereits damals klar wie und womit ich
künftig arbeiten würde.
> Ich gehe aber davon aus, dass VB6-Anwendungen auch
> unter dem nächsten Betriebssystem von Windows problemlos
> lauffähig sind
Ich vermute das auch, aber garantieren tut mir
das niemand.
> (mit Windows 7 hatten wir übrigens keinerlei Probleme).
> Aber wer weiß dass schon.
> Ich denke es lohnt sich, dass wir jetzt unsere Erfahrungen mit
> VB.NET sammeln und vielleicht unsere bestehenden Anwendungen
> unter VB6 versuchen zu optimieren.
Wenn "Optimieren" bedeutet, VB6 Anwendung so umzugestalten
dass sie später weitgehend 1:1 nach .net umzusetzen sind, dann
habe ich da schon beachtliche Zweifel.
.net bietet z.T. völlig andere neue Möglichkeiten und nur mit
ebenfalls völlig anderen Programmierkonzepten sind diese
Möglichkeiten uneingeschränkt nutzbar. Der Aufwand, die
VB6-Anwendungen erst anzupassen und dann der weitere
Aufwand diese nach .net umzusetzen könnte sehr schnell
zu hoch und unwirtschaftlich werden.
> In einem Jahr kann ich dann vielleicht abschätzen, inwieweit sich
> unsere Anwendungen problemlos umstellen lassen und welcher
> Aufwand damit verbunden ist.
Ich kann aus eigener Erfahrung sagen, dass dieser Aufwand
keineswegs vernachlässigbar ist. Keine meiner vorhandenen
Anwendungen konnte mit vernünftigem Aufwand und mit Blick
auf optimale Ergebnisse und stabiles Laufzeitverhalten weitgehend
1:1 umgesetzt werden, weshalb es letztlich auf völlige
Neukonzepte hinauslief. Ich kann heute aber sagen, dass sich
der Umstieg gelohnt hat, da u.a. der Aufwand für Pflege und
Erweiterungen bestehender Projekte spürbar geringer
und damit kostengünstiger geworden ist.
Peter Götz
> Nix gegen die Anwendung selbst, die ist gut gemacht, sieht
> hübsch aus usw. (hab's gerade ausprobiert)
Ausprobiert mit einer soundfontfähigen Soundkarte wie
z.B. Creative x-fi?
Nur dann kommt der in clsSFMan.vb enthaltene Code
zur Ausführung.
> - aber was genau wäre jetzt mit VBclassic nicht
> realisierbar - bzw. (Deiner Meinung nach) "schwer
> umzusetzen"?
z.B. der Zugriff auf die in sfms32dll und/oder sfman32.dll
nur über eine Funktionstabelle erreichbaren Funktionen
(kein StdCall). Ich hätte dafür jetzt keine schnelle, einfache
VB6-Lösung.
Thorsten Albers
> Natürlich ist auch das möglich, aber eben mit
> erhöhtem Arbeitsaufwand, den irgendjemand (z.B. der
> Kunde) bezahlen muss.
Da es in jedem Projekt ohne Anpassung wiederverwendbarer Code ist, läßt
sich das ohne Probleme über die verschiedenen Kunden strecken.
> Nun haben wir ja schon eine ganze Reihe von .net-Versionen
> hinter uns, aber .Dock und .Anchor sind immer noch vorhanden
> und werden es ganz sicher auch in künftigen Versionen sein.
Man wird sehen. Bei diesen Methoden kann man das vermutlich auch noch mit
einer gewissen Sicherheit sagen, aber das gilt mit Sicherheit nicht für
alles ge-.NET-te.
Interessant wird es bei dieser völligen .NET-Framework-Abhängigkeit
übrigens mit der Portierung auf andere Platformen: Man muß sich schon
darauf verlassen, daß das gesamte Framework portiert wird, was dann aber
wirklich 1:1 nur der Hersteller kann.
Mit dem eigenen VB-Code habe ich derartige Probleme nicht, da ich ihn
selbst anpassen bzw. portieren kann.
> Da habe ich dann schon deutlich grössere Probleme mit
> Controls für VBclassic von Drittherstellern, bei denen es
> schon erheblich mehr als einmal vorkam, dass solche
> Hersteller plötzlich vom Markt verschwunden waren.
Ich wüßte nicht, was einem bei MS die Gewißheit geben könnte, daß
irgendetwas nicht von heute auf morgen gestrichen wird. Ein Beispiel dafür
sind diese Sch...-Ribbons von Office 2007 gegenüber den 'normalen'
Symbolleisten in Office 2003, die ein komplett neues Vorgehen sowohl bei
der Handhabung und Programmierung erfordern.
> Eben schon ein Problem. Solche Bibliotheken fallen nicht vom
> Himmel. Sie müssen geplant, geschrieben und gründlichst
> ausgetestet werden. Das kostet Zeit und Geld und beeinflusst
> somit den Preis einer dem Kunden anzubietenden Software.
Natürlich ist das eine wirtschaftliche Abwägung, ob man die Zeit und das
Geld investiert, dabei aber flexibel und unabhängig bleibt, oder ob man das
Geld spart, sich dafür aber in die völlig Abhängigkeit von MS, seinem
Betriebssystem und dem Framework begibt. Meinem Eindruck nach beantwortet
längst nicht jedes Software-Unternehmen diese Frage zugunsten von .NET -
von der Software, die ich oder meine Bekannten so einsetzen, basiert
herzlich wenig auf dem .NET-Framework. Der Vorteil der Zeit- und
Geldersparnis scheint für viele doch nicht so vorteilhaft zu sein.
> Dann hast Du Dir den Code dieses Programmes aber offensichtlich
> noch nicht so ganz genau angesehen und ich würde schon ganz
> gerne sehen, wie und mit welchem Aufwand Du den Zugriff auf
> das SDK von Creative realisieren würdest.
----
> z.B. der Zugriff auf die in sfms32dll und/oder sfman32.dll
> nur über eine Funktionstabelle erreichbaren Funktionen
> (kein StdCall). Ich hätte dafür jetzt keine schnelle, einfache
> VB6-Lösung.
Natürlich kann ich das mit VB 6 und externen Komponenten realisieren - Du
hast offenbar den Zusatz überlesen: "... was nicht heißen soll, daß jede
dieser Bibliotheken in VB geschrieben werden könnte - genau wie bei .NET".
--
Thorsten Albers
> > Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise
> > die Abwärtskompatibilität sehr hoch" - ....
> Hier lobst Du, dass Microsoft die Abwärtskompatibilität sehr
> hoch hält
Entschuldige 'mal - das ist ein Zitat von Frank!
Thorsten Albers
<01cb9c5e$9fd36000$8901a8c0@thalk8s8x>...
> Entschuldige 'mal - das ist ein Zitat von Frank!
Bzw. Wolf...
Schmidt
> Ich höre wohl auch, dass immer wieder von browserbasierten
> Anwendungen gesprochen wird, nur sehe ich bei meinen
> Kunden (grosse Industrieunternehmen der Elektro-/Elektronik-
> branche und div. Behörden) so gut wie keine.
Ja, in der (Industrie-)Ecke drehen die Mühlen halt etwas
langsamer - heisst aber nicht, dass Prozess-Visualisierung
oder ein GUI für eine Maschinensteuerung nicht auch
in einem Browser gehostet werden könnte (entweder
lokal - oder auch "serverseitig zentral" - die Messwerte
kommen heutzutage ohnehin oft an zentralen Punkten an -
über welche "Busse" auch immer - und Ethernet ist
jedenfalls kein Fremdwort in der Industrie.
Was bisher (auf breiter Front) fehlte, war im Wesentlichen
*Performance* im Browser-GUI bzw. -DOM.
Das Problem ist mittlerweile aus der Welt - fehlen nur noch
(browserbasierte) RAD-IDEs ... und die werden IMO bald
folgen - Flash/Silverlight waren bisher nur Workarounds,
FAT-Client ähnliche Performance und Programmierbarkeit
in die allgegenwärtigen Browser zu bringen - HTML5,
gekoppelt mit aktuellen Javascript-Tools bringt nun endlich
einen "breiter akzeptierten Standard" - schaun mer mal...
Und nein, ich sage nicht, dass die "klassische Desktop-App"
jetzt tot ist - sobald mit "externer Hardware" direkter
interagiert werden muss, haben "Browser-Sandboxen"
so ihre Probleme - es sei denn, man benutzt sie direkt
"als Control" - oder schreibt entsprechende Plugins, die
dann "seitwärts andocken".
Aber für die "typische Branchenlösung" (Datenbank+
DatenGUI+Druckfunktionen) ist eine Browser-Anwendung
heutzutage mit sehr guter Performance umsetzbar -
und mit den zu erwartenden neuen Browser-IDEs dann
auch "raddish" entwickelbar.
> > Und selbst wenn "neu zu schreibende App XY" wieder
> > ein FAT-Client werden soll (von mir aus auch in .NET),
> > dann ist doch die Frage, ob nicht z.B. das Auslassen des
> > Erwerbs von z.B. WinForms-KnowHow (wie z.B. in
> > Deinem MIDI-Client zu sehen) und das sofortige
> > Beginnen mit WPF nicht unter'm Strich effizienter wäre.
>
> Was meinst Du mit "Auslassen des Erwerbs von
> z.B. WinForms-KnowHow"?
Ich bezog mich auf Deinen "Vorwurf", dass man nicht schon
vor 10 Jahren auf .NET umgestiegen ist.
Das, wofür Du in den letzten 10 Jahren eine Menge Zeit
(und somit Geld) investiert hast (Erlernen von WinForms z.B.),
... also dieses "tote .NET-Gleis" kann sich ein heutzutage
neu Einsteigender doch gleich schenken.
Ergo hätte (verglichen mit Dir) eine "erst in nächster Zeit
von VB6 zu .NET" wechselnde Firma Geld gespart,
die letzten Jahre also "in Summe effizienter" zugebracht
(betriebswirtschaftlich gesehen) also "alles richtig
gemacht".
> > Genauso gut kann man aber auch Python in Verbindung
> > mit QT oder GTK hernehmen und ansprechende (und
> > plattformunabhängige) Desktop-GUIs damit bauen.
>
> Kommt bei meinen Kunden nicht vor.
Du stellst jetzt auf "plattform(un)abhängig" ab (also das
Betriebssystem) - aber die oben erwähnten Alternativen
funktionieren halt auch unter Windows sehr gut - und
bieten neben Plattformunabhängigkeit auch z.B.
"Hersteller-Unabhängigkeit" - und somit ein ziemlich stabiles
(von einer Community getragenes, nicht alle Nase lang
"am Entwickler vorbei" umgeworfenes) Komponenten-API -
investiertes KnowHow, investierter Code sind somit etwas
"langzeitstabiler nutzbar" als derzeit bei MS üblich.
> > Warum diese "wir wollen weg von VB6"-Diskussion immer
> > automatisch in die "man nimmt natürlich VB.NET, bist eh'
> > spät dran"-Richtung läuft, versteh ich nicht ganz.
>
> Ich sage keineswegs, dass der Nachfolger von VB6
> unbeding VB.net sein müsste.
> Wenn jemand sagt, er müsse einen Umstieg mindestens 2
> bis 3 Jahre vorausplanen, dann denke ich aber schon, dass
> er mit einem Umstieg auf .net eben um 10 Jahr zu spät
> daran ist.
Argumente dagegen habe ich ja gerade genannt - dennoch
sollte man sich jetzt "so langsam kümmern und was in's Auge
fassen" - aber Grund zur Hektik - oder für Vorwürfe a la
"ihr seid zu spät dran" gibt es IMO noch keine.
> > Ein Neuschreiben auf Basis neu zu lernender Begleit-
> > Bibliotheken! (dafür geht doch die meiste Zeit drauf, und
> > nicht für die Sprachsyntax) steht doch ohnehin an, da
> > 1:1 (wie Du selbst sagst) nicht geht, bzw. empfehlenswert ist.
>
> Richtig, 1:1 macht in den seltensten Fällen Sinn, da es eben
> kaum zu optimalen Lösungen führt. Natürlich muss man
> für einen Umstieg nach .net eine Vielzahl neuer Bibliotheken
> kennenlernen, eben wie für jede andere Programmierumgebung
> auch. Das alleine spricht aber doch weder für oder gegen die
> eine noch die andere Sprache.
Eben, eben.
> Wenn ich aber ausschliesslich SW für Windows entwickle,
> weil Kunden das so wünschen, dann macht es schon Sinn
> ein hierzu passendes, vom Betriebssystemhersteller kommendes
> Programmierwerkzeug zu nutzen.
Wie VB6 z.B.?
Oder wie WinForms (jetzt WPF)?
Oder wie Remoting (jetzt WCF)?
Also bei den Programmierwerkzeugen zumindest, hat MS in
den letzten Jahren hinsichtlich "Langzeit-Stabilität und Investitions-
sicherheit von Lernkurven bzw. Know-How" einen ziemlichen
Tanz aufgeführt (beginnend mit der "VB6-Story").
Vielleicht kriegen sie sich ja jetzt endlich mal wieder ein -
aber auf Basis eines über Jahre (Jahrzehnte) garantiert stabilen
APIs - lassen sich halt die so beworbenen "neuen Technologien"
relativ schlecht verkaufen.
> Die Entscheidung ob Windows oder ein anderes
> Betriebssystem ist bei allen meinen Kunden längst gefallen,
> ich bin also gar nicht in der Situation, darüber zu diskutieren.
Wie gesagt, es gibt genügend Alternativen die *auch* auf
der Win-Plattform hervorragend funktionieren - und dass
Kunden (auch - oder gerade in der Industrie) sagen:
"heute Windows-OS, immer Windows-OS", wage ich
zu bezweifeln. Gerade in den Technik-Abteilungen
(auf der "Management-Ebene" eher weniger) steht man
den "offenen Alternativen" meist wohlwollend gegenüber,
so jedenfalls meine Erfahrungen.
> > Und ob man diese Zeit nun in Python + neu zu lernende QT-
> > Klassen investiert, oder in VB.NET + neu zu lernende
> > "WPF/WCF-Klassen", wird sich am Ende nicht viel geben -
>
> s.oben:
> Meine Kunden bekommen die von mir entwickelte SW inkl.
> Sourcecode und hier wird eben VB.net oder teilweise auch
> C++ gewünscht.
Letzteres ist schon eher das, was ich aus der Industrie kenne
(dann mehr aus der "embedded Ecke") - C/C++ basierte
Sourcen - möglichst gepaart mit einem GUI-Framework,
welches nicht nur auf Windows läuft.
Sowas ist dann relativ leicht portier- bzw. "rekompilierbar"
auch mit alternativen (nicht MS-) C/C++ Build-Tools
(und dann für unterschiedlichste Prozessor-Architekturen).
> > während die andere Variante wesentlich krisenfester ist
> > (da von Communities getragene, offene Quellen existieren -
> > sowohl für die Sprache, als auch die verwendeten Frame-
> > work-libs).
>
> Auch hier ist meine Erfahrung eine andere.
> Meine Kunden planen ihre Systeme über Zeiträume von
> 5 Jahren und auch mehr. So war bei diesen nun lange Zeit
> Win XP das Betriebssystem für alle Büro- und Fertigungs-
> arbeitsplätze. Vista wurde übersprungen und ist nun
> gerade der Umstieg nach Win7 weitgehend abgeschlossen,
> aber eben keiner nach Linux oder sonstige Unix-Abkömmlinge.
Wie gesagt, die (potentielle) Betriebssystem-Unabhängigkeit
beim Arbeiten mit Alternativen ist nur *ein* Punkt auf der
Liste von Vorteilen - gibt auch gewisse Nachteile, wie
z.B. "sieht nicht so ganz 'native' aus, das GUI" - oder ein
gewisser Overhead aus den Ladevorgängen der OpenSource-
Framework-libs, die halt nicht bereits "in System32 sitzen
und vom OS schon beim Start geladen wurden" - aber
ersteres Problem ist bei z.B. bei einem aktuellen QT oder
auch wxWidgets nicht mehr existent - und letzteres "wächst
sich so langsam aus", da die Hardware immer flotter wird
und die Arbeitsspeicher-Resourcen heutzutage nicht mehr
so das Problem darstellen.
Naja - der Optionen gibt es jedenfalls Viele - und ich
rechne wie gesagt auch noch mit ein paar "sehr interessanten
neuen Ansätzen" in der "Browser-App-Arena", sobald sich die
neuen HTML5-getriebenen Engines dann "flächendeckend
manifestiert haben". ;-)
Olaf
Georg Jung
>>> die Abwärtskompatibilität sehr hoch" - ....
>> Hier lobst Du, dass Microsoft die Abwärtskompatibilität sehr
>> hoch hält
>
> Entschuldige 'mal - das ist ein Zitat von Frank!
>
LOL! Ich hab echt selten so gelacht! :-)
Dieter Strassner
[...]
> Ich höre wohl auch, dass immer wieder von browserbasierten
> Anwendungen gesprochen wird, nur sehe ich bei meinen
> Kunden (grosse Industrieunternehmen der Elektro-/Elektronik-
> branche und div. Behörden) so gut wie keine.
[...]
es tut ja nun auch "keinem Schlag" und alles ist umgestellt. Es kommt
schleichend, in kleinen Portionen.
Eine "Portion" ist mir gerade heute "über den Weg gelaufen":
http://www.inxmail.de/de/referenzen/referenzen.php?navanchor=1010045
...frag doch mal bei deinen jetztigen Kunden herum. Sicherlich ist der eine
oder andere dabei
der schon solche / ähnliche Dienste nutzt.
BTW: Und Cloud-Applikationen zu benutzen ist ein "alter Hut". Macht jeder
von uns schon seit Jahren sobald er die Suchmaschine seines Vertrauens
bemüht. Der Umschwung in die bezahlte Leistung und das anvertrauen von
Personendaten ist die große noch zu meistender Hürde. Aber auch da gibt es
im Ami-Land Vorreiter wie z.B. www.SalesForce.com die schon seit über 10
Jahren davon leben...
[...]
> Richtig, 1:1 macht in den seltensten Fällen Sinn, da es eben
> kaum zu optimalen Lösungen führt. Natürlich muss man
> für einen Umstieg nach .net eine Vielzahl neuer Bibliotheken
> kennenlernen, eben wie für jede andere Programmierumgebung
> auch. Das alleine spricht aber doch weder für oder gegen die
> eine noch die andere Sprache. Wenn ich aber ausschliesslich
> SW für Windows entwickle, weil Kunden das so wünschen,
> dann macht es schon Sinn ein hierzu passendes, vom
> Betriebssystemhersteller kommendes Programmierwerkzeug
> zu nutzen. Die Entscheidung ob Windows oder ein anderes
> Betriebssystem ist bei allen meinen Kunden längst gefallen,
> ich bin also gar nicht in der Situation, darüber zu diskutieren.
ACK!
Den Entwicklungsprozess weg vom "1:1 umsetzen" (von VB6 auf VB.NET) mußte
ich auch durchlaufen.
Mit "1:1" verbaut man/frau sich eine Menge Möglichkeiten/Chancen.
Meine Erkenntnis daraus:
Wenn schon nochmal programmieren, dann nur so das es auch einen
erheblichen/erkennbaren Mehrnutzen für die Kundschaft bringt. Dann läßt sich
das Umstellungsprojekt auch finanzieren.
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Lothar Geyer
Am 15.12.2010 16:07, schrieb Dieter Strassner:
> ...
> Aber auch da gibt es im Ami-Land Vorreiter wie z.B. www.SalesForce.com
> die schon seit über 10 Jahren davon leben...
... und gerade denen wurde ihre Datenbank im Internet gehackt. Peinlich,
peinlich...
Lothar Geyer
Dieter Strassner
>> Aber auch da gibt es im Ami-Land Vorreiter wie z.B.
>> www.SalesForce.com die schon seit �ber 10 Jahren davon leben...
>
> ... und gerade denen wurde ihre Datenbank im Internet gehackt.
> Peinlich, peinlich...
Allerdings!
So darf einem KMU auf keinen Fall passieren!
--
Viele Gr��e - Dieter
Schmidt
> Hallo Olaf,
>
> > Nix gegen die Anwendung selbst, die ist gut gemacht, sieht
> > hübsch aus usw. (hab's gerade ausprobiert)
>
> Ausprobiert mit einer soundfontfähigen Soundkarte wie
> z.B. Creative x-fi?
> Nur dann kommt der in clsSFMan.vb enthaltene Code
> zur Ausführung.
>
> > - aber was genau wäre jetzt mit VBclassic nicht
> > realisierbar - bzw. (Deiner Meinung nach) "schwer
> > umzusetzen"?
>
> z.B. der Zugriff auf die in sfms32dll und/oder sfman32.dll
> nur über eine Funktionstabelle erreichbaren Funktionen
> (kein StdCall). Ich hätte dafür jetzt keine schnelle, einfache
> VB6-Lösung.
Heisst aber nicht, dass es diese nicht gibt... ;-)
Für CDecl-Aufrufe (per Function-Pointer) gibt es
fix und fertige VB6-Klassenmodule - für Deine ca. 20
Funktionsaddressen "hinter dem SFMan-VTable-Pointer"
schreibt man sich dann einmalig einen kleinen Funktions-
Wrapper auf Basis entsprechender Public-Functions,
und ruft innerhalb dieser Routinen die Funktions-Zeiger
per cDecl-HelferKlasse inkl. der nötigen Parameterbesetzung
direkt auf.
Wem das direkte Arbeiten mit CDecl-ASM-Code in VB6
zu sehr nach Hack riecht, der kann sich (ohne auf ASM
ausweichen zu müssen) eine CDecl-to-StdCall-HelferDll
auch in Free- oder PowerBasic schreiben (oder gleich in C).
Olaf
Peter Fleischer
Ahmed Martens
Super, dass ist doch schon einmal ein Anfang. Jetzt kann ich an den
gordischen Knoten solange zupfen, bis ich den gelöst habe.
Vielen Dank noch einmal.
Gruß Ahmed
Peter Götz
>> Ich höre wohl auch, dass immer wieder von browserbasierten
>> Anwendungen gesprochen wird, nur sehe ich bei meinen
>> Kunden (grosse Industrieunternehmen der Elektro-/Elektronik-
>> branche und div. Behörden) so gut wie keine.
>
> Ja, in der (Industrie-)Ecke drehen die Mühlen halt etwas
> langsamer - heisst aber nicht, dass Prozess-Visualisierung
> oder ein GUI für eine Maschinensteuerung nicht auch
> in einem Browser gehostet werden könnte (entweder
> lokal - oder auch "serverseitig zentral" - die Messwerte
> kommen heutzutage ohnehin oft an zentralen Punkten an -
> über welche "Busse" auch immer - und Ethernet ist
> jedenfalls kein Fremdwort in der Industrie.
Ich sage doch gar nicht, dass auch im Industriebereich
browserbasierte Anwendungen möglich wären, sie sind
es aber eben in weiten Teilen nicht. Das wurde und wird
von den Verantwortlichen in solchen Grossunternehmen
entschieden und steht damit automatisch im Pflichtenheft
für neu zu erstellende Projekte.
> Was bisher (auf breiter Front) fehlte, war im Wesentlichen
> *Performance* im Browser-GUI bzw. -DOM.
> Das Problem ist mittlerweile aus der Welt - fehlen nur noch
> (browserbasierte) RAD-IDEs ... und die werden IMO bald
> folgen - Flash/Silverlight waren bisher nur Workarounds,
> FAT-Client ähnliche Performance und Programmierbarkeit
> in die allgegenwärtigen Browser zu bringen - HTML5,
> gekoppelt mit aktuellen Javascript-Tools bringt nun endlich
> einen "breiter akzeptierten Standard" - schaun mer mal...
Ja, das ist mir alles auch sehr wohl bekannt, aber eben für
viele grosse Industrieunternehmen schlicht und einfach kein
Thema. Und wenn ich ehrlich sein soll, meine ich selbst
auch nicht, nur weil gerade mal alles von browserbasierten
Lösungen schwärmt, dies als alleinseligmachende Arbeits-
weise ansehen zu müssen.
> Und nein, ich sage nicht, dass die "klassische Desktop-App"
> jetzt tot ist
Genau das glaube ich auch nicht, obwohl sogar MS
das gerne hätte.
> - sobald mit "externer Hardware" direkter
> interagiert werden muss, haben "Browser-Sandboxen"
> so ihre Probleme - es sei denn, man benutzt sie direkt
> "als Control" - oder schreibt entsprechende Plugins, die
> dann "seitwärts andocken".
Zumindest in meinem Wirkungsbereich haben sich klassische
Desktopanwendungen bewährt und es lassen sich damit
die Kundenanforderungen besser und umfassender erfüllen.
Da die Entscheidung aber von Kundenseite her ohnehin
gegen browserbasierte Anwendungen gefallen ist, muss ich
darüber auch gar nicht lange diskutieren.
> Aber für die "typische Branchenlösung" (Datenbank+
> DatenGUI+Druckfunktionen) ist eine Browser-Anwendung
> heutzutage mit sehr guter Performance umsetzbar -
> und mit den zu erwartenden neuen Browser-IDEs dann
> auch "raddish" entwickelbar.
Anwendungen zur Überwachung und Steuerung von Fertigungs-
abläufen passen vielleicht doch nicht ganz in dieses einfache
"typische" Schema.
>> > Und selbst wenn "neu zu schreibende App XY" wieder
>> > ein FAT-Client werden soll (von mir aus auch in .NET),
>> > dann ist doch die Frage, ob nicht z.B. das Auslassen des
>> > Erwerbs von z.B. WinForms-KnowHow (wie z.B. in
>> > Deinem MIDI-Client zu sehen) und das sofortige
>> > Beginnen mit WPF nicht unter'm Strich effizienter wäre.
>>
>> Was meinst Du mit "Auslassen des Erwerbs von
>> z.B. WinForms-KnowHow"?
>
> Ich bezog mich auf Deinen "Vorwurf", dass man nicht schon
> vor 10 Jahren auf .NET umgestiegen ist.
Vorwurf ist vielleicht nicht der passende Ausdruck. Aber wenn
jemand sagt er müsse einen Umstieg mindestens 2 bis 3 Jahre
vorausplanen, dann kann ich eben nur feststellen, dass ein
Umstieg von VB6 nach VB6 zum heutigen Zeitpunkt um 10
Jahre zu spät kommt.
> Das, wofür Du in den letzten 10 Jahren eine Menge Zeit
> (und somit Geld) investiert hast (Erlernen von WinForms z.B.),
Ich habe nicht nur Zeit und Geld investiert, sondern eben
damit auch Geld verdient.
> ... also dieses "tote .NET-Gleis" kann sich ein heutzutage
> neu Einsteigender doch gleich schenken.
Ich sehe, wie schon mehrfach erwähnt, in meinem Umfeld
keineswegs ein "totes .net-Gleis" sondern eben ein sehr
lebendiges.
> Ergo hätte (verglichen mit Dir) eine "erst in nächster Zeit
> von VB6 zu .NET" wechselnde Firma Geld gespart,
> die letzten Jahre also "in Summe effizienter" zugebracht
> (betriebswirtschaftlich gesehen) also "alles richtig
> gemacht".
Diese Logik verstehe ich nicht so recht.
Ich habe eben nicht erst 10 Jahre gewartet, sondern mich
rechtzeitig auf ein neues Programmierwerkzeug eingestellt
und damit in den vergangenen Jahren sehr effizient gearbeitet
und eben damit Geld verdient.
>> > Genauso gut kann man aber auch Python in Verbindung
>> > mit QT oder GTK hernehmen und ansprechende (und
>> > plattformunabhängige) Desktop-GUIs damit bauen.
>>
>> Kommt bei meinen Kunden nicht vor.
> Du stellst jetzt auf "plattform(un)abhängig" ab (also das
> Betriebssystem) -
Plattformunabhängigkeit ist auch so ein Schlagwort, das
man besser nicht eingehender hinterfragen darf. Ich habe
jedenfalls bisher Plattformunabhängigkeit ohne jegliche
Einschränkung noch nicht erlebt und da meine Anwendungen
ohnehin ausschliesslich für Windows konzipiert sind, ist
dies auch kein Thema für mich.
> aber die oben erwähnten Alternativen
> funktionieren halt auch unter Windows sehr gut
Das bestreite ich doch gar nicht.
Aber mit dem .net-Framework erstellte Anwendungen funktionieren
eben auch sehr gut und meine Erfahrung der letzten Jahre ist, dass
ich damit bei Erstellung, Wartung, Pflege und evtl. Erweiterungen
solcher .net-Anwendungen gegenüber meinen früheren VBclassic
Anwendungen viel Zeit spare.
> - und bieten neben Plattformunabhängigkeit
Was ich vom Schlagwort Plattformunabhängigkeit halte,
habe ich ja schon erwähnt.
> auch z.B. "Hersteller-Unabhängigkeit" -
Hersteller-Unabhängigkeit, ich nehme an Du spielst auf
Linux usw. an, heisst aber auch, dass ich keinen
gewährleistungspflichtigen Lieferanten habe. Das
kann bei Fehlern in einem Betriebssystem recht
unangenehm werden und auch sehr schnell unerwartete
Kosten verursachen.
> und somit ein ziemlich stabiles (von einer Community
> getragenes, nicht alle Nase lang "am Entwickler vorbei"
> umgeworfenes) Komponenten-API - investiertes KnowHow,
> investierter Code sind somit etwas
> "langzeitstabiler nutzbar" als derzeit bei MS üblich.
Ich kann nun nicht behaupten, dass meine Anwendungen über
viele Jahre hinweg auf XP-Systemen auffallend unstabil gelaufen
wären und die .net-basierten Anwendungen tun ihren Dienst nun
auch schon eine Reihe von Jahren klaglos und zur vollen
Zufriedenheit.
>> > Warum diese "wir wollen weg von VB6"-Diskussion immer
>> > automatisch in die "man nimmt natürlich VB.NET, bist eh'
>> > spät dran"-Richtung läuft, versteh ich nicht ganz.
>>
>> Ich sage keineswegs, dass der Nachfolger von VB6
>> unbeding VB.net sein müsste.
>> Wenn jemand sagt, er müsse einen Umstieg mindestens 2
>> bis 3 Jahre vorausplanen, dann denke ich aber schon, dass
>> er mit einem Umstieg auf .net eben um 10 Jahr zu spät
>> daran ist.
>
> Argumente dagegen habe ich ja gerade genannt - dennoch
> sollte man sich jetzt "so langsam kümmern und was in's Auge
> fassen" - aber Grund zur Hektik - oder für Vorwürfe a la
> "ihr seid zu spät dran" gibt es IMO noch keine.
Im Ursprungsposting wurde doch unmissverständlich ein
Umstieg von VB6 nach VB.net genannt. Eben diesen
Umstieg konnte man bereits vor mehr als 10 Jahren in
Angriff nehmen und ich sehe nun wirklich nicht, dass man
sich über Zeitdruck beklagen könnte, wenn man diesen
Umstieg erst heute, also 10 Jahre zu spät ins Auge fasst.
>
>> > Ein Neuschreiben auf Basis neu zu lernender Begleit-
>> > Bibliotheken! (dafür geht doch die meiste Zeit drauf, und
>> > nicht für die Sprachsyntax) steht doch ohnehin an, da
>> > 1:1 (wie Du selbst sagst) nicht geht, bzw. empfehlenswert ist.
>>
>> Richtig, 1:1 macht in den seltensten Fällen Sinn, da es eben
>> kaum zu optimalen Lösungen führt. Natürlich muss man
>> für einen Umstieg nach .net eine Vielzahl neuer Bibliotheken
>> kennenlernen, eben wie für jede andere Programmierumgebung
>> auch. Das alleine spricht aber doch weder für oder gegen die
>> eine noch die andere Sprache.
> Eben, eben.
Nicht "eben, eben".
Es spricht eben auch nicht gegen .net.
>> Wenn ich aber ausschliesslich SW für Windows entwickle,
>> weil Kunden das so wünschen, dann macht es schon Sinn
>> ein hierzu passendes, vom Betriebssystemhersteller kommendes
>> Programmierwerkzeug zu nutzen.
> Wie VB6 z.B.?
Meine Kunden wollen aber keinen VB6 Sourcecode sondern
eben VB.net und/oder C++.
Und ehrlich gesagt käme ich auch nicht auf die Idee, heute
noch eine neue Anwendung in VB6 zu schreiben. Ich betone
ausdrücklich "neue Anwendungen". Bestehende VB6 Anwendungen
habe auch ich noch zu betreuen und werde das wohl auch noch
eine ganze Weile tun.
> Oder wie WinForms (jetzt WPF)?
> Oder wie Remoting (jetzt WCF)?
> Also bei den Programmierwerkzeugen zumindest, hat MS in
> den letzten Jahren hinsichtlich "Langzeit-Stabilität und Investitions-
> sicherheit von Lernkurven bzw. Know-How" einen ziemlichen
> Tanz aufgeführt (beginnend mit der "VB6-Story").
>
> Vielleicht kriegen sie sich ja jetzt endlich mal wieder ein -
> aber auf Basis eines über Jahre (Jahrzehnte) garantiert stabilen
> APIs - lassen sich halt die so beworbenen "neuen Technologien"
> relativ schlecht verkaufen.
Irgendwie höre ich da schon immer ein wenig generelle und
grundsätzliche Ablehung von allem was von MS kommt heraus.
Ich habe zu Grossrechnerzeiten noch den Inkompatibilitätskrieg
der damals führenden Hersteller IBM, Siemens, HP usw.
miterlebt, verglichen damit erscheinen mir Windows und die
von MS dazu bereitgestellten Programmierwerkzeuge doch
als ein sehr angenehm ruhiges Wasser.
>> Die Entscheidung ob Windows oder ein anderes
>> Betriebssystem ist bei allen meinen Kunden längst gefallen,
>> ich bin also gar nicht in der Situation, darüber zu diskutieren.
> Wie gesagt, es gibt genügend Alternativen die *auch* auf
> der Win-Plattform hervorragend funktionieren - und dass
> Kunden (auch - oder gerade in der Industrie) sagen:
> "heute Windows-OS, immer Windows-OS", wage ich
> zu bezweifeln. Gerade in den Technik-Abteilungen
> (auf der "Management-Ebene" eher weniger) steht man
> den "offenen Alternativen" meist wohlwollend gegenüber,
> so jedenfalls meine Erfahrungen.
Ich bezweifle gar nicht, dass das Deine Erfahrung ist, meine
Erfahrung ist wie schon erwähnt eine genau entgegengesetzte,
was eigentlich nur zeigt, dass man solche Diskussionen
einfach nicht verallgemeinern sollt und auch nicht kann.
>> > Und ob man diese Zeit nun in Python + neu zu lernende QT-
>> > Klassen investiert, oder in VB.NET + neu zu lernende
>> > "WPF/WCF-Klassen", wird sich am Ende nicht viel geben -
>>
>> s.oben:
>> Meine Kunden bekommen die von mir entwickelte SW inkl.
>> Sourcecode und hier wird eben VB.net oder teilweise auch
>> C++ gewünscht.
> Letzteres ist schon eher das, was ich aus der Industrie kenne
> (dann mehr aus der "embedded Ecke") - C/C++ basierte
> Sourcen - möglichst gepaart mit einem GUI-Framework,
> welches nicht nur auf Windows läuft.
> Sowas ist dann relativ leicht portier- bzw. "rekompilierbar"
> auch mit alternativen (nicht MS-) C/C++ Build-Tools
> (und dann für unterschiedlichste Prozessor-Architekturen).
Da muss nichts rekompilierbar sein.
Meine Kunden bekommen ohnehin den kompletten Sourcecode,
weil das eben einfach so vertraglich festgelegt worden ist.
>> > während die andere Variante wesentlich krisenfester ist
>> > (da von Communities getragene, offene Quellen existieren -
>> > sowohl für die Sprache, als auch die verwendeten Frame-
>> > work-libs).
>>
>> Auch hier ist meine Erfahrung eine andere.
>> Meine Kunden planen ihre Systeme über Zeiträume von
>> 5 Jahren und auch mehr. So war bei diesen nun lange Zeit
>> Win XP das Betriebssystem für alle Büro- und Fertigungs-
>> arbeitsplätze. Vista wurde übersprungen und ist nun
>> gerade der Umstieg nach Win7 weitgehend abgeschlossen,
>> aber eben keiner nach Linux oder sonstige Unix-Abkömmlinge.
>
> Wie gesagt, die (potentielle) Betriebssystem-Unabhängigkeit
> beim Arbeiten mit Alternativen ist nur *ein* Punkt auf der
> Liste von Vorteilen -
Echte und wirklich uneingeschränkte Betriebssystem-Unabhängigkeit
gibt es eben nicht, solange nicht alle in Frage kommenden Systeme
in Umfang und Funktionalität völlig identische APIs zur Verfügung
stellen. Vieles lässt sich mit Frameworks ausbügeln, aber
es wird doch immer wieder die eine oder andere Einschränkung
geben.
> gibt auch gewisse Nachteile,
Einer der Nachteile ist bei OpenSource ist eben, dass man
keinen gewährleistungspflichtigen Hersteller/Ansprechpartner
hat. Im privaten Umfeld sicher kein sonderliches Problem, im
kommerziellen Bereich dagegen kann dies schon ein echtes
und leider zur unrechten Zeit auch ein kostenintensives
Problem werden.
> wie
> z.B. "sieht nicht so ganz 'native' aus, das GUI" - oder ein
> gewisser Overhead aus den Ladevorgängen der OpenSource-
> Framework-libs, die halt nicht bereits "in System32 sitzen
> und vom OS schon beim Start geladen wurden" - aber
> ersteres Problem ist bei z.B. bei einem aktuellen QT oder
> auch wxWidgets nicht mehr existent - und letzteres "wächst
> sich so langsam aus", da die Hardware immer flotter wird
> und die Arbeitsspeicher-Resourcen heutzutage nicht mehr
> so das Problem darstellen.
Ich kann keinem Kunden sagen, "na ja, die Anwendung läuft
jetzt noch ein wenig müde, aber mit einer künftigen schnelleren
und umfangreicheren Hardware wird es dann schon besser".
Ein solcher Kunde wäre vermutlich schnell nicht mehr mein
Kunde.
> Naja - der Optionen gibt es jedenfalls Viele - und ich
> rechne wie gesagt auch noch mit ein paar "sehr interessanten
> neuen Ansätzen" in der "Browser-App-Arena", sobald sich die
> neuen HTML5-getriebenen Engines dann "flächendeckend
> manifestiert haben". ;-)
Schaun ma mal... ;-)
Peter Fleischer
schön, dass es Dir hilft. Zu VB.NET nutze bitte aber die NG
de.comp.lang.misc bis die geplanten neuen NG's eingerichtet sind.
--
Viele Grüße
Peter
Peter Götz
> [...]
>> Ich höre wohl auch, dass immer wieder von browserbasierten
>> Anwendungen gesprochen wird, nur sehe ich bei meinen
>> Kunden (grosse Industrieunternehmen der Elektro-/Elektronik-
>> branche und div. Behörden) so gut wie keine.
> [...]
>
> es tut ja nun auch "keinem Schlag" und alles ist umgestellt. Es kommt
> schleichend, in kleinen Portionen.
Konnte ich bei meinen Kunden nicht feststellen.
Da liefen viele Jahre lang VBclassic-Anwendungen und
dann wurde beschlossen, ab sofort für Neuentwicklungen nur
noch VB.net und/oder C++.
> Eine "Portion" ist mir gerade heute "über den Weg gelaufen":
>
> http://www.inxmail.de/de/referenzen/referenzen.php?navanchor=1010045
>
> ...frag doch mal bei deinen jetztigen Kunden herum. Sicherlich ist der
> eine oder andere dabei
> der schon solche / ähnliche Dienste nutzt.
Nein, weder einer meiner Industriekunden und auch keiner
meiner Behördenkunden.
> BTW: Und Cloud-Applikationen zu benutzen ist ein "alter Hut".
Meiner Meinung nicht nur ein alter Hut, sondern viel Lärm um
nichts. In meinem Umfeld sehe ich nicht, dass jemand daran
grosses Interesse hätte.
... schnipp ...
Peter Götz
... schnipp ..
>> > - aber was genau wäre jetzt mit VBclassic nicht
>> > realisierbar - bzw. (Deiner Meinung nach) "schwer
>> > umzusetzen"?
>>
>> z.B. der Zugriff auf die in sfms32dll und/oder sfman32.dll
>> nur über eine Funktionstabelle erreichbaren Funktionen
>> (kein StdCall). Ich hätte dafür jetzt keine schnelle, einfache
>> VB6-Lösung.
>
> Heisst aber nicht, dass es diese nicht gibt... ;-)
Ich sage doch nicht dass es keine Lösung gibt, aber
eben keine schnelle und einfache.
> Für CDecl-Aufrufe (per Function-Pointer) gibt es
> fix und fertige VB6-Klassenmodule - für Deine ca. 20
> Funktionsaddressen "hinter dem SFMan-VTable-Pointer"
> schreibt man sich dann einmalig einen kleinen Funktions-
> Wrapper auf Basis entsprechender Public-Functions,
> und ruft innerhalb dieser Routinen die Funktions-Zeiger
> per cDecl-HelferKlasse inkl. der nötigen Parameterbesetzung
> direkt auf.
>
> Wem das direkte Arbeiten mit CDecl-ASM-Code in VB6
> zu sehr nach Hack riecht, der kann sich (ohne auf ASM
> ausweichen zu müssen) eine CDecl-to-StdCall-HelferDll
> auch in Free- oder PowerBasic schreiben (oder gleich in C).
Genau das meine ich, wenn ich sage "mir fällt jetzt dafür
keine schnelle, einfach VB6 Lösung ein". Eine .net-Lösung
dagegen ist ohne Zuhilfenahme von Free- oder PowerBasic
problemlos möglich.
Peter Götz
> Super, dass ist doch schon einmal ein Anfang. Jetzt kann
> ich an den gordischen Knoten solange zupfen, bis ich den
> gelöst habe.
Und wenn Du den gelöst hast, dann schau Dir vielleicht mal
www.gssg.de -> Visual Basic -> VB.net
-> DataTable / DataView
-> DataTable / DataView, RowState
an. Das wäre dann ein weiterführendes Beispiel passend zu
Peter Fleischers "Einführungscode", welches dann schon
Fehlerbehandlung, Überprüfung der eingegebenen Daten
usw. enthält. Der Code im Beispiel ist sehr ausführlich
kommentiert und sollte damit gut verständlich sein.
W. Wolf
[...]
>> Wem das direkte Arbeiten mit CDecl-ASM-Code in VB6
>> zu sehr nach Hack riecht, der kann sich (ohne auf ASM
>> ausweichen zu müssen) eine CDecl-to-StdCall-HelferDll
>> auch in Free- oder PowerBasic schreiben (oder gleich in C).
>
> Genau das meine ich, wenn ich sage "mir fällt jetzt dafür
> keine schnelle, einfach VB6 Lösung ein". Eine .net-Lösung
> dagegen ist ohne Zuhilfenahme von Free- oder PowerBasic
> problemlos möglich.
>
Dafür bekommt der Anwender für diese App ein
10K DLL-chen auf den Rechner und kein 60 MB Framework.
Schönen Gruß
W. Wolf
Frank Müller
Oliver Dietz wrote:
> Hallo Frank,
>
>> ich habe keinen Kunden der Aero usw. eingeschaltet
>> hat. Und schon gar nicht bei Kunden die eine VB6 Software
>> viele Jahre nutzen wo es solche Sachen noch gar nicht gab.
> Aero ist mittlerweile auf einem mittelklasse Büro-PC automatisch
> aktiviert. Inklusive 125% DPI-Schriftauflösung wenn das TFT groß
> genug ist.
Ja aber nur bis der Admin oder der User Aero deaktiviert hat.
Und selbst wenn das nicht der Fall ist, dann funktioniert ein
VB6 Programm trotzdem, halt ohne die entsprechenden Effekte.
Das mit der höheren DPI bzw. Schriftgröße ist bei meinen Programmen
übrigens kein Problem.
>>> Unter aktuellen Programmierumgebungen bekommt man die SDKs
>>> frei Haus mit Beispielcode ... unter VB6 ist viel Handarbeit
>>> angesagt.
>> SDKs gab es immer schon, sind auch in der MSDN integriert
>> schon seit was ich wann.
> ja klar. Die SDKs werden aber für .NET (oder C) geschrieben
> (Beispiele, Quellcodes, vorausgesetzte Hilfsfunktionen). Unter VB6
> kannst du die vielleicht verwenden ... aber unter .NET bist du
> schneller produktiv.
Das streite ich ja gar nicht ab dass heutige SDKs keine
VB6 Beispiele mehr enthalten. Und ja, bei Neuentwicklungen
ist man unter .NET schneller, es ging aber hier um schon vorhandene
evtl. große Programme die umgestellt werden sollen.
>>> Komponentenhersteller haben den VB6-Support auch mehr oder
>>> weniger aufgekündigt
>> Viele Hersteller von Komponenten haben aber auch
>> .NET Versionen im Programm.
> Die du unter VB6 nicht verwenden kannst?!
Da brauche ich die ja auch nicht. Wer Komponente
X verwendet hat in VB6 und auf .NET umsteigt
verwendet natürlich dann die entsprechend neue
Komponente nicht umgekehrt.
>> Wer will so etwas?
Aus sicht der Anwender?
> Wer will ein Mausrad?
> (das von VB6-Usercontrols nicht von Haus aus unterstützt wird)
Klar die wollen das aber das Mausrad gibt es nicht erst seit .NET
Das funktioniert in meinen VB6 Anwendungen auch hervorragend.
> Wer will 125% DPI Textauflösung (was Windows 7 manchmal automatisch
> einstellt).
Das wollen viele User, besonders welche die sehbehindert, Brillenträger
usw. sind. Aber auch das funktionierte in gewissen Grenzen schon
mit VB6 Programmen.
> Wer will fremde Webservices anbinden?
Kein Anwender, der weiß nicht mal was das ist.
> Wer will PNG-Dateien öffnen?
Viele, aber das ist nur dann ein Problem wenn du
eine Grafikanwendung schreibst. Öffnen kann der
User die png Dateien ja auch so.
> Wer will Try-Catch-Blöcke?
> Wer will Vererbung nutzen?
Kein Anwender, der weiß nicht mal was das ist.
Ok, ein Vater möchte sein Vermögen an seine Kinder
vererben, aber das hat nichts mit Programmierung zu tun.
> Wer will ...
Eben, die Wünsche sind vielfältig, Wünsche von
Kunden sollte man versuchen zu erfüllen.
> Nochmal: Es sind nur Beispiele die vielleicht in deinem konkreten
> Fall nicht von Bedeutung sind und es ist auch alles mit VB6 lösbar.
> Effizienter ist es aber unter .NET, weil dort nicht nur die
> Technologien von 1998 unterstützt werden (und der Rest selbst
> programmiert werden muss) ... und jedes Jahr kommt etwas mehr dazu,
> das unter VB6 mühsam und unter .NET easy ist ... wann die Vorteile
> überwiegen und das Support-Risiko zu groß wird muss jeder selbst
> entscheiden.
Ganz genau und deswegen halt der Unterschied zwischen einer
Neuentwicklung oder einer Portierung. Kommt halt immer auf
das Programm, die Kunden und die Zielgruppe der Anwender an.
> "Noch" gibt es eine "Just-Works"-Support-Zusage von MS ...
Eben und deswegen haben wir auch noch Zeit, wenn
auch nicht bis in alle Ewigkeit.
Gruß,
Frank
Frank Müller
Thorsten Albers wrote:
> Frank Müller <Frank....@t-online.de> schrieb im Beitrag
> <ie92dl$fhr$00$1...@news.t-online.com>...
>> Das ist zwar nicht direkt, aber indirekt schon vergleichbar.
> Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise die
> Abwärtskompatibilität sehr hoch" - da 16 Bit-Programme als Beispiel
> anzuführen, ist nicht sinnvoll, weil die 16 Bit-Kompatibilität seit
> Windows 95/NT 3.5 eigentlich mehr oder weniger die gleiche ist, und
> MS diese nicht jedes Mal an die neue Windows-Version anpassen muß.
Die 16 Bit Programme habe ich ja auch nicht eingeführt in
diese Diskussion. Und ja, warum sollte MS denn die Unterstützung
dafür heute noch anpassen? Es werden ja keine neuen 16 Bit
Programme mehr geschrieben die auf den Markt kommen.
Aber 32 Bit Programme werden heute noch massenhaft verwendet,
weiter entwickelt und auch neu geschrieben.
> 32
> Bit-Kompatibilität bestimmter Bereiche fortzuführen ist für MS
> wesentlich komplexer und keineswegs so sicher wie 16
> Bit-Kompatibilität. Solange neuere Windows-Versionen 16
> Bit-Kompatibilität mitbringen, ist es wahrscheinlicher,
> Kompatibilitätsprobleme mit einem 32 Bit-Programm denn mit einem 16
> Bit-Programm zu bekommen.
OK, dann sollte ich vielleicht doch noch meine Corel 3 CDs
aufbewahren und meine > 3 verschrotten?
Ich wollte eigentlich nur sagen, dass es immer eine Übergangsphase gibt
bzw. auch weiterhin geben muss. Wie auch immer und wie lange
die sein sollte oder sein wird.
Gruß,
Frank
Frank Müller
>> Mich wundert immer, daß die gläubigen .NET-Programmierer
>> noch nicht dazu übergegangen sind, ihre Programme mit
>> 'MS inside' oder 'pure MS' zu zertifizieren.
> Na ja, ich denke, diesen Vorwurf richtest Du bei mir
> an den falschen. Ich habe sogar noch einen Kunden
> der mit MS-Dos seine Sudkesselanlagen steuert und
> damit nach wie vor ein vorzügliches Bier braut. Es
> gibt für diesen Anwender nicht den geringsten Grund
> dies zu ändern und ich sehe das ganz genauso.
Genau das ist ja ein Paradebeispiel für einen Kunden
der mit seiner Software zufrieden ist, egal womit
sie erstellt worden ist.
Das Bier würde auch mit VB6, .NET oder XYZ
Software nicht besser oder schlechter werden.
Also warum sollte er wechseln?
Ich gehe mal davon aus, das der PC der die
Anlage steuert nicht noch ein 486er ist wo
die Festplatte kleiner ist als der heutige
Arbeitsspeicher.
Aber jetzt zum entscheidenden Thema:
Was machst du bei diesem Kunden wenn er einen
Änderungs- oder Erweiterungswunsch an seiner
DOS Software hat? Sagst du ihm dann, dass das nicht
geht, machst du ihm ein Angebot für eine .NET Version
oder sagst du "Sorry, da kann ich nicht helfen"?
Oder anders gefragt, was machst du wenn dein Kunde
eine neue Kesselanlage bekommt deren Schnittstelle
eine Änderung der DOS Software erforderlich macht?
Ich denke mal, dass du das auch realisieren kannst.
Der Punkt, dass sich der Kunde einen PC vom
Discounter kauft und an die Anlage anschließt,
sich dann wundert, dass das nicht funktioniert
scheidet aus, das wird bei gewerblichen Kunden
eher nicht der Fall sein.
Gruß,
Frank
Ahmed Martens
Gru� Ahmed
--
Antworten bitte nur in der Newsgroup.
Peter Götz
>> Na ja, ich denke, diesen Vorwurf richtest Du bei mir
>> an den falschen. Ich habe sogar noch einen Kunden
>> der mit MS-Dos seine Sudkesselanlagen steuert und
>> damit nach wie vor ein vorzügliches Bier braut. Es
>> gibt für diesen Anwender nicht den geringsten Grund
>> dies zu ändern und ich sehe das ganz genauso.
>
> Genau das ist ja ein Paradebeispiel für einen Kunden
> der mit seiner Software zufrieden ist, egal womit
> sie erstellt worden ist.
>
> Das Bier würde auch mit VB6, .NET oder XYZ
> Software nicht besser oder schlechter werden.
> Also warum sollte er wechseln?
Genau so isses.
> Ich gehe mal davon aus, das der PC der die
> Anlage steuert nicht noch ein 486er ist wo
> die Festplatte kleiner ist als der heutige
> Arbeitsspeicher.
Es ist tatsächlich noch ein echtes Museumsstück
von PC und es gibt dazu noch einige Reserve-PCs.
Falls mal einer ausfallen sollte, was bisher ganze
2 mal in Laufe der Jahre passiert ist, wird innerhalb
weniger Minuten ein solcher Reserve-PC angesteckt
und in wenigen Minuten läuft wieder alles.
> Aber jetzt zum entscheidenden Thema:
> Was machst du bei diesem Kunden wenn er einen
> Änderungs- oder Erweiterungswunsch an seiner
> DOS Software hat? Sagst du ihm dann, dass das nicht
> geht, machst du ihm ein Angebot für eine .NET Version
> oder sagst du "Sorry, da kann ich nicht helfen"?
Weder noch.
Ich werfe meinen für solche Fälle immer noch betriebsbereiten
QuickBasic Entwicklungsrechner an und baue die gewünschte
Änderung.
> Oder anders gefragt, was machst du wenn dein Kunde
> eine neue Kesselanlage bekommt deren Schnittstelle
> eine Änderung der DOS Software erforderlich macht?
In absehbarer Zeit ist das nicht zu erwarten. Solche Anlagen
sind sehr haltbar und werden nicht alle Nase lange ausgetauscht.
So wie sich die Rezepturen fürs Bierbrauen nur selten oder
gar nicht ändern, so ist das auch mit dem ganzen "Drum Herum".
> Ich denke mal, dass du das auch realisieren kannst.
Eine neue Anlage würde vermutlich ein anderes Bedienkonzept
erfordern und die Arbeitsabläufe würden sich vermutlich auch
von den jetzigen unterscheiden. Die Folge wäre sicher auch
eine neue, deutlich andere Software als die jetzige.
> Der Punkt, dass sich der Kunde einen PC vom
> Discounter kauft und an die Anlage anschließt,
> sich dann wundert, dass das nicht funktioniert
> scheidet aus, das wird bei gewerblichen Kunden
> eher nicht der Fall sein.
Da noch genügend Reserve-PCs vorhanden sind ist
in dieser Hinsicht erst mal kein Problem am Horizont
zu sehen.
Peter Götz
> Dafür bekommt der Anwender für diese App ein
> 10K DLL-chen auf den Rechner und kein 60 MB Framework.
Falsch!
Er bekommt die 10k-DLL und das 60MB-Framework hat
er bei den neueren Systemversionen ohnehin schon per
Default auf seinem Rechner.
Ich verstehe ehrlich gesagt diese ganze Diskussion nicht
so recht. Da wird auf eine neue Technologie (.net) eingeprügelt
mit dem vermeintlichen Argument, dass nicht sicher sei,
wie lange sie verfügbar sei oder gepflegt würde und gleichzeitig
eine alte (oder soll ich sagen veraltete?) Technologie mit
Klauen und Zähnen verteidigt obwohl für die genau das
Selbe gilt. Keiner weiss, wie lange VB6 unter künftigen
Systemversionen noch nutzbar ist.
Niemand kann ernsthaft bestreiten, dass man mit der neueren
Technologie .net effizienter arbeiten kann und nur damit die
Möglichkeit hat die neuen Funktionalitäten der jüngsten
Windows-Systeme voll zu nutzen. Ich habe mich deshalb
dafür entschieden, vorhandene ältere (VBclassic) Anwendungen
bis auf Weiteres, bzw. solange dafür Bedarf besteht, zu pflegen
und für neue Anwendungen eben die neue an Windows
angepasste Technologie .net zu nutzen. Ich denke mal, dass
das wohl schon ein "vernünftiger" Weg ist.
Peter Götz
>> > Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise
>> > die Abwärtskompatibilität sehr hoch" - ....
>> Hier lobst Du, dass Microsoft die Abwärtskompatibilität sehr
>> hoch hält
>
> Entschuldige 'mal - das ist ein Zitat von Frank!
Dann habe ich mich wohl vertan und ich bitte dies zu
entschuldigen.
Deine Argumentation an VB6 festhalten zu wollen und .net
abzulehnen, weil man nicht wisse, ob und wie lange darin
enthaltene Funktionalitäten verfügbar seien, ist mindestens
ebenso unlogisch. Keiner weiss, wie lange VB6 mit künftigen
Windows-Versionen noch nutzbar sein wird (tatsächlich gibt
es bei neueren Systemversionen schon Einschränkungen),
es darf aber zumindest vermutet werden, dass .net mindestens
ebenso lange oder eher länger nutzbar sein wird.
Ich kann mich immer nur wiederholen. Vorhandene VBclassic
Anwendungen mit VB6 pflegen solange der Bedarf dafür
besteht und neue Anwendungen mit .net entwickeln, scheint
mir ein sehr wohl vernünftiger Weg, der sich bei mir in der
täglichen Praxis bestens bewährt hat.
Peter Götz
>>> Wem das direkte Arbeiten mit CDecl-ASM-Code in VB6
>>> zu sehr nach Hack riecht, der kann sich (ohne auf ASM
>>> ausweichen zu müssen) eine CDecl-to-StdCall-HelferDll
>>> auch in Free- oder PowerBasic schreiben (oder gleich in C).
>>
>> Genau das meine ich, wenn ich sage "mir fällt jetzt dafür
>> keine schnelle, einfach VB6 Lösung ein". Eine .net-Lösung
>> dagegen ist ohne Zuhilfenahme von Free- oder PowerBasic
>> problemlos möglich.
>>
>
> Dafür bekommt der Anwender für diese App ein
> 10K DLL-chen auf den Rechner und kein 60 MB Framework.
Das .net Framework ist, wie schon erwähnt auf den aktuellen
Windows-Versionen schon vorhanden und meine mit
.net entwickelten Anwendungen brauchen, wenn sie nicht
z.B. mehrsprachig ausgelegt sind,weder zusätzliche DLLs
noch eine Registrierung. Die entsprechende *.exe wird einfach
per XCopy auf den Zielrechner gebracht oder noch einfacher
direkt von einem USB-Stick aus gestartet.
W. Wolf
> Windows-Versionen schon vorhanden und meine mit
> .net entwickelten Anwendungen brauchen, wenn sie nicht
> z.B. mehrsprachig ausgelegt sind,weder zusätzliche DLLs
> noch eine Registrierung. Die entsprechende *.exe wird einfach
> per XCopy auf den Zielrechner gebracht oder noch einfacher
> direkt von einem USB-Stick aus gestartet.
>
Da mußt Du schon ganz genau präzisieren, was eine
aktuelle Windows-Version ist (aktuell <> neu).
Im Business Bereich kann (konnte ich zumindest bis
gestern) noch Rechner mit vorinstalliertem XP kaufen
und in meinem Umfeld ist das sogar die Regel. Große
Unternehmen wie einer meiner Aufraggeber haben sogar
Abkommen mit MS, dass XP noch lange genutzt und auf neuen
Rechner installiert werden kann. Hier handelt es sich
unter anderen um spezielle Industrie-PCs. Der Witz dabei
ist, dass die Produkt-Techniker, Programmierer und sonstige
Beteiligte vergleichbare PCs unterm Tisch haben, weil sie
so näher am Produkt sind.
Ein aktuelles Framework 4 ist ganz sicher nicht immer
vorhanden. Nun könntest Du ja auch gegen das 3.5-er
oder älter programmieren um die Wahrscheinlichkeit
der Framework-Existenz zu erhöhen. Dann machst Du
aber das gleiche wie ich, wenn ich gegen die VB-Runtime
programmiere. An die Verbreitung der VB-Runtime kommst
Du dennoch nicht heran.
Schönen Gruß
W. Wolf
W. Wolf
[...]
>
> Ich verstehe ehrlich gesagt diese ganze Diskussion nicht
> mit dem vermeintlichen Argument, dass nicht sicher sei,
> eine alte (oder soll ich sagen veraltete?) Technologie mit
> Selbe gilt. Keiner weiss, wie lange VB6 unter k�nftigen
> Systemversionen noch nutzbar ist.
>
[...]
Nein, ich verstehe Dich nicht! Ich habe Dich bereits
auf das Thema dieser NG hingewiesen. Dass Du hier
wieder den uralten Regentanz um die Vorteile von .net
vorf�hrst, ist �tzend. Du bist ja nun wirklich lange
genug dabei um zu wissen dass Net-Werbung hier verp�nt
ist, kannst es aber pardu nicht lassen.
Sch�nen Gru�
W. Wolf
Peter G�tz
> Nein, ich verstehe Dich nicht! Ich habe Dich bereits
> auf das Thema dieser NG hingewiesen. Dass Du hier
> wieder den uralten Regentanz um die Vorteile von .net
> vorf�hrst, ist �tzend. Du bist ja nun wirklich lange
> genug dabei um zu wissen dass Net-Werbung hier verp�nt
> ist, kannst es aber pardu nicht lassen.
Ein wenig am�siert bin ich aber nun schon, von Deiner
Antwort.
Die urspr�ngliche Frage in dieser Diskussion war doch,
ob jemand Erfahrung mit dem Umstieg von VB6 nach
VB.,net habe, was es dabei zu beachten g�be, welche
Schwierigkeiten dabei auftreten k�nnten usw.
Dass in dieser Frage, die nicht ich gestellt habe, das
Wort "VB.net" vorkommt, scheint bei Dir schon eine
heftige Abwehrhaltung auszul�sen.
Ich habe nichts weiter gemacht, als meine Erfahrungen
(wie vom Fragesteller gew�nscht) zu schildern. Dabei
habe ich meine Vorgehensweise, vorhandene Anwendungen
weitgehend mit VB6 weiterzupflegen und neue Anwendungen
mit VB.net zu erstellen, beschrieben. Dass dabei die
Vor- und Nachteile des einen und des anderen Programmier-
werkzeuges erw�hnt werden, ist eher zwangsl�ufig und ich
sehe darin nichts Verwerfliches.
Wenn Du gerne noch weitere 50 Jahre mit VB6 arbeiten willst,
bittesch�n, meinetwegen. Es st�rt mich nicht im Geringsten.
Nur solltest Du halt nicht erwarten, dass ich jemanden der
einen Umstieg von VB6 nach VB.net �berlegt, empfehle
auf keinen Fall .net zu nutzen und weiterhin f�r alle Zeiten
seine Anwendungen mit VB6 zu entwickeln.
Gru� aus St.Georgen
Peter G�tz
Heinz-Mario Frühbeis
"Peter G�tz" <gssg_...@gssg.de> schrieb ...
.NET ist doch wohl eher f�r einen Developer Scripting; VB6 eine
Programmiersprache. :)
Zum Thema "f�r alle Zeiten ... " f�llt mir spontan C ein ...
Und was MS uns (in Zukunft) verweigern m�chte (aus Eigennutz); nun ja,
schau'n wir mal ...
Mit Gru�
Heinz-Mario Fr�hbeis
Steine oder Fertighaus; das ist hier die Frage!
W. Wolf
> Antwort.
>
> Die urspr�ngliche Frage in dieser Diskussion war doch,
> ob jemand Erfahrung mit dem Umstieg von VB6 nach
> Schwierigkeiten dabei auftreten k�nnten usw.
> Dass in dieser Frage, die nicht ich gestellt habe, das
> Wort "VB.net" vorkommt, scheint bei Dir schon eine
>
Dieses "scheint" rettet gerade noch so deine Annahme.
Der Eindruck mag hier entstehen und bezogen auf diese
NG stimmt das auch. Aber ganz so einseitig bin ich nicht.
Ich besitze auch eine aktuelle VS Pro Version und arbeite
gelegentlich damit. Ich kenne wohl die Vorteile. Diese
Vorteile spielen aber in dieser NG aber �berhaupt keine
Rolle, weil es hier um VB-classic geht.
> Ich habe nichts weiter gemacht, als meine Erfahrungen
> (wie vom Fragesteller gew�nscht) zu schildern. Dabei
> habe ich meine Vorgehensweise, vorhandene Anwendungen
> weitgehend mit VB6 weiterzupflegen und neue Anwendungen
> mit VB.net zu erstellen, beschrieben. Dass dabei die
> Vor- und Nachteile des einen und des anderen Programmier-
> werkzeuges erw�hnt werden, ist eher zwangsl�ufig und ich
> sehe darin nichts Verwerfliches.
>
So weit so gut. Andere haben hier auch alternative Wege aufgezeigt.
Zum Teil um das eigene Programm zu erhalten, zum Teil um
auf andere Werkzeuge umzusteigen. Ich st�re mich nur daran,
wenn daraus ein Net-Marketing-Chacka gemacht wird. Daf�r
gibt es Net-Foren und wie ich hoffe, auch bald eine
passende NG.
Zeige Detlef doch das Forum welches MS speziell f�r
Umsteiger eingerichtet hat (ich habe den Link nicht,
weil mich das Forum nicht sonderlich interessiert).
Wenn Detlef wirklich zu Net wechseln will ist er dort
wesentlich besser aufgehoben.
> Wenn Du gerne noch weitere 50 Jahre mit VB6 arbeiten willst,
So wenig wie Du mit .Net weitere 50 Jahre arbeiten willst.
Ich f�rchte bis da hin, hat die Natur f�r uns beide ein
weiteres nicht abw�rtskompatibles Update vorgesehen... ;-)
> bittesch�n, meinetwegen. Es st�rt mich nicht im Geringsten.
> Nur solltest Du halt nicht erwarten, dass ich jemanden der
> einen Umstieg von VB6 nach VB.net �berlegt, empfehle
> auf keinen Fall .net zu nutzen und weiterhin f�r alle Zeiten
> seine Anwendungen mit VB6 zu entwickeln.
>
Daf�r haben wir uns unter anderem auch diese NG eingerichtet.
�brigens habe ich dich gar nicht in der Liste der gez�hlten
Stimmen f�r die Einrichtung der NG gefunden (hoffe ich habe
nichts �bersehen). Hier aber dann am Rande der NG-Charta gegen
VB zu argumentieren, ist ein starkes St�ck.
Heinz-Mario Frühbeis
"Peter Götz" <gssg_...@gssg.de> schrieb ...
> Hallo Thorsten,
>
>>> > Nicht bei dem, auf das ich einging: "Microsoft hängt üblicherweise
>>> > die Abwärtskompatibilität sehr hoch" - ....
>>> Hier lobst Du, dass Microsoft die Abwärtskompatibilität sehr
>>> hoch hält
>>
>> Entschuldige 'mal - das ist ein Zitat von Frank!
>
> Dann habe ich mich wohl vertan und ich bitte dies zu
> entschuldigen.
> Deine Argumentation an VB6 festhalten zu wollen und .net
> abzulehnen, weil man nicht wisse, ob und wie lange darin
> enthaltene Funktionalitäten verfügbar seien, ist mindestens
> ebenso unlogisch. Keiner weiss, wie lange VB6 mit künftigen
> Windows-Versionen noch nutzbar sein wird (tatsächlich gibt
> es bei neueren Systemversionen schon Einschränkungen),
Beispiele?
> es darf aber zumindest vermutet werden, dass .net mindestens
> ebenso lange oder eher länger nutzbar sein wird.
>
> Ich kann mich immer nur wiederholen. Vorhandene VBclassic
> Anwendungen mit VB6 pflegen solange der Bedarf dafür
> besteht und neue Anwendungen mit .net entwickeln, scheint
> mir ein sehr wohl vernünftiger Weg, der sich bei mir in der
> täglichen Praxis bestens bewährt hat.
Mit Gruß
Heinz-Mario Frühbeis
Manches aus der Vergangenheit erscheint mir für die Zukunft viel besser
geeignet! Nur alleine verschiebt sich leider immer der Anfang der
Vergangenheit.
Heinz-Mario Frühbeis
"Frank Müller" <Frank....@t-online.de> schrieb ...
Es ist ja nicht nur das mit dem 64 Bit ... auch 128 Bit, oder gar mehr. Da
sollte noch was kommen, das man mit VB6 noch entwickeln kann.
Mit Gruß
Heinz-Mario Frühbeis
Gott sei Dank ist das nur Software!
Thorsten Albers
<iecgeb$hl0$1...@news.albasani.net>...
> Deine Argumentation an VB6 festhalten zu wollen und .net
> abzulehnen, weil man nicht wisse, ob und wie lange darin
> enthaltene Funktionalitäten verfügbar seien, ist mindestens
> ebenso unlogisch.
Du mißverstehst meine Argumentation: Ich sage lediglich, daß keiner für
sein VB.NET-Programm Inkompatibilitäten ausschließen kann. Zur Zeit besteht
hier sicherlich eine wesentlich geringere Gefahr als bei VB 6, obwohl die
Zeitspannen von Framework-Version zu Framework-Version immer kürzer werden.
Aber das kann sich in Zunkunft ändern - meiner Einschätzung nach sogar in
relativ naher Zukunft, denn ich glaube, daß .NET für MS nur eine Zwischen-
und Entwicklerstufe auf dem Weg zu einem Framework ist, das vollständig
'Netz-basierte' Anwendungen zuläßt. Da wird dann, denke ich, einiges anders
werden oder auf der Strecke bleiben.
--
Thorsten Albers
gudea (a) gmx.de
Lars P. Wolschner
> "Peter Götz" <gssg_...@gssg.de> schrieb
>> bitteschön, meinetwegen. Es stört mich nicht im Geringsten.
>> Nur solltest Du halt nicht erwarten, dass ich jemanden der
>> einen Umstieg von VB6 nach VB.net überlegt, empfehle
>> auf keinen Fall .net zu nutzen und weiterhin für alle Zeiten
>> seine Anwendungen mit VB6 zu entwickeln.
>
> Dafür haben wir uns unter anderem auch diese NG eingerichtet.
> Übrigens habe ich dich gar nicht in der Liste der gezählten
> Stimmen für die Einrichtung der NG gefunden (hoffe ich habe
> nichts übersehen). Hier aber dann am Rande der NG-Charta gegen
> VB zu argumentieren, ist ein starkes Stück.
Ich bitte Dich.
Das Problem hier in dem Thread besteht wohl eher darin, daß man
nicht zwischen Verfahren und deren Algorithmik einerseits und ihren
Implementationen andererseits unterscheidet.
Ich habe beispielsweise ein System entwickelt, das Datenbankab-
fragen aus einer strukturellen Information herleitet, wenn neben
dieser die gewünschten Felder gegeben sind, und das zur Laufzeit.
Die dazu erforderlichen Algorithmen werde ich wohl zu VB.NET oder
C# mitnehmen können, zumal mir der Ansatz der bekannten objekt-
relationalen Mapper - gleichviel ob Hibernate oder die Systeme von
Microsoft - mit relativ komplexen Konfigurationsdateien verbunden
zu sein scheint.
--
Mit freundlichen Grüßen
Lars P. Wolschner
Lars P. Wolschner
Warum sollte es? Das Erfordernis der Implementation von Geschäfts-
logik entfällt doch nicht durch die Verlagerung vom Client auf den
Server oder von dort wiederum in die "Cloud". Und die Cloud ersetzt
ja beispielsweise bei einem location based service auch nicht die
Sensorik einer lokalen Maschine, eines Mobiltelefons. Auch eine
Maschinensteuerung wird nicht in der Cloud stattfinden.
Frank Müller
Peter Götz wrote:
> Hallo Frank,
>> Aber jetzt zum entscheidenden Thema:
>> Was machst du bei diesem Kunden wenn er einen
>> Änderungs- oder Erweiterungswunsch an seiner
>> DOS Software hat? Sagst du ihm dann, dass das nicht
>> geht, machst du ihm ein Angebot für eine .NET Version
>> oder sagst du "Sorry, da kann ich nicht helfen"?
> Weder noch.
> Ich werfe meinen für solche Fälle immer noch betriebsbereiten
> QuickBasic Entwicklungsrechner an und baue die gewünschte
> Änderung.
Siehst du, du orientierst dich am Bedarf deiner Kunden und
versuchst nicht ihnen "koste es was es wolle" eine .NET
Version zu verkaufen.
Und nur so geht es, ich halte auch "alte" Betriebssysteme
vor und werde auch immer mindestens einen Rechner
haben auf denen ich VB-Classic Programme schreiben
bzw. weiter entwickeln kann.
Ich will ja nicht gegen .NET argumentieren,
ganz im Gegenteil, ich verwende es ja auch.
Aber für Bestandskunden halte ich eine
Umstellung "einfach so" ohne zwingenden
Grund für wirtschaftlich nicht sinnvoll bei
größeren Programmen. Schon gar nicht bei
Kunden wo sich die Umgebung nur relativ
selten ändert.
Gruß,
Frank
Frank Müller
Heinz-Mario Frühbeis wrote:
>> Ich wollte eigentlich nur sagen, dass es immer eine Übergangsphase
>> gibt bzw. auch weiterhin geben muss. Wie auch immer und wie lange
>> die sein sollte oder sein wird.
> Es ist ja nicht nur das mit dem 64 Bit ... auch 128 Bit, oder gar
> mehr. Da sollte noch was kommen,
Ja klar wird da in der Zukunft noch mehr kommen, das ist
gar keine Frage. Aber...
> das man mit VB6 noch entwickeln kann.
... ist die entscheidende Frage bzw. wie lange.
Noch ist das kein Problem auf aktuellen Betriebssystemen
32 Bit Anwendungen laufen zu lassen. Aber irgendwann
könnte es nicht mehr so sein.
Wie im anderen Teilthread schon diskutiert ist es für
Bestandskunden die langjährig ihre Hardware bzw.
Betriebssystemumgebungen nicht verändern, halt
die entsprechenden Werkzeuge zu haben um auch
diese Kunden bedienen zu können. Aber das ist
kein Thema für die Masse der Entwickler.
Gruß,
Frank
Frank Müller
Thorsten Albers wrote:
> Peter Götz <gssg_...@gssg.de> schrieb im Beitrag
> <iecgeb$hl0$1...@news.albasani.net>...
>> Deine Argumentation an VB6 festhalten zu wollen und .net
>> abzulehnen, weil man nicht wisse, ob und wie lange darin
>> enthaltene Funktionalitäten verfügbar seien, ist mindestens
>> ebenso unlogisch.
> Du mißverstehst meine Argumentation: Ich sage lediglich, daß keiner
> für sein VB.NET-Programm Inkompatibilitäten ausschließen kann. Zur
> Zeit besteht hier sicherlich eine wesentlich geringere Gefahr als bei
> VB 6,
Ok, lassen wir das mal so stehen
> denn ich glaube, daß .NET für MS nur eine Zwischen- und
> Entwicklerstufe auf dem Weg zu einem Framework ist, das vollständig
> 'Netz-basierte' Anwendungen zuläßt. Da wird dann, denke ich, einiges
> anders werden oder auf der Strecke bleiben.
Nehmen wir an dem ist so, dann ist das ja ein weiteres Argument
mit dem Umstieg auf .NET zu warten für bestehende größere VB6
Anwendungen die momentan problemlos laufen.
Denn grade das "auf der Strecke bleiben" wäre dann
wieder ein Punkt wo entscheidende Änderungen an der .NET
Software notwendig wären.
Gruß,
Frank
Frank Müller
W. Wolf wrote:
> Ich besitze auch eine aktuelle VS Pro Version und arbeite
> gelegentlich damit. Ich kenne wohl die Vorteile. Diese
> Vorteile spielen aber in dieser NG aber �berhaupt keine
> Rolle, weil es hier um VB-classic geht.
Na so eng kann man bzw. sollte man das aber nicht sehen.
Grade die Frage ob und unter welchen Umst�nden sich
ein Umstieg lohnt oder nicht betrifft auch VB-Classic.
> Ich st�re mich nur daran,
> wenn daraus ein Net-Marketing-Chacka gemacht wird. Daf�r
> gibt es Net-Foren und wie ich hoffe, auch bald eine
> passende NG.
In der dann aber VB-Classic OT w�re?
Wo sollte man das denn deiner Meinung nach diskutieren?
> Zeige Detlef doch das Forum welches MS speziell f�r
> Umsteiger eingerichtet hat (ich habe den Link nicht,
> weil mich das Forum nicht sonderlich interessiert).
Gibt oder gab es daf�r eine Newsgroup (kein Web Forum)?
>> Nur solltest Du halt nicht erwarten, dass ich jemanden der
>> einen Umstieg von VB6 nach VB.net �berlegt, empfehle
>> auf keinen Fall .net zu nutzen und weiterhin f�r alle Zeiten
>> seine Anwendungen mit VB6 zu entwickeln.
> Daf�r haben wir uns unter anderem auch diese NG eingerichtet.
Daf�r bestimmt nicht um jemandem zu empfehlen unbedingt
bei VB6 zu bleiben. Diese NG ist daf�r da Fragen zu
VB-Classic zu beantworten, dazu geh�rt halt auch das
Thema dieser Diskussion meiner pers�nlichen Meinung nach.
Und grade Peter ist doch ein Beispiel daf�r, dass es
kompetente Leute gibt die sich in beiden "Welten" auskennen.
Und er hilft auch, beantwortet Fragen sowohl bei VB-Classic
als auch bei VB.NET.
> Hier aber dann am Rande der NG-Charta gegen
> VB zu argumentieren, ist ein starkes St�ck.
Das macht er doch �berhaupt nicht, ganz im Gegenteil.
Und in der Charta steht ja nicht: "VB-Classic ist beste
Programmiersprache von Welt, nix anderes gibt es."
Warum sollte er deiner Meinung nach gegen die Charta
verstossen haben?
Gru�,
Frank
Frank Müller
>> Das .net Framework ist, wie schon erwähnt auf den aktuellen
>> Windows-Versionen schon vorhanden
> Da mußt Du schon ganz genau präzisieren, was eine
> aktuelle Windows-Version ist (aktuell <> neu).
Genau, aktuell ist immer das was der User hat und
wo die Anwendung laufen muss.
> Im Business Bereich kann (konnte ich zumindest bis
> gestern) noch Rechner mit vorinstalliertem XP kaufen
Ja und auch im Consumer Bereich gibt es bei Windows 7
inszwischen wieder den XP-Modus kostenlos. Muss zwar
per Downlaod auf den Rechner und installiert werden,
ist aber kostenlos.
> und in meinem Umfeld ist das sogar die Regel. Große
> Unternehmen wie einer meiner Aufraggeber haben sogar
> Abkommen mit MS, dass XP noch lange genutzt und auf neuen
> Rechner installiert werden kann. Hier handelt es sich
> unter anderen um spezielle Industrie-PCs.
Richtig, so kenne ich das auch von einigen meiner Kunden.
> Der Witz dabei
> ist, dass die Produkt-Techniker, Programmierer und sonstige
> Beteiligte vergleichbare PCs unterm Tisch haben, weil sie
> so näher am Produkt sind.
Das ist kein Witz, das ist Tatsache und auch notwendig.
Siehe anderen Teilthread.
> Ein aktuelles Framework 4 ist ganz sicher nicht immer
> vorhanden. Nun könntest Du ja auch gegen das 3.5-er
> oder älter programmieren um die Wahrscheinlichkeit
> der Framework-Existenz zu erhöhen. Dann machst Du
> aber das gleiche wie ich, wenn ich gegen die VB-Runtime
> programmiere. An die Verbreitung der VB-Runtime kommst
> Du dennoch nicht heran.
Das stimmt schon, aber grade die Frage gegen welches
minimale Framework man entwickelt ist hier ein Problem.
Das ist keineswegs in der neuesten Version vorhanden
obwohl es über Windows Update verteilt wird.
Die Frage ist eher ob und wann die VB-Runtime irgendwann
mal "unten raus" fallen wird. Klar dauert das noch eine
Weile, wie lange weiß aber niemand.
Gruß,
Frank
Thorsten Doerfler
>> Ich störe mich nur daran,
>> wenn daraus ein Net-Marketing-Chacka gemacht wird. Dafür
>> gibt es Net-Foren und wie ich hoffe, auch bald eine
>> passende NG.
>
Nein, VB.classic war der Grund dieses Forum zu schaffen.
> Wo sollte man das denn deiner Meinung nach diskutieren?
Wenn es nach einigen geht, am besten gar nicht. Klassische
Scheuklappenmentalität. Mag ich nicht, will ich nicht, gibt es nicht.
>> Zeige Detlef doch das Forum welches MS speziell für
>> Umsteiger eingerichtet hat (ich habe den Link nicht,
>> weil mich das Forum nicht sonderlich interessiert).
>
> Gibt oder gab es dafür eine Newsgroup (kein Web Forum)?
Von MSFT gibt es keine Newsgroups mehr und eine NG speziell für
Umsteiger (wohin auch immer) hat es nicht gegeben. Hier möchte man dies
offenbar auch nicht diskutiert sehen.
>> Dafür haben wir uns unter anderem auch diese NG eingerichtet.
>
> Dafür bestimmt nicht um jemandem zu empfehlen unbedingt
> bei VB6 zu bleiben. Diese NG ist dafür da Fragen zu
> VB-Classic zu beantworten, dazu gehört halt auch das
> Thema dieser Diskussion meiner persönlichen Meinung nach.
Du hast die Diskussionen zur Einrichtung dieser Gruppe wohl nicht
verfolgt, aber ein Umstieg nach .NET ist für VB6 keine Option, daher
soll dies auch nicht hier diskutiert werden.
"Mag ich nicht, will ich nicht, gibt es nicht."
> Warum sollte er deiner Meinung nach gegen die Charta
> verstossen haben?
Peter vertritt nach Meinung von W. eine Meinung, die W. hier nicht lesen
möchte. Nach Charta dieser NG ein legitimer Wunsch. Unverständlich nur,
dass W. diesen Hinweis nicht an den OP richtet, der das ganze erst ins
Rollen gebracht hat, sondern Peter einen Vorwurf macht hier durchaus
richtige Fakten zu einer möglichen Alternative zu VB6 niederzuschreiben,
wie es vom OP gewünscht wurde.
Thorsten Dörfler
--
Microsoft MVP Visual Basic
vb-hellfire visual basic faq | vb-hellfire - einfach anders
http://vb-faq.de/ | http://www.vb-hellfire.de/
Frank Müller
Thorsten Doerfler wrote:
> Am 16.12.2010 23:55, schrieb Frank Müller:
>>> Ich störe mich nur daran,
>>> wenn daraus ein Net-Marketing-Chacka gemacht wird. Dafür
>>> gibt es Net-Foren und wie ich hoffe, auch bald eine
>>> passende NG.
>>
>> In der dann aber VB-Classic OT wäre?
> Nein, VB.classic war der Grund dieses Forum zu schaffen.
Hier sind wir ja nicht in einem (Web)Forum sondern im Usenet.
>> Wo sollte man das denn deiner Meinung nach diskutieren?
> Wenn es nach einigen geht, am besten gar nicht. Klassische
> Scheuklappenmentalität. Mag ich nicht, will ich nicht, gibt es nicht.
Eben und genau hier in den Newsgroups gibt es keine Admins
die das zensieren wie es oft in einem Webforum gemacht wird.
Das ist der Vorteil gegenüber einem Forum und das ist auch
gut so.
>> Gibt oder gab es dafür eine Newsgroup (kein Web Forum)?
> Von MSFT gibt es keine Newsgroups mehr und eine NG speziell für
> Umsteiger (wohin auch immer) hat es nicht gegeben. Hier möchte man
> dies offenbar auch nicht diskutiert sehen.
Ja jetzt leider nicht mehr.
Es hat aber ansatzweise schon Umstiegshilfen für VB-Classic
Programme auf neue BS gegeben wie z.B. die NG
news://microsoft.public.vb.vista.compatibility
Klar hatte auch die nichts mit dem Wechsel zu .NET zu tun.
> Du hast die Diskussionen zur Einrichtung dieser Gruppe wohl nicht
> verfolgt, aber ein Umstieg nach .NET ist für VB6 keine Option, daher
> soll dies auch nicht hier diskutiert werden.
>
> "Mag ich nicht, will ich nicht, gibt es nicht."
Doch die Diskussionen habe ich verfolgt auch wenn ich
mich nicht aktiv daran beteiligt habe.
>> Warum sollte er deiner Meinung nach gegen die Charta
>> verstossen haben?
> Peter vertritt nach Meinung von W. eine Meinung, die W. hier nicht
> lesen möchte. Nach Charta dieser NG ein legitimer Wunsch.
Nicht wirklich.
Wenn W. das nicht lesen möchte, aus welchen Gründen auch immer,
dann soll er die Postings von Peter halt einfach ignorieren oder
ihn in seinen Filter packen oder was auch immer.
In der Charta steht natürlich, dass es sich um VB-Classic handeln
soll, aber genau das tut es wenn jemand nach Möglichkeiten oder
Problemen fragt die mit einem Umstieg auf "irgendwohin"
zusammen hängen. Ich sehe immer noch keinen Punkt der Charta
gegen den der OP oder Peter oder die anderen am Thread
beteiligten verstossen haben.
> Unverständlich nur, dass W. diesen Hinweis nicht an den OP richtet,
> der das ganze erst ins Rollen gebracht hat, sondern Peter einen
> Vorwurf macht hier durchaus richtige Fakten zu einer möglichen
> Alternative zu VB6 niederzuschreiben, wie es vom OP gewünscht wurde.
Das kann ich aber nachvollziehen, denn die Frage des OP ist ja nicht
Gegenstand seines Protestes sondern die Antworten von Peter.
Der OP hat nichts falsch gemacht, ganz im Gegenteil er war
mit seiner Frage völlig OT.
Aber gut, das ist halt Usenet, da bekommt man nicht
immer nur die Postings die man gerne lesen möchte.
Aber grade das ist ein Vorteil gegenüber Foren
welcher Art auch immer.
Gruß,
Frank
W. Wolf
[...]
>
> Peter vertritt nach Meinung von W. eine Meinung, die W. hier nicht lesen
> dass W. diesen Hinweis nicht an den OP richtet, der das ganze erst ins
> Rollen gebracht hat, sondern Peter einen Vorwurf macht hier durchaus
> wie es vom OP gew�nscht wurde.
>
Detlefs Sorgen sind real, jeder der hier regelm�ssig
schreibt und daheim eine gro�e VB-Anwendung zu pflegen
hat, hat schon in diesem Schwitzkasten gesessen. Ich nehme
es daher Detlef nicht �bel, gefragt zu haben. Er hat auch
gen�gend konstruktive L�sungsans�tze aus allen m�glichen
Richtungen bekommen. Auch von Peter. Mit Peters Empfehlung
kann ich gut leben, auch wenn ich sie nicht ganz teile.
Wenn ein Umstieg gewollt ist, ist VB.Net eine naheliegende
Alternative, auf den ersten Blick schon wegen der
Namensgleichheit. Was hat aber das Dot-Net-MIDI-Tool
(welches so sch�n in .Net zu programmieren war und gegen
das VB keinen Hauch einer Chance h�tte) mit Detlefs
Fragestellung zu tun?
Es gibt einen Punkt, wo Mancher all zu gerne zu dieser
Net-Euphorie �berschwenkt und schwupp-di-wups werden
in der classic-NG Links zu .Net Beispielen (oder gar
ganze Net-Quellcode-Passagen gepostet, letzteres war
allerdings der andere Peter. Zwischen-Frage an
Peter Fleischer: Darf ich in deiner neu angestrebten
.Net-NG auch VB-Classic Code posten? Im Rfd schreibst Du:
"Alle Fragen zu Visual Basis bis einschlie�lich Version 6
sind in der Newsgroup de.comp.lang.vbclassic zu platzieren"
Warum postest Du dann hier VB.Net Code?).
Wenn dann noch in Werbemanier hier von .Net-Vorteilen
geschw�rmt wird, so habe ich den Eindruck schon wieder
in der alten mpde zu sitzen. Das muss nicht sein, oder? Daf�r
habe ich in dclm und dang nicht mitgestritten.
Dieter Strassner
> Wenn dann noch in Werbemanier hier von .Net-Vorteilen
> geschwärmt wird, so habe ich den Eindruck schon wieder
> in der alten mpde zu sitzen. Das muss nicht sein, oder? Dafür
> habe ich in dclm und dang nicht mitgestritten.
Ach, gibt schlimmeres im Leben....
So tragisch ist das nun nicht.
--
Viele Grüße - Dieter
EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
Ulrich Korndoerfer
Thorsten Doerfler schrieb:
> Von MSFT gibt es keine Newsgroups mehr und eine NG speziell für
> Umsteiger (wohin auch immer) hat es nicht gegeben. Hier möchte man dies
> offenbar auch nicht diskutiert sehen.
>
Richtig ist, daß es keine Usenet-NG für Umsteiger von VBClassic zu .NET
gibt. Falsch ist die Konnotation, daß hier nicht über Alternativen zu
VBClassic diskutiert werden darf. Richtig ist, daß das Prozedere eines
Umstiegs hier OT ist.
>>> Dafür haben wir uns unter anderem auch diese NG eingerichtet.
>> Dafür bestimmt nicht um jemandem zu empfehlen unbedingt
>> bei VB6 zu bleiben. Diese NG ist dafür da Fragen zu
>> VB-Classic zu beantworten, dazu gehört halt auch das
>> Thema dieser Diskussion meiner persönlichen Meinung nach.
>
> Du hast die Diskussionen zur Einrichtung dieser Gruppe wohl nicht
> verfolgt, aber ein Umstieg nach .NET ist für VB6 keine Option, daher
> soll dies auch nicht hier diskutiert werden.
>
"Hier" ist diese NG? OK, wie oben erwähnt, Diskussionen über
Umstiegsmöglichkeiten sind hier nicht OT, die Diskussion über das
Umstiegsprozedere schon.
> "Mag ich nicht, will ich nicht, gibt es nicht."
>
Albern.
>> Warum sollte er deiner Meinung nach gegen die Charta
>> verstossen haben?
>
> Peter vertritt nach Meinung von W. eine Meinung, die W. hier nicht lesen
> möchte. Nach Charta dieser NG ein legitimer Wunsch. Unverständlich nur,
> dass W. diesen Hinweis nicht an den OP richtet, der das ganze erst ins
> Rollen gebracht hat, sondern Peter einen Vorwurf macht hier durchaus
> richtige Fakten zu einer möglichen Alternative zu VB6 niederzuschreiben,
> wie es vom OP gewünscht wurde.
In dieser Charta steht nirgends, daß W. hier bestimmte Meinungen nicht
lesen möchte. Das ist auch kein legitimer Wunsch gemäß dieser Charta.
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
Ulrich Korndoerfer
W. Wolf schrieb:
> "Thorsten Doerfler" <t.doerfl...@bdsw.de> schrieb
> [...]
>>
>> Peter vertritt nach Meinung von W. eine Meinung, die W. hier nicht lesen
>> möchte. Nach Charta dieser NG ein legitimer Wunsch. Unverständlich nur,
>> dass W. diesen Hinweis nicht an den OP richtet, der das ganze erst ins
>> Rollen gebracht hat, sondern Peter einen Vorwurf macht hier durchaus
>> richtige Fakten zu einer möglichen Alternative zu VB6 niederzuschreiben,
>> wie es vom OP gewünscht wurde.
>>
>
> Detlefs Sorgen sind real, jeder der hier regelmässig
> schreibt und daheim eine große VB-Anwendung zu pflegen
> hat, hat schon in diesem Schwitzkasten gesessen. Ich nehme
> es daher Detlef nicht übel, gefragt zu haben. Er hat auch
> genügend konstruktive Lösungsansätze aus allen möglichen
> Richtungen bekommen. Auch von Peter. Mit Peters Empfehlung
> kann ich gut leben, auch wenn ich sie nicht ganz teile.
> Wenn ein Umstieg gewollt ist, ist VB.Net eine naheliegende
> Alternative, auf den ersten Blick schon wegen der
> Namensgleichheit. Was hat aber das Dot-Net-MIDI-Tool
> (welches so schön in .Net zu programmieren war und gegen
> das VB keinen Hauch einer Chance hätte) mit Detlefs
> Fragestellung zu tun?
>
Nichts. Ist halt in der "Hitze" der Diskussion, und vielleicht weil der
Autor so stolz darüber ist, gefallen. Wahrscheinlich war es einfach nur
ein Beispiel, wie man nach Meinung des Autors unter .NET effizienter
arbeiten kann.
> Es gibt einen Punkt, wo Mancher all zu gerne zu dieser
> Net-Euphorie überschwenkt und schwupp-di-wups werden
> in der classic-NG Links zu .Net Beispielen (oder gar
> ganze Net-Quellcode-Passagen gepostet, letzteres war
> allerdings der andere Peter. Zwischen-Frage an
> Peter Fleischer: Darf ich in deiner neu angestrebten
> ..Net-NG auch VB-Classic Code posten? Im Rfd schreibst Du:
> "Alle Fragen zu Visual Basis bis einschließlich Version 6
> sind in der Newsgroup de.comp.lang.vbclassic zu platzieren"
> Warum postest Du dann hier VB.Net Code?).
>
> Wenn dann noch in Werbemanier hier von .Net-Vorteilen
> geschwärmt wird, so habe ich den Eindruck schon wieder
> in der alten mpde zu sitzen. Das muss nicht sein, oder? Dafür
> habe ich in dclm und dang nicht mitgestritten.
>
Komm bitte wieder runter, ja? ;-).
Zum einen hält sich der .NET "Belästigungspegel" sehr in Grenzen. Zum
anderen hat der OP zwar (für mich sehr) spät, aber immerhin, nur ein
Thema angesprochen, welches uns alle betrifft: wie man in Zukunft
verfahren soll, ist ein Thema, das uns allen unter den Nägeln brennt.
Sei doch froh, daß er es hier getan hat. In einer .NET Group wären die
Antworten in Summe undifferenzierter ausgefallen.
Und wenn ich mich recht erinnere, schließt die Charta zwar Diskussionen
darüber aus, *wie* eine Migration zu .NET stattfinden sollte. *Ob* aber
eine Migration zu .NET sinnvoll oder wünschenswert ist, ist AFAIR nicht OT.
Da hat halt jeder so seine Meinung, der Bias ist hier sicher dagegen,
aber andere Stimmen sollten auch erlaubt sein, solange sie nicht in
reine Werbeaktionen ausarten (die Peter Götz sicher nicht veranstaltet
hat). Da besteht ja auch noch Aufklärungsbedarf bzgl. "wie gehts weiter"
und in der Richtung, daß eine Migration zu .NET nicht das allein
seligmachende ist. Wohin sollen sich den die armen Seelen, die "immer
noch" mit VBClassic arbeiten, bei Fragen zur Zukunft denn hin wenden
wenn nicht hier her? Und dann muß da drüber auch diskutiert werden
können, mit allem Wenn und Aber.
Zusammenfassend sind Diskussionen darüber, "wie es weiter gehen soll",
hier nicht OT. .NET ist eine der Möglichkeiten, deshalb kann man sie bei
solchen Diskussionen nicht ausschließen. Und dann muß man auch Vertreter
der .NET Linie dazu zu Wort kommen lassen.
Ach ja, bei den Diskussionen in dclm und dang habe ich auch ein bißchen
mitgemischt, AFAIR war ich sogar einer der Initiatoren für dclv :-)
Peter Götz
> Detlefs Sorgen sind real, jeder der hier regelmässig
> schreibt und daheim eine große VB-Anwendung zu pflegen
> hat, hat schon in diesem Schwitzkasten gesessen. Ich nehme
> es daher Detlef nicht übel, gefragt zu haben.
Ich auch nicht, und genau deshalb habe ich ihm auch
von meinen praktischen Erfahrungen in Sachen Umstieg
von VBclassic zu anderen Entwicklungsumgebungen wie
u.a. VB.net berichtet.
> Er hat auch
> genügend konstruktive Lösungsansätze aus allen möglichen
> Richtungen bekommen. Auch von Peter. Mit Peters Empfehlung
> kann ich gut leben, auch wenn ich sie nicht ganz teile.
Ich denke mal, dass mein Ansatz, bestehende VBclassic
Anwendungen mit VB6 weiterzupflegen, solange Bedarf
besteht und die Kundenanforderungen so erfüllt werden können
und neue Projekte mit moderneren Entwicklungswerkzeugen
zu erstellen eine durchaus weit verbreitete Vorgehensweise
ist.
Ich weiss nicht, was Dich daran so stört, dass Du immer
gleich auf die Palme gehst, wenn dabei mal der Begriff
.net vorkommt.
> Wenn ein Umstieg gewollt ist, ist VB.Net eine naheliegende
> Alternative, auf den ersten Blick schon wegen der
> Namensgleichheit.
Sage ich was anderes?
Wobei die "Namensgleichheit" dabei nicht als ein Argument
sehen würde.
> Was hat aber das Dot-Net-MIDI-Tool
> (welches so schön in .Net zu programmieren war und gegen
> das VB keinen Hauch einer Chance hätte) mit Detlefs
> Fragestellung zu tun?
Ich kann mich nicht erinnern, in irgendeinem meiner Beiträge
den Ausdruck "VB habe keinen Hauch einer Chance"
gebraucht zu haben. Vielleicht solltest Du Postings einfach
so lesen wie sie geschrieben wurden und nicht irgendwelche
Dinge hineininterpretieren die nirgendwo geschrieben wurden.
Als Antwort auf eines meiner Postings wurde behauptet, dass
es möglich sei, jede Art von Aufgabenstellung mit VB6 zu lösen
und ich wurde aufgefordert ein Beispiel zu nennen, bei dem
dies gar nicht oder nur schwer möglich ist.
Genau ein solches praktisches Beispiel habe ich daraufhin
wie gewünscht genannt.
> Es gibt einen Punkt, wo Mancher all zu gerne zu dieser
> Net-Euphorie überschwenkt und schwupp-di-wups werden
> in der classic-NG Links zu .Net Beispielen (oder gar
> ganze Net-Quellcode-Passagen gepostet, letzteres war
> allerdings der andere Peter.
Wenn Du das Ganze nicht aus dem Zusammenhang reissen
würdest, könntest Du vielleicht auch zu der Ansicht gelangen,
dass Peter Fleischer hiermit dem Fragesteller durchaus eine
brauchbare Hilfestellung gegeben hat. Genau solche Hilfestellungen
sind Sinn und Zweck einer Entwickler-NG aber sicher nicht
übereifriges Lauern auf Beiträge, die mal auf eine andere
Entwicklungsumgebung verweisen.
> Zwischen-Frage an
> Peter Fleischer: Darf ich in deiner neu angestrebten
> .Net-NG auch VB-Classic Code posten? Im Rfd schreibst Du:
> "Alle Fragen zu Visual Basis bis einschließlich Version 6
> sind in der Newsgroup de.comp.lang.vbclassic zu platzieren"
> Warum postest Du dann hier VB.Net Code?).
Ich kann mich nur wiederholen. Sinn und Zweck einer Entwickler-NG
ist es, Informationen zu Entwicklerthemen auszutauschen und sich
gegenseitig zu helfen. Wenn eine solche Hilfe dann evtl. so
aussieht, dass sie einen Hinweis auf ein anderes Entwicklungswerkzeug
gibt, dann liegt es vor allem beim Fragesteller zu beurteilen, ob
ihm ein solcher Hinweis geholfen hat.
> Wenn dann noch in Werbemanier hier von .Net-Vorteilen
> geschwärmt wird, so habe ich den Eindruck schon wieder
> in der alten mpde zu sitzen.
Offenbar ist für Dich alles, was nicht eindeutig und unmissverständlich
gegen .net spricht ein rotes Tuch. Es muss Dir doch irgendwann mal
selbst auffallen, dass niemand sonst mit solchem Übereifer alles
ausser VB6 ablehnt, ja geradezu verteufelt, und aus jeglicher
Diskussion verbannen möchte.
> Das muss nicht sein, oder? Dafür
> habe ich in dclm und dang nicht mitgestritten.
Ich würde mir wünschen, Du würdest künftig ein kleines bisschen
mehr Gelassenheit an den Tag legen und nicht jedesmal auf
die Palme gehen, wenn jemand ein Entwicklungswerkzeug
nennt, das nicht VB6 heisst.
Gruß aus St.Georgen
Peter Götz
Peter Götz
>> Das .net Framework ist, wie schon erwähnt auf den aktuellen
>> Windows-Versionen schon vorhanden und meine mit
>> .net entwickelten Anwendungen brauchen, wenn sie nicht
>> z.B. mehrsprachig ausgelegt sind,weder zusätzliche DLLs
>> noch eine Registrierung. Die entsprechende *.exe wird einfach
>> per XCopy auf den Zielrechner gebracht oder noch einfacher
>> direkt von einem USB-Stick aus gestartet.
>>
>
> Da mußt Du schon ganz genau präzisieren, was eine
> aktuelle Windows-Version ist (aktuell <> neu).
Akt. Versionen in meinem Umfeld sind Windows XP,
vereinzelte Vista und derzeit mehr und mehr Windows 7,
sowie Server2003 und höher.
> Im Business Bereich kann (konnte ich zumindest bis
> gestern) noch Rechner mit vorinstalliertem XP kaufen
> und in meinem Umfeld ist das sogar die Regel.
Meine Anwender installieren auf neuen Rechnern zwar kein
XP mehr, aber natürlich haben sie noch reichlich Rechner
in Betrieb, auf denen XP installiert ist. Meine mit .net
entwickelten Anwendungen laufen auf diesen Rechnern
völlig problemlos und wie schon erwähnt mit der angenehmen
Begleiterscheinung weder ein aufwändiges Setup noch
irgendwelche Registrierungen zu benötigen. Die *.exe
wird einfach per xCopy auf den Rechner gebracht oder,
sehr angenehm bei kleineren Tools, auch gleich direkt
von einem wechselbaren Datenträger wie z.B. USB-Stick
gestartet.
> Große
> Unternehmen wie einer meiner Aufraggeber haben sogar
> Abkommen mit MS, dass XP noch lange genutzt und auf neuen
> Rechner installiert werden kann. Hier handelt es sich
> unter anderen um spezielle Industrie-PCs. Der Witz dabei
> ist, dass die Produkt-Techniker, Programmierer und sonstige
> Beteiligte vergleichbare PCs unterm Tisch haben, weil sie
> so näher am Produkt sind.
Aha!..?
Und was willst Du mir damit sagen?
> Ein aktuelles Framework 4 ist ganz sicher nicht immer
> vorhanden.
Aber mindestens ein 2.0 und bei regelmässig gewarteten
und mit akt. Updates versehenen Rechnern auch die
jüngeren Versionen des .net-Frameworks.
> Nun könntest Du ja auch gegen das 3.5-er
> oder älter programmieren um die Wahrscheinlichkeit der Framework-Existenz
> zu erhöhen.
Genau das mache in in den Fällen, bei denen ich kein
höheres FW als 2.0 voraussetzen kann, was allerdings
nur sehr seltene Einzelfälle sind.
> Dann machst Du aber das gleiche wie ich, wenn ich gegen die VB-Runtime
> programmiere.
Da möchte ich nochmal auf mein "Midi-Orchestra" verweisen,
das maximal .net FW 2.0 benötigt und damit keinerlei
Einschränkungen verbunden sind.
Schau Dir vielleicht einfach mal etwas genauer an, was die
neueren Frameworkversionen gegenüber der Version 2.0 an
zusätzlicher Funktionalität mitbringen.
> An die Verbreitung der VB-Runtime kommst
> Du dennoch nicht heran.
Da ich mit den Admins meiner Kunden eng zusammenarbeite,
hatte ich noch nie irgendein Problem, wenn es darum ging
eine VBclassic oder eine .net Laufzeitumgebung auf den
jeweiligen Rechnern vorzufinden.
Peter Götz
>> Deine Argumentation an VB6 festhalten zu wollen und .net
>> abzulehnen, weil man nicht wisse, ob und wie lange darin
>> enthaltene Funktionalitäten verfügbar seien, ist mindestens
>> ebenso unlogisch.
>
> Du mißverstehst meine Argumentation: Ich sage lediglich, daß
> keiner für sein VB.NET-Programm Inkompatibilitäten ausschließen
> kann.
Da ich ausschliesslich Anwendungen für einen bestimmten
Kundenkreis und nach konkretem Auftrag entwickle, kann ich
Inkompatibilitäten sehr wohl ausschliessen. Um solche von
vorneherein auszuschliessen gibt es für jedes neu zu entwickelnde
Projekt ein sehr detailliertes Pflichtenheft.
> Zur Zeit besteht hier sicherlich eine wesentlich geringere Gefahr
> als bei VB 6, obwohl die Zeitspannen von Framework-Version
> zu Framework-Version immer kürzer werden.
Was aber nicht bedeutet, dass Funktionalitäten älterer FW-Versionen
bei den neueren FW-Versionen nicht mehr verfügbar wären.
> Aber das kann sich in Zunkunft ändern - meiner Einschätzung nach
> sogar in relativ naher Zukunft, denn ich glaube, daß .NET für MS
> nur eine Zwischen- und Entwicklerstufe auf dem Weg zu einem
> Framework ist, das vollständig 'Netz-basierte' Anwendungen
> zuläßt. Da wird dann, denke ich, einiges anders werden oder
> auf der Strecke bleiben.
Ich möchte Dich daran erinnern, dass es .net nun schon seit gut
10 Jahren gibt. Bei der allgemeinen Schnell- und Kurzlebigkeit
im IT-Bereich würde ich bei einem über 10 Jahre im Einsatz
befindlichen Produkt nicht unbedingt mehr von einer Zwischenlösung
sprechen. Das kommt mir ein bisschen so vor, als würde einer
sagen, ich bleibe bei DBase, weil Access, SQL-Server, Oracle
usw. alles nur Zwischenlösungen auf dem Weg zu einem in der
Zukunft liegenden ultimativen DB-System seien.
Thorsten Doerfler
> Thorsten Doerfler wrote:
>> Frank Müller schrieb:
>>>> Ich störe mich nur daran,
>>>> wenn daraus ein Net-Marketing-Chacka gemacht wird. Dafür
>>>> gibt es Net-Foren und wie ich hoffe, auch bald eine
>>>> passende NG.
>>>
>>> In der dann aber VB-Classic OT wäre?
>
>> Nein, VB.classic war der Grund dieses Forum zu schaffen.
>
> Hier sind wir ja nicht in einem (Web)Forum sondern im Usenet.
Danke, wäre mir nicht aufgefallen. Aber offenbar haben wir uns hier
missverstanden. Ich bezog mich auf das Webforum, das für VB6 (Migration)
eingerichtet wurde.
>>> Wo sollte man das denn deiner Meinung nach diskutieren?
>
>> Wenn es nach einigen geht, am besten gar nicht. Klassische
>> Scheuklappenmentalität. Mag ich nicht, will ich nicht, gibt es nicht.
>
> Eben und genau hier in den Newsgroups gibt es keine Admins
> die das zensieren wie es oft in einem Webforum gemacht wird.
Darum ging es gar nicht.
> Ich sehe immer noch keinen Punkt der Charta
> gegen den der OP oder Peter oder die anderen am Thread
> beteiligten verstossen haben.
Dann sind wir ja einer Meinung.
>> Unverständlich nur, dass W. diesen Hinweis nicht an den OP richtet,
>> der das ganze erst ins Rollen gebracht hat, sondern Peter einen
>> Vorwurf macht hier durchaus richtige Fakten zu einer möglichen
>> Alternative zu VB6 niederzuschreiben, wie es vom OP gewünscht wurde.
>
> Das kann ich aber nachvollziehen, denn die Frage des OP ist ja nicht
> Gegenstand seines Protestes sondern die Antworten von Peter.
Wenn einer nach der Option .NET fragt, sind .NET lastige Antworten
nahezu unausweichlich. Daher verstehe ich das Verhalten von W. ggü.
Peter ja nun nicht. Muss ich aber auch nicht. Ich kenne es ja nicht anders.
> Der OP hat nichts falsch gemacht, ganz im Gegenteil er war
> mit seiner Frage völlig OT.
Off-Topic, oder On-Topic?
> Aber gut, das ist halt Usenet, da bekommt man nicht
> immer nur die Postings die man gerne lesen möchte.
> Aber grade das ist ein Vorteil gegenüber Foren
> welcher Art auch immer.
Nein, das kann ich in Foren auch haben.
W. Wolf
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> schrieb
>>
>> Detlefs Sorgen sind real, jeder der hier regelmässig
>> schreibt und daheim eine große VB-Anwendung zu pflegen
>> hat, hat schon in diesem Schwitzkasten gesessen. Ich nehme
>> es daher Detlef nicht übel, gefragt zu haben. Er hat auch
>> genügend konstruktive Lösungsansätze aus allen möglichen
>> Richtungen bekommen. Auch von Peter. Mit Peters Empfehlung
>> kann ich gut leben, auch wenn ich sie nicht ganz teile.
>> Wenn ein Umstieg gewollt ist, ist VB.Net eine naheliegende
>> Alternative, auf den ersten Blick schon wegen der
>> Namensgleichheit. Was hat aber das Dot-Net-MIDI-Tool
>> (welches so schön in .Net zu programmieren war und gegen
>> das VB keinen Hauch einer Chance hätte) mit Detlefs
>> Fragestellung zu tun?
>>
>
> Da hat halt jeder so seine Meinung, der Bias ist hier sicher dagegen, aber
> andere Stimmen sollten auch erlaubt sein, solange sie nicht in reine
> Werbeaktionen ausarten (die Peter Götz sicher nicht veranstaltet hat). Da
> besteht ja auch noch Aufklärungsbedarf bzgl. "wie gehts weiter" und in der
> Richtung, daß eine Migration zu .NET nicht das allein seligmachende ist.
> Wohin sollen sich den die armen Seelen, die "immer noch" mit VBClassic
> arbeiten, bei Fragen zur Zukunft denn hin wenden wenn nicht hier her? Und
> dann muß da drüber auch diskutiert werden können, mit allem Wenn und Aber.
>
> Zusammenfassend sind Diskussionen darüber, "wie es weiter gehen soll",
> hier nicht OT. .NET ist eine der Möglichkeiten, deshalb kann man sie bei
> solchen Diskussionen nicht ausschließen. Und dann muß man auch Vertreter
> der .NET Linie dazu zu Wort kommen lassen.
Ich lasse mal mein Gesagtes und dein Gesagtes stehen.
Wodurch unterscheiden sich unsere Aussagen? Dass ich
.Net-Links und .Net-Quellcode hier als deplaziert halte?
Das sehe ich nun mal so und erinnere dabei an den
nicht enden wollenden .Net-Lobgesang in mpdv. Ich hatte
tatsächlich gehofft hier meine Ruhe zu haben und
konstruktiv über die Themen der Charta diskutieren zu
können. War wohl nix... einmal Herpes - immer Herpes.
Schade!
Schön's Wochenende
W. Wolf
Thorsten Albers
<iefcqv$ohm$1...@news.albasani.net>...
> Da ich ausschliesslich Anwendungen f�r einen bestimmten
> Kundenkreis und nach konkretem Auftrag entwickle, kann ich
> vorneherein auszuschliessen gibt es f�r jedes neu zu entwickelnde
> Projekt ein sehr detailliertes Pflichtenheft.
Das bedeutet also, da� Du f�r jeden Kunden von Anfang an neu programmierst
und keinen eigenen wiederverwendbaren Code einsetzt?
> Was aber nicht bedeutet, dass Funktionalit�ten �lterer FW-Versionen
> bei den neueren FW-Versionen nicht mehr verf�gbar w�ren.
...aber - bei der Art von MS, mit solchen Dingen umzugehen - von heute auf
morgen nicht mehr verf�gbar sein k�nnen.
> Ich m�chte Dich daran erinnern, dass es .net nun schon seit gut
> 10 Jahren gibt. Bei der allgemeinen Schnell- und Kurzlebigkeit
> im IT-Bereich w�rde ich bei einem �ber 10 Jahre im Einsatz
> befindlichen Produkt nicht unbedingt mehr von einer Zwischenl�sung
> sprechen.
F�r Software sind 10 Jahre nicht kurz, f�r Bibliothek(sammlungen) dagegen
nicht gerade lang. Dann auch noch innerhalb dieser Zeit 6 Versionen bzw.
Versions-'Abs�tze' (1, 1.1, 2, 3, 3.5, 4).
> Das kommt mir ein bisschen so vor, als w�rde einer
> sagen, ich bleibe bei DBase, weil Access, SQL-Server, Oracle
> usw. alles nur Zwischenl�sungen auf dem Weg zu einem in der
> Zukunft liegenden ultimativen DB-System seien.
Du willst hoffentlich nicht die bisherige Lebensspanne von .NET mit der von
DBase, Access oder SQL vergleichen.
Peter Götz
>> Da ich ausschliesslich Anwendungen für einen bestimmten
>> Kundenkreis und nach konkretem Auftrag entwickle, kann ich
>> Inkompatibilitäten sehr wohl ausschliessen. Um solche von
>> vorneherein auszuschliessen gibt es für jedes neu zu entwickelnde
>> Projekt ein sehr detailliertes Pflichtenheft.
>
> Das bedeutet also, daß Du für jeden Kunden von Anfang an neu
> programmierst und keinen eigenen wiederverwendbaren Code
> einsetzt?
Habe ich das irgendwo geschrieben?
Wie kommst Du darauf?
>> Was aber nicht bedeutet, dass Funktionalitäten älterer FW-Versionen
>> bei den neueren FW-Versionen nicht mehr verfügbar wären.
>
> ...aber - bei der Art von MS, mit solchen Dingen umzugehen -
> von heute auf morgen nicht mehr verfügbar sein können.
Bei der Arbeit mit .net ist mir bisher nichts abhanden
gekommen.
Wenn es so wäre, würde das dann nicht auch für VB6
gelten?
>> Ich möchte Dich daran erinnern, dass es .net nun schon seit gut
>> 10 Jahren gibt. Bei der allgemeinen Schnell- und Kurzlebigkeit
>> im IT-Bereich würde ich bei einem über 10 Jahre im Einsatz
>> befindlichen Produkt nicht unbedingt mehr von einer Zwischenlösung
>> sprechen.
>
> Für Software sind 10 Jahre nicht kurz,
Das kommt darauf an, wer diese Software wofür einsetzt.
Wie schon erwähnt habe ich einen Anwender der noch
heute mit MS-DOS arbeitet und damit genau das hat,
was er braucht.
Andere Kunden steuern und überwachen mit Hilfe entsprechender
Software Fertigungsprozesse und da sind die Produktzyklen
oft deutlich kürzer als 10 Jahre.
> für Bibliothek(sammlungen) dagegen nicht gerade lang.
> Dann auch noch innerhalb dieser Zeit 6 Versionen bzw.
> Versions-'Absätze' (1, 1.1, 2, 3, 3.5, 4).
Wieviele Versionen und ServicePacks hatten wir denn
bei VBclassic?
>> Das kommt mir ein bisschen so vor, als würde einer
>> sagen, ich bleibe bei DBase, weil Access, SQL-Server, Oracle
>> usw. alles nur Zwischenlösungen auf dem Weg zu einem in der
>> Zukunft liegenden ultimativen DB-System seien.
>
> Du willst hoffentlich nicht die bisherige Lebensspanne von
> .NET mit der von DBase, Access oder SQL vergleichen.
Kann es sein, dass Du mich bewusst missverstehen willst?
Thorsten Albers
> >> kann ich
> >> Inkompatibilitäten sehr wohl ausschliessen.
> > programmierst und keinen eigenen wiederverwendbaren Code
> > einsetzt?
>
> Habe ich das irgendwo geschrieben?
> Wie kommst Du darauf?
Wenn Du wiederverwendbaren Code einsetzt und nicht ad hoc für jeden Auftrag
von Grund auf programmierst, dann kannst Du Inkompatibilitäten des
wiederverwendeten, älteren Codes nicht ausschließen. Ändert sich etwas an
den verwendeten Methoden etc., mußt Du anpassen - sicherlich seltener und
weniger als jetzt und in Zukunft bei VB 6, aber ausschließen kann man in
diesem Fall Inkompatibilitäten grundsätzlich nicht.
> Bei der Arbeit mit .net ist mir bisher nichts abhanden
> gekommen.
> Wenn es so wäre, würde das dann nicht auch für VB6
> gelten?
Hier stellt keiner in Frage, daß das für VB 6 gilt. Ich stelle in Frage,
daß das alles nicht auch - zumindest in gewissem Umfang - für VB.NET gilt.
Natürlich muß man bei VB 6 mit Inkompatibilitäten rechnen und umgehen, für
VB.NET ist das aber auch keineswegs auszuschließen
> Wieviele Versionen und ServicePacks hatten wir denn
> bei VBclassic?
Du willst es nicht verstehen: Kritik an VB.NET bedeutet nicht automatisch,
daß man VB 6 für besser hält. Ich bezweifel nur, daß die aufgezählten
Vorteile von VB.NET so wirklich in ihrer Gesamtheit uneingeschränkt gelten,
und, daraus resultierend, ob der Umstieg von VB 6 auf VB.NET wirklich das
allein Heil bringende ist, ein Eindruck, der auch von Dir erweckt wurde.
Ein 'besser' gibt es tatsächlich zwischen VB 6 und VB.NET nicht, weil diese
beiden direkt zu vergleichen völlig unmöglich ist. VB 6 ist eine
Programmiersprache mit einem eigenen Framework, VB.NET eine Art
'Makro'-Sprache zur Programmierung des .NET-Framework. Das sind zwei völlig
unterschiedliche Dinge, und jeder muß für sich selbst entscheiden, was er
davon tatsächlich benötigt.
> > Du willst hoffentlich nicht die bisherige Lebensspanne von
> > .NET mit der von DBase, Access oder SQL vergleichen.
> Kann es sein, dass Du mich bewusst missverstehen willst?
Nö.
Aber lassen wir diese Diskussion, sie führt zu weit ab vom Ausgangspunkt
und Thema der Gruppe. Für mich EOD.