VB6: Laufzeitfehler 10 beheben

Von e7 am 22.02.2011, 15:20 in der Kategorie Code-Snippets mit den Tags bug redim, goto, 10, laufzeitfehler, runtime, error, ide, vb6, visual basic,. Kompletten Eintrag zeigen

In Visual Basic 6 habe ich wieder einen Workaround für einen bescheuerten Bug benötigt. Folgender Laufzeitfehler 10 (Runtime Error) tritt bei Redim auf:

Array ist unveränderlich oder momentan gesperrt
This array is fixed or temporarily locked

Bei Microsoft existiert dafür eine Beschreibung, die „triviale“ Lösung lautet:

Avoid using Exit For inside a With statement. A GoTo statement should be used instead.
NOTE: Be sure that the End With statement is executed. If the statement is not executed, you will receive the above error message.

Das heißt, man muss statt bspw. Exit For folgende Krücke verwenden — also jetzt als Alternative zum GoTo, was ja auch nicht gerade so toll ist, aber ebenfalls eine Lösung darstellt:

Dim outOfLoop As Boolean '<--
For I = 0 To UBound(allProperties)
    With arrayName(I)
        If .feld = gesuchterwert Then
            treffer = I
            outOfLoop = True '<--
        End If
    End With
    If outOfLoop Then Exit For '<--
Next I


Interessant ist, dass der Fehler in der IDE nicht auftritt, sondern nur im compilierten Projekt; außerdem scheint man wohl den Code häufiger ausführen zu müssen, bis das Problem auftritt. Auf jeden Fall funktioniert ein ReDim problemlos, wenn ma darauf achtet, dass die Zeile „End With“ grundsätzlich ausgeführt wird.

Man kann sich auch Gedanken über die Architektur machen, die dem VB-Compiler zugrunde liegen muss. Bisher dachte ich, With ist nur eine Art Schreiberleichterung und wird vom Compiler zu normalem Code aufgelöst — scheinbar habe ich da falsch gedacht und er bastelt da noch einiges drum herum.

D-Link... Support? Keinen Bock.

Von e7 am 05.12.2009, 16:21 in der Kategorie Zwischendurch... mit den Tags bug fehlerhaft technik boykott support dlink. Kompletten Eintrag zeigen

Irgendjemand eine Ahnung, wie man bei D-Link Support bekommt? Die guten Leute haben scheinbar recht neu so eine Art Self-Service-Portal eingeführt, das wohl technisch noch nicht ganz ausgereift ist.

Login funktioniert erst, nachdem man sich über Passwort Vergessen ein neues Passwort zukommen lässt, anschließend kann man auch schön brav Supportfälle anlegen. Dummerweise ist allerdings nirgends ein Textfeld, in das man Informationen dazu reinschreiben könnte. Es gibt so eine Art Dateieditor, der behauptet „mit dieser Art von Browser“ ginge das nicht, allerdings kann ich die fast leere Datei immerhin herunterladen. Im Internet Explorer 6 klappt nicht mal der Login, ist also auch nicht zu gebrauchen… Im IE7 klappts dann endlich, nachdem man die Seite den vertrauenswürdigen Seiten zugewiesen hat; der Text wird zwar auch angezeigt, kann aber nicht bearbeitet werden.

Waren das noch Zeiten, als nicht jeder Depp irgendwelche komplizierten Dinger bauen musste, sondern einfach auf normales HTML (und vielleicht ein bisschen JavaScript als Formularprüfung) gesetzt wurde…

Mal schauen, ob es bei D-Link irgendwo noch andere Kontaktmöglichkeiten gibt (mal abgesehen von den teuren Servicenummern). Aber zumindest weiß ich jetzt, von welchem Unternehmen ich mir nie Produkte kaufen werde (mal ganz abgesehen davon, dass die Software auf den D-Link-Produkten scheinbar auch nicht die beste ist)…

Standard beachten und Bugs produzieren...

Von e7 am 08.02.2009, 22:34 in der Kategorie e7o.de mit den Tags standard xml rss verbesserung bug e7o.de. Kompletten Eintrag zeigen

Nun hat's mich selbst ganz böse erwischt: In der Sidebar steht ganz groß „Vollständige Feeds“ für meine RSS-Feed, und dabei wurde immer was abgeschnippelt. Ist damals beim Testen nicht so aufgefallen, da die Einträge immer kürzer waren. Der Atom-Feed enthielt schon immer die vollständigen Einträge; dem RSS-Feed fehlte bisher der komplette <content:encoded>-Bereich. Außerdem hab ich inzwischen von <author> auf <dc:creator> umgestellt, da ersteres eigentlich eine vollständige Mailadresse erwartet. Und <guid> enthält jetzt den (oder zumindest einen) Perma-Link (Notiz an mich: SEO-Links rein…)

Ach ja, und es gibt noch eine große, wichtige Neuerung: Der Feed wird jetzt visuell komplett korrekt ausgeliefert. Man sieht nun keinerlei BB-Codes mehr, diese sollten eigentlich komplett in HTML geparst werden. Zumindest ist mir kein BB-Code mehr aufgefallen.

Außerdem habe ich rechts die Sidebar leicht aufgeräumt und umgeschlichtet. Dabei ist mir aufgefallen, dass ich das mit meinem CMS doch noch mal überdenken sollte — es ist doch schon wieder sehr viel Gebastel und Gefrickel. Vielleicht mal wirklich ordentlich Software Engineering betreiben, samt Wasserfallmodell und irgendwelchen Anforderungsanalysen, Sequenzdiagrammen etc. — was allerdings die Sache ziemlich verzögern dürfte.

