>> 1. Das problem ist, dass meine ganzen anderen Programme auch OHNE diese MS.VB.DLL funktionierten. Warum sollte ich für etwas banales wie ein
>> kleinen Programmcode, den ich umschreiben muss, ne DLL includen? ... und dann auch noch der Gefahr laufen, dass der code garnicht läuft. (hab ich
>> schon mehrfach unter SharpDevelop erlebt).
Das kann ich mir gut vorstellen. Das gleiche Problem hättest du ebenfalls mit/unter Vs.Net und/oder #D2, zumindest dann, wenn nicht per default in der IDE ein Verweis auf die Dll gesetzt wird. Es ist aber grundsätzlich - problemlos - möglich, unter Vb.Net ohne dem Assembly Ms.Vb zu entwickeln. Für fast jede Vb-spez. Methode/Klasse gibt es ein entsprechenden .Net-Ersatz/Pendant. Problem ist nur, wenn du Vb.Net Code benutzen möchtest, der Aufrufe wie MsgBox(), InputBox(), IsNumeric(), Len() et cetera enthält, musst du entweder, A.) den Code umschreiben oder B.) eine Ref. auf das o.g. Assembly setzen. Andere Möglichkeiten gibt es quasi nicht. (lasse mich gerne eines Besseren belehren  )
>> du hast den Grund schon erfasst. Ich nutze aus gutem Grund #D1, da in SharpDevelop 2.0 mehr als 40 Befehle, die ich nutzte, nicht funkionierten.
Hm, falsch! Nicht in #D (!!), sondern im FW fehlen bestimmte Methoden! Wie gesagt, #D ist nur eine IDE (ein Frontend/GUI usw.), mehr nicht. Es speilt ÜBERHAUPT keine Rolle mit welchen Programm/Editor man unter .Net entwickelt. Das .Net FW, und nicht die Entwicklungsumgebung gibt Dir vor welche Möglichkeiten du letztendlich hast.
Die IDE ist quasi die Schnittstelle, der "Vermittler" zwischen dem Compiler und dem Benutzer/Entwickler, eine GUI für den Compiler, ein hilfreiches Werkzeug, dass dem Benutzer einiges an Arbeit abnimmt. D.h. zB.: Compileraufrufe, Refs. verwalten, gr. Oberfläche mit dem Designer kreieren, Db-Connects erstellen usw. - keine Frage, das ist wirkliche feine Sache! Das Ganze hat aber einen gravierenden Nachteil: der Entw. weiss meistens nicht, was "hinter" der Oberfläche passiert/abläuft. Schade finde ich, dass die meisten Einsteiger das auch garnicht erst wissen wollen was "unter Haube" abläuf, denn es trägt ihmo sehr zum Verständnis von .Net (und auch anderen technischen Systemen) bei! Und nicht falsch verstehen; es ist schon okay mit einem Designer zu entwickeln. Ich möchte ja auch keine GUI mehr mit Notepad erstellen. Nur einmal sollte man sich das System "hinter" der IDE anschauen. Der Lernfaktor ist dabei echt enorm!
Bei anderen Programmiersprachen/Frameworks, wie bspw. Java, Qt oder Python ist das übrigens ähnlich bzw. 100%ig genauso, was die IDE und das darunterliegende FW angeht.
Naja, zurück zum eigentlichen Thema...
Also, ich kann mir das nur sehr schwer vorstellen kann, dass bestimmte .Net 1.x "Befehle" im FW 2.0 fehlen. Hast du vllt. ein Beispiel für uns? Damals, bei der .Net Version 1.1 wurde zwar vieles geändert und einige Befehle usw. wurden umbenannt, aber beim Update von 1.1 auf die Version 2.0 war das nicht der Fall. Das .Net 2.0 FW ist theoretisch auch abwärtskompatibel.
>> Er sagte mir bei einer Long-Variable, die ich übergeben hab, dass die Longvaribale nicht zulässig wäre als Übergabewert einer Funktion, die eine Long-
>> variable erwartete ... Fand ich echt witzlos.
Ich denke du verwechselst hier was. Vermutlich hat die Methode ein Integer, Double o. Long erwartet, und du wolltest lediglich ein Long o. Integer übergeben. So wie sich das anhört, war Dein Code nicht 100%ig typensicher. Vermutlich ist in #D 2.0 die Compileroption Strict und Explicit standardmässig aktiviert (was auch völlig richtig ist), mehr nicht. Daraufhin hat sich der .Net Compiler bei Dir über den fehlerhaften Code beschwert. In Vs.Net sind soweit ich weiss diese beiden Optionen nicht eingeschalten. Warum auch immer...
>> Außerdem ist #D2 zu kompliziert zu steuern. Ich habe bis heut nicht rausgefunden,
Findest du? #D2 ist anders als #D1, das ist klar, aber nicht komplizierter wie ich finde. Es ist allerdings etwas umfangreicher geworden.
>> wie man anstelle des Debug-Modus in den Release-Modus kommt.
Einfach im Menü unter "Erstellen" > "Konfiguration festlegen" entweder den Modus Debug oder Release auswählen. Das wars.
>> Oder wie man ein Icon an ein Projekt heftet, sodass die Exe-Datei dieses Icon hat. Sind alles so Gründe, warum ich #D2 nicht nutze.
Ebenfalls einfach:
Projekteigenschaften aufrufen, Tab Anwendung auswählen. Im Bereich Anwendungsicon kannst du ein Icon auswählen. |
Forenübersicht Suchen Forumsregeln
Juni 2024
Sie sind aktuell nicht angemeldet.
