Hallo VB-Gemeinde,

ich beschäftige mich seit einigen Wochen intensiv mit VB.
Meine Erfahrung ist allerdings beschränkt, ich habe mir die benötigten Informationen entweder aus der MSDN oder hier im Forum geholt.

Meine Software ist fertig und funktioniert innerhalb des VS2010 super
Allderings scheint irgendwas beim "veröffentlichen" schief zu laufen.
Die Software wird erstellt und kann sowohl installiert wie auch gestartet werden.

Nur bekomme ich bei bestimmten Funktionen eine exception bezüglich ungültiger Typkonvertierungen,
wie gesagt aber nur bei der fertig veröffentlichten Software.
Innerhalb von VS2010 habe ich die Fehler beim Debuggen nicht.

Ich schätze ich habe versehentlich in den Projekteinstellung irgendwas verändert, so dass der Kram
später so nicht funktionieren kann.

Vieleicht hat jemand ne Idee an welcher Stelle ich suchen kann oder was fehlt...


Danke im Voraus
Casey Burns

Willkommen im Forum.

CaseyBurns schrieb:

an welcher Stelle ich suchen kann

Startest Du die abstürzende Version auf Deinem Rechner?
Wenn nein: Tue es.
Ja: Sind bei der installierten Version alle erforderlichen Dateien dabei?
Greifst Du auf eine auf dem PC installierte Komponente zu?
Was passiert, wenn Du das Programm in der Entwicklungsumgebung mit Strg+F5 startest (ohne Debugger)?

Der Fehler kann an tausenden von Stellen liegen - immerhin wissen wir, dasses sich um einen Typkonvertierungs-Fehler handelt.

Programmierst du Strict Off?
Das wäre sehr schlecht, denn dabei ereignen sich u.U. sehr sehr viele TypKonvertierungen, die man im Code gar nicht als solche erkennen kann.
Das Problem mit denen ist 1) sie sind verborgen 2) sie sind meist überflüssig, wenn man stattdessen gleich einen angemessenen Typ genommen hätte.
Und 3) sind Typkonvertierungen generell Anti-OOP und unsicher, denn sie setzen sich punktuell über die normalen Sprachregeln einer typsicheren Sprache hinweg.
Das kann gut gehen - muss es aber nicht.

Lange Rede kurzer Sinn: Option Strict On!

(Falls du es schon hattest ist dieser Post gegenstandslos)

Hallo RodFromGermany,

erstmal Danke für die schnelle Antwort.

Ich habe die Software sowohl auf dem Rechner, auf dem die IDE installiert ist, wie auch auf einem anderen Rechner gestartet.
Bei beiden Rechnern ist das Verhalten identisch. Beim anderen Rechner musste ich noch die PowerPacks nachinstallieren, war
aber kein Thema.

Mit STRG-F5 passiert genau das selbe wie mit der "fertigen" Software.

Ich Arbeite eigentlich nur innerhalb der IDE und dachte VS2010 wäre dann schlau genug mir bei der veröffentlichung meiner Software
die entsprechenden Daten mit ins Verzeichnis zu legen oder dafür zu sorgen dass bei der späteren Installation benötigte Software
entweder mit installiert oder entsprechend aus dem Netz gesaugt wird.
Aus dem Netz saugen hab ich schon in anderer Software gesehen (hatte irgendwas mit SQL zu tun, wegen Datenbank).

Die Frage ob alle Daten dabei sind kann ich also nur mit "hoffentlich" beantworten.

Ich greife an einer Stelle im Quelltext auf eine "user32.dll" zu.
Dabei geht es sich um das Mitscrollen einer Richtextbox in Bezug auf das scrollen einer anderen.
Den Codeschnipsel hab ich aus der MSDN, wo genau die Problematik erläutert wird.
Ich verwende das um Zeilennummern in einer Richtextbox zu sehen, die beim Scrollen mitlaufen.

Allerdings funktioniert das auch einmalig gut...
Ich vermute wie gesagt, dass irgendeine Einstellung in den Projekteinstellungen nicht stimmt.

ErfinderDesRades schrieb:

Programmierst du Strict Off?

Und was ist damit?

Hallo ErfinderDesRades,

Danke für den Hinweis.
Ich habe folgende Einstellungen überprüft bzw. Angepasst:

- option Explicit: on
- option Strict: on
- option Infer: off
- option Compare: binary

Das führt natürlich dazu, dass der Code sehr präzise werden muss, wass mir grundsätzlich sehr zusagt!!!
Ich werde jetzt erstmal ein Review des gesammten Quelltextes durchführen, um die >100 Fehler zu beseitigen.

P.S. Danke nochmal für den Beitrag: DataSet only - Datenbankprogrammierung ohne Datenbank
Ich verwende gleich zwei DataSets in meinem Programm, eins für Laden und Speichern von Projekten,
ein zweites als permanente Datenbank.

OffTopic:
Warum mir präziser Quellcode lieber ist?
Ich programmiere u.A. auch 8-Bit Mikrocontroller in C++ (Bit-Schubsen Professional).
Präzision ist da alles! Ein Bit falsch gesetzt und der Controller macht irgendwas, nur nicht das was man möchte.

Ich habe allerdings überhaupt keine Erfahrung in C++ für Windows,
aber kannte vor diesem Projekt Grundzüge von VB.
Also habe ich den einfachen Weg gewählt und mich für VB für den PC und C++ für Mikrocontroller entschieden.
Irgendwann werd ich bestimmt umschwenken, aber jetzt ist erstmal die Software wichtig!!!

CaseyBurns schrieb:

- option Infer: off

Setz sie auf ON, erleichtert dir das Leben
Gerade bei Datasets...

LG von der ehemaligen Bit-Schubserin

ok, wenn strict on ist, dann gehts ans fehlerle suchen: kriegst du die genaue Fehlermeldung inklusive StackTrace?

Da werden ja die beteiligten Datentypen genannt, und auch die CodeZeilen, wo der Fehler auftritt.

Die entsprechenden Codezeilen werden jetzt direkt im Quellcode angemeckert,
ich werden erstaml etwas dran zu arbeiten haben...

CaseyBurns schrieb:

werden jetzt direkt im Quellcode angemeckert

Genau das ist der Plan.

CaseyBurns schrieb:

Meine Erfahrung ist allerdings beschränkt, ich habe mir die benötigten Informationen entweder aus der MSDN oder hier im Forum geholt.

Am besten dieses Buch lesen (hingegen das Galileio-Openbook ist Mist)

Ist auch kostenlos.

CaseyBurns schrieb:

Die entsprechenden Codezeilen werden jetzt direkt im Quellcode angemeckert,
ich werden erstaml etwas dran zu arbeiten haben...

Die meisten, die damit konfrontiert sind, folgen einfach den Vorschlägen der IDE, und machen ein CType drumrum.

Das ist aber nicht Sinn der Sache. Denn dadurch machst du aus einem verborgenen Unfug nur einen offensichtlichen (was zugegebenermassen ein Fortschritt ist, aber keine Lösung).

Die Lösung besteht darin, in Fällen von Type-Mismatches zu überlegen, welches die richtigen Typen wären, die an diese Stelle zu verbauen wären.

ZB ist gut möglich, dass bereits deine Datasetse failen, weil Spalten mit Datentyp String angelegt sind, die eiglich Zahlen beinhalten sollen.
Weil zum Rechnen sind Zahlen da, keine Strings.

@ sonne75:
Werde einiges Nachholen (lesen) müssen. Danke für den Hinweis!

@ErfinderDesRades:
Stimme zu!
Die ggf. nötige Umwandlung von Daten in das passende Format hat vor Zuweisung zu geschehen.
Ich als Programmierer habe keine Ahnung, was der DAU vor dem PC mir später an Informationen
zur verfügung stellt. Bedeutet ich als Programmierer bin dafür verantwortlich dass Fehleingaben
zu einer MsgBox führen, die darum bittet die Informationen richtig anzugeben.
Beispiel: TextBox -> Single

Die Informationen, die in die DataSets geschrieben werden sind bisher nur Strings und Single Datentypen.
Natürlich kommen da auch nur solche Daten hin!

Ich habe bereits jetzt viele stellen im Quellcode, die ungefähr so aussehen:


Ich hätte mich besser vorher damit auseinandergesetzt...

[VB.NET] TryCatch ist ein heißes Eisen

Dafür gibt es Single.TryParse() statt CSng():

msdn.microsoft.com/de-de/libra…yparse%28v=vs.110%29.aspx

und vorrangig ist zu gucken, dass der TempString ühaupt nicht auftritt. Warum kann das nicht von vornherein ein Single sein? Vlt. ist das ja möglich.

Ich habe bei der ganzen Fehlerkorrigiererei eins vergessen:

Auch wenn option strict off ist, müsste eine fertige Software doch eigentlich so laufen, wie im Debugging...
Oder bin ich da jetzt voll auf dem Holzweg
Sonst wäre option strict ja unsinn und müsste permanent on sein :pinch:

Werde morgen früh mal mein Backup von vor den Änderungen wiederherstellen.
Wieleicht hat ja einfach irgendwas nen knacks.

Klingt vieleicht :wacko: , aber vieleicht hilft einfach neues Projekt anlegen,
Forms und Quelltext importieren und sehen was passiert.
Einen Versuch ist es wert.

Natürlich ist der Quelltext weit von *ErleuchtungBeimDraufschauen* entfernt aber würde erstmal laufen,
bis der überarbeitet ist. Habe bis jetzt nicht gehört, dass ich nicht V2.00 erstellen dürfte.

Greez
CaseyBurns

CaseyBurns schrieb:

ungültige Typkonvertierungen

würden sich bei Strict On eben von alleine erledigen.

Und es kann sein, dass dieses Hintenrumgeradebiegen von Strict Off eben nicht immer so funktioniert, wie im Debugging.

CaseyBurns schrieb:

Sonst wäre option strict ja unsinn und müsste permanent on sein

Genau so ist es ja auch. Option Strict ist ein Überbleibsel aus alten Zeiten, als man noch mit VB6 programmiert hat. Als Microsoft den Support dafür vollständig eingestellt hat, wurde die Funktionalität kurzerhand in das gerade neu entstandene VB.Net reingequetscht. Beachtet haben sie dabei aber nicht, dass das ganze Zeug eigentlich überhaupt nicht mehr in die Sprache passt und somit jetzt leider viele neue Programme immer noch so geschrieben werden wie die alten. Bei allen anderen Framework-Sprachen (z.B. C#) gibt es sowas überhaupt nicht, da muss man immer typsicher programmieren, und das ist auch gut so. Deshalb muss Strict immer auf On bleiben, ansonsten braucht mans gar nicht erst zu versuchen.

Es kann sein, dass der Debugger dir bestimmte Exceptions als "first chance" einfach durchgehen lässt, auf Release kompiliert knallts dann aber, musst mal in die Ausgabe-Console schauen.

CaseyBurns schrieb:

Auch wenn option strict off ist, müsste eine fertige Software doch eigentlich so laufen, wie im Debugging...

stimmt.
Strict On führt ganz allgemein zu saubereren Code, und reduziert insbesondere die Anzahl der TypKonvertierungen.

Ist gewissermaßen eine General-Überholung, und u.U. ist anschließend sogar der Fehler verschwunden, ohne dass er ühaupt explizit gefunden wurde. Ist aber eher unwahrscheinlich.

Aber man kann dem Fehler ja auch gezielter nachgehen - lies doch nochmal post#8.

Generell tippe ich drauf, dass dem veröffentlichten Proggi irgendwo annere Daten serviert werden, die nicht verarbeitbar sind.
Der eigliche Fehler kann sein, dass die Daten falsch generiert wurden, dass falsch gefiltert wird, oder dass die Daten schlicht hätten abgelehnt werden müssen. Ein beliebter Fehler ist auch, dass kulturabhängige Systemeigenschaften nicht berücksichtigt wurden.

Wie gesagt: Näheres sollte die Fehlermeldung ausspucken.