Hallo Reinhard,
Abwink, mir was zu erklären schafft keiner 
)
Abwarten, man sollte die Hoffnung nie aufgeben
Also ist VB9 nicht wie bei VB5 zu VB6 eine neuere Version mit
mehr Features sondern was völlig anderes in der Struktur.
Es gab die Versionen bis zur 6. Sie waren vom Syntax her gleich.
Danach kam das Visual Studio. Ergo .NET , das gibt es ja was weiss ich in der 2005 Version und ich hab die 2008 Version. Das VB dort nennt sich VB9! VB5 zu VB6 ist wie Visual Studio 2005 zu Visual Studio 2008.
Es hat sich nur der Syntax erweitert. Vieles wurde einem abgenommen und es kam ein neues Framework heraus 
Ja, von VBA (Excel) her.
Fein
Wie das in VB6 geht weiß ich nicht, in Excel sind die DLLs
dabei.
Siehst und du hast unter VB 6 einmal die Runtimes. Diese beinhalten auch DLL’s. Dann gibt es noch welche die eh auf dem System vorliegen!
Dann gibt es aber wiederrum spezielle die kein Bestandteil von Windows sind. Wenn man diese nun in sein Proggi einbindet, so musst du sie mit ausliefern! Sie muss dann auch auf dem entsprechenden Rechner Registriert werden Aber das macht meistens das Setup!
Ich deute das jetzt so, bei VB6, Vba müssen die dlls auf dem
Rechner installiert sein, bei .NET dieses Framework.
Da sehe ich noch keine Verbesserung bzw. Vorteil für .NET.
Richtig! Versuchst du eine Anwendung die unter .NET erstellt wurde zu installieren und hast das Framework nicht drauf, so wird gleich gemeckert und du kannst es nicht installieren. Ich glaube du bekommst da sogar gleich einen Link angezeigt, wo du dir das Framework runterladen und installieren kannst. Oder das Setup macht das gleich mit *gruebel* Muesste ich eigentlich mal nachschauen
Eine deutliche Verbesserung ist schon. Bsp. es ist eine Anwendung schon vorhanden. Diese soll erweitert werden um eine Function X. Nehmen wir mal an. Bei einem Fehler soll eine Mail gesendet werden.
Was macht man. Unter VB tippelt und tippelt man und greift wiederrum auf vielleiht andere DLL’s zu. Ergo muss man für die Aenderung, wieder ein komplettes Setup ausliefern 
da die DLL’s ja registriert werden muessen und man vom Anwender net verlangen kann, das er das selbst macht Unter .NET -> 3 Zeilen Source und volla fertig Die benötigten Klassen sind im Framework enthalten und muessen nicht nocheinmal mit ausgeliefert werden! Es reicht als , einfach das reine EXE File weiterzureichen
Auch ein enormer Unterschied ist die Ausführungsgeschwindigkeit. Aber darueber habe ich dir vorhergehenden Posting schon etwas geschrieben
Ich deute das so, in Frameworks kann ich leicht ermitteln
welche Klassen es da gibt und die Inhalte ermitteln.
Nur, wenn ich die Bildschirmauflösung ermitteln will, bei API
MUß ich wissen daß das mit GetWindowSolution (*gg* erfunden)
geht,
in Framework auch, also wie kriege ich raus welche
Frameworkklasse ich benutzen muß um die Bildschirmauflösung zu
bekommen?
Auch da gibt es wieder viele Wege :s
Nur mal um einen zu nennen
Ein simples Bsp. Wir nehmen mal wieder den Batterystatus
Wie geht man am duemmsten vor?
Man nehme den Objectbrowser und gebe als Suchbegriff „Battery“ ein
In den vielen Ergebnissen sehe ich nun
System.Windows.Forms.PowerStatus.BatteryChargeStatus() As System.Windows.Forms.BatteryChargeStatus
dabei achten wir auf "BatteryChargeStatus() , volla das ist doch genau die Information die wir brauchen Also klicken wir das nun an!
Wir sehen dann die Definition!
Public ReadOnly Property BatteryChargeStatus() As System.Windows.Forms.BatteryChargeStatus
Member of System.Windows.Forms.PowerStatus
Summary:
Gets the current battery charge status.
Return Values:
One of the System.Windows.Forms.BatteryChargeStatus values indicating the current battery charge level or charging status.
Wie wir nun sehen, ist der Namespace System.Windows.Form und der Member Powerstatus!
Eine Eingabe, alla system.Windows.Forms.Powerstatus bemaengelt .NET natuerlich, weil er den Member nicht kennt 
Also gehen wir zurueck zu .NET und geben mal Powerstatus ein und druecken F1 ( die Hilfe)
Dort finden wir dann gleich als erstes, folgenden Eintrag
PowerStatus Class (System.Windows.Forms)
Indicates current system power status information. ... The PowerStatus class represents information about the current AC line power status, battery charging status, and battery ...
Ha, genau da suchen wir ja. Also klicken wir dieses an
Wir bekommen nun die Klasse Powerstatus angezeigt
Das alles interessiert uns ja erstmal nicht
Wir scrollen mal ganz runter zu den referencen
Dort finden wir folgendes
Version Information
.NET Framework
Supported in: 3.5, 3.0 SP1, 3.0, 2.0 SP1, 2.0
See Also
Reference
PowerStatus Members
System.Windows.Forms Namespace
PowerStatus
SystemInformation
PowerLineStatus
BatteryChargeStatus
PowerState
Wie unschwer zu erkennen ist, bedarf es dem Framework 3.5 etc.
Auch sehen wir da nun eine weitere wichtige Info.
„SystemInformation“ und genau das ist das Stichwort!
Wir klicken das mal an
Provides information about the current system environment.
Namespace: System.Windows.Forms
Assembly: System.Windows.Forms (in System.Windows.Forms.dll)
Syntax:
Visual Basic (Declaration)
Public Class SystemInformation
Visual Basic (Usage)
Dim instance As SystemInformation
Nun haben wir eigentlich Daten die wir brauchen
Also machen uns ans Werk!
Wir importieren die System.Windows.Forms
uns steht Systeminformation zur Verfuegung und dann ergo auch der Member PowerStatus und deren Eigenschaften.
imports System.Windows.Forms
systeminformation.Powerstatus.DieGewuenschteEigenschaft
oder halt
System.Windows.Forms.Systeminformation.Powerstatus.Eigenschaft
das alles hört sich alles ein wenig verzwickt an, ist aber eigentlich nicht. Es Bedarf nur ein wenig Übung
Jaaaaaaaaaa )))
Aber so schlimm sind die nicht Man muss nur die Zusammenhaenge sehen, dann erklaert sich vieles von allein
Das ist ein guter Anfang, könnte aber sehr lang dauern *gg*
Naja schauen wir mal
Bis ich das alles kapiert habe brauche ich länger als die
Installation.
*feix* naja solange dauert die nun wieder auch nicht. Bei mir war es glaube sowas an die 20 Minuten
Das klingt gut, aber wenn man nur 32Bit Operationen hat, was
habe ich da von 64Bit?
Wenig, Was nuetzt dir ein Porsche auf einer 30 'er Zone?
Es kommt immermehr das blöde Vista. Vista ist 64 Bit basiernd
und ergo werden dann auch die Programme dafür ausgelegt!
Du selbst arbeitest ja auch schon mit einem 32 Bit Zahlensystem!
Auch hast du unter .NET den sogenannten uLong Datentyp und der ist 64 Bit basierend!
Ich drücke euch beiden die Daumen, die Programmiersrache zu
finden die für euch am Besten ist.
Naja ich habe mich entschieden, das ich umsteige. Auch wenn es verdammt schwer ist / wird. Aber ich habe VB geschafft und dann werde ich .Net auch schaffen. Egal wielange es dauert und was es für Nerven kostet! Das schoene daran ist, ich lerne auch heute noch Sachen, die ich in VB machen kann und nicht wusste :s
Wusstest du das man Parameter die man mit Byval uebergibt, dennoch in einer Sub aendern kann ? Das war mir neu, aber es geht
Und wenn in diesem Framework 8000 Klassen sind, da müssen doch
ein paar Klassen sein um zum Bleistift hier den CommunityChat
permanent auszulesen und auch da mal was reinzuschreiben
*lächel*
Puh, ich denke mal das es dafür sicher eine Lösung gibt. Man muesste nur die zeit haben, das alles mal zu testen :s
Anscheinend fehlen da bei VB6 paar APIs die das können:frowning:
Ich denke mal nicht. Es ist nur eine Frage des Aufwandes!
Man hat ja eine Textzeile! man kann das Fenster bestimmen und dies dann aktivieren, dann kann man einen Text senden
Zum Auslesen. Hmm, ich würde einen Thread basteln, der stetig das Fenster abfragt und wenn sich was geaendert hat, dann volla, auslesen und anzeigen
Du hast es super versucht, aber auf verdörrtem Boden wächst
selten ein Baum der Erkenntnis, ich sehs jetzt so, bei .NET
muß man, vielleicht in der Exe versteckt, das framework
mitausliefern.
NEIN! Ist es bei Dir nicht installiert und du magst einen Anwendung installieren die mit .NET geschrieben wurde, so musst du genau 1 mal das Framework installieren und dann nie wieder! Das Framework selbst kannst du dir dann aus dem Netz laden. Ist ja kostenfrei
Bei VB6 halt die DLLs, auch da zur Not in der Exe versteckt.
Und wenn in beiden Fällen das Verstecken nicht geht, dann halt
das Framework extra mitschicken, bzw. die DLLs.
Machbar ist alles. Wozu gibt es unter VB6 Ressourcen *zwinker*
Und, eine vielleicht blöde Frage,
im uraltBasic gabs die Anweisung Circle(50,60,100).
Dadurch wurde um die Bildschirmkoordinaten x=50, y=60 ein
Kreis mit dem Radiaus 100 gezeichnet.
Durch den Start des Basicprogramms wurde es interpretiert,
also in Assemblercode umgesetzt, der dann ausgeführt wird.
Wenn ich nun in VB6 oder .NET auch sage, zeichne mir einen
Kreis, dann wird das doch in den gleichen Assemblercode
umgestezt, also ist doch dann .NET, VB6, uraltBasic gleich
schnell.
Lassen wir mal Interpreter und Kompiler weg *gg*
NEIN und den Compilier koemma net weglassen :s
Unter VB6, ist es richtig. Da dort MaschinenCode erzeugt wird der auf allen Maschinen laufen muss. Unter .NET liegt der Source nur im IL vor, welches dann der JITTER bei Bedarf erst compiliert und den Source , der CPU anpasst!
Ich hoffe ich habe dir mein Unverständnis verständlich sagen
können:smile:
Gruß
Reinhard
MfG Alex