Ansonsten nur noch der Hinweis: Jeder, der bisher gezögert hatte, meinen Feed zu abonnieren, kann sich jetzt nicht mehr rausreden. Sauber, korrekt umgesetzt, vollständige Einträge, interessanter Content (hoffe ich zumindest). Den Rest bitte ich auf diesem Wege, einfach mal einen Kommentar zu diesem Blogeintrag zu posten. Ich wüsste nämlich gerne, wie viele aktive Leser (die sogar Blogeinträge wie diesen lesen) es so ungefähr gibt — vielen Dank schon mal :) Feedback ist natürlich ebenfalls willkommen, ebenso welche Themen ich weglassen soll, von was mehr kommen könnte usw.

Und nun: Let's follow :)

Das Schimpfen auf falsch interpretierte Standards...

Von e7 am 05.02.2009, 12:00 in der Kategorie Kopfschüttelnd... mit den Tags bug standard rfc header html http bashing firefox mozilla gecko. Kompletten Eintrag zeigen

Was ist der Unterschied zwischen den folgenden beiden Zeilen?

header(„Content-Disposition: attachment; filename=\"blubb\"“);
header(„Content-Disposition: filename=\"blubb\"; attachment“);

Ganz einfach: die erste Zeile funktioniert, die zweite nicht. Und jetzt die große Preisfrage: Warum ist das so? Eigentlich ist diese Frage noch viel leichter zu beantworten: Es ist so definiert. RFC 2183 gibt nähere Auskunft:

disposition := „Content-Disposition“ „:“
disposition-type
*(„;“ disposition-parm)

Daraus wird eigentlich relativ klar ersichtlich, dass disposition-type (also inline oder attachment) zuerst steht und anschließend die optionalen Parameter auftauchen — was ja soweit auch logisch und nachvollziehbar ist.

Nächste Preisfrage: Wo stehen diese Angaben? Auch ganz einfach: im HTTP-Header.

Nun ist mir allerdings eben die tolle Seite vb-fun.de über den Weg gelaufen. Das Design ähnelt (vor allem in den drei Farbrechtecken oben links) einer berühmten Frontpage-Vorlage und lässt auch dadurch eine gewisse Microsoft-Verbundenheit vermuten. Nun les ich allerdings in deren Downloadhinweisen folgendes:

Bei einigen Software-Firewalls (Norton) und Browsern (z.B. Opera, Mozilla) ist die Übergabe des HTTP-Referrers standardmäßig abgeschaltet.

Ich wüsste nicht, dass mein Mozilla seine HTTP-Requests standardmäßig ohne Referrer bildet. Es gibt Extensions, die das möglich machen, aber default — nein. Soweit allerdings nicht so schlimm — was man nicht einsetzt, kennt man nicht so gut. Vielmehr ist mir das Gecko-Bashing aufgefallen:

Dies passiert, wenn Sie Browser wie den Mozilla oder Firefox einsetzen. Leider ignorieren diese von Ihrer Fangemeinde so hochgelobten Browser beharrlich den HTML-Standard.

Nach diesem Standard gibt es sogenannte HTML-Header. Unser Script versendet gemäß dieses Headers ein Zip-Archiv. Leider sehen die vorgenannten Browser das allerdings etwas anders. Benennen Sie die erhaltene Datei einfach in die von Ihnen angeforderte *zip-Datei um. Beispiel (Datei „Tip.pl“ erhalten, umbenennen in z.B. „tip0210.zip“)

Und jetzt zum Vergleich das, was das Script wirklich sendet:

HTTP/1.1 200 OK
Date: Thu, 05 Feb 2009 10:34:31 GMT
Server: Apache/1.3.37 (Unix)
Content-Disposition: filename="Wellen.zip"; attachment
Content-Length: 55877;
Keep-Alive: timeout=3, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream;

PK(und-jetzt-ca-55875-Bytes)

Wenn wir uns jetzt an unser allgemeines Grundwissen sowie meine vorher aufgeführten Punkte erinnern, könnte es einem dämmern, warum Firefox den HTML-Standard ignoriert.

Erstens: Die Informationen über die Datei befinden sich im HTTP-Header und nicht im HTML-Header. Also kann folglich eigentlich kein Browser die Angaben nach HTML-Standard befolgen — zusätzlich ist das ganze ja eigentlich eine ZIP-Datei.

Zweitens: application/octet-stream ist zwar alles, aber kein ZIP. Funktioniert unter Windows zwar genauso, widerspricht allerdings der Aussage „Unser Script versendet gemäß dieses Headers ein Zip-Archiv.“

Drittens: Wären wir bei der Reihenfolge der Angaben in Content-Disposition. Nachdem hier disposition-type mit filename=irgendwas angegeben ist, kennt das natürlich kein korrekter Browser.

Jetzt ist noch die Frage, warum es im Internet Explorer klappt. Sicher nicht, weil er irgendwelche Standards beachtet. Wohl eher, weil der Internet Explorer alles versucht zu interpretieren…

Mal schauen, wie die von vb-fun.de reagieren. Entweder das Problem löst sich wie von selbst, oder es wird fröhlich weitergebasht. Die Zeit läuft :)

Edit, 13.10 Uhr: Das Problem scheint behoben zu sein, zumindest wird mir jetzt in SeaMonkey der richtige Dateiname angezeigt. Der Satz auf der Website hat sich verkürzt in: Dies kann passieren, wenn Sie Browser wie den Mozilla oder Firefox einsetzen. Das ging ja richtig schnell, wenn auch noch das Stichwort Firefox enthalten ist…