VFP9-Absturz - VisualStudio

Question

Moin,

einsame Stille hier ? Hört mich einer ?:-))

Also mein Kunde sagte mit kürzlich am Telefon das sein VFP (er hat's auch) beim beenden abstürzt. Jetzt schickt er mir mehrere screenshots. Ich beschreib mal: Fensterüberschrift : vfp9(Debuggen) - Microsoft Visual Studio Meldung:Unbehandelte Ausnahme bei....0xC0..5, Zugriffsverletzung beim Lesen an Position 0x0...
Fenster 2: vfp9-Microsoft Visual Studio, Meldung: Die Projektmappendatei C:\program files(x86)\Microsoft Visual Foxpro9\vfp9.sln wurde nicht erfolgreich geschrieben.

Fenster 3 : C:\program files (x6) Microsoft Visual Foxpro9\vfp9.sln kann nicht gespeichert werden. Der Ordner ist schreibgeschützt"

Diese letzte Meldung ist mir relativ klar, aber meine Frage mal,(ich hab nie was mit Visual Studio und Fox gemacht). Ich weiß auch garnicht was der mit Visual Studio zu tun hat. Wie ist das denn verknüpft? Und bekommt man das ohne Neuinstallation wieder hin? Das wird ihm der Firmensysop eingerichtet haben , der versteht aber nix von VFP und ist auch überhaupt kein Freund davon. Mich interessiert hier nur ob das ohne Neuinst reparierbar ist oder nicht ? Schien ja eine Weile gelaufen zu sein ...weiß ich nicht genau. (Das man nicht in dieses Verzeichnis installieren soll weiß ich).

Hat jemand eine guten Rat (den ich weitergeben kann)

Grüsse aus dem endlich schönen WBL

Horst

Answer 1

Hi Horst,

mein Tipp wäre, VFP zu deinstallieren und anschliessend in ein eigenes (nicht C:\Program Files(x86) ) Verzeichnis zu installieren.

Die Program Files Verzeichnissse werden explizit von der UAC überwacht.

Zu diesem Problem gibt es bereits diverse Threads hier im Forum die sowohl von Olaf als auch von wOOdy im Detail beschrieben/erklärt wurden (Einfach mal hier im Forum nach UAC suchen). In Summe läuft es m.E. aber darauf hinaus, das eine Installation jenseits der Program Files die einfachste Lösung ist.

---

Gruss / Best regards -Tom 010101100100011001010000011110000101001001101111011000110110101101110011

Answer 2

Danke Tom,

UAC und Kommentare Olaf / Woody sind mir bekannt. Hatte bei diesem konkreten Fall wegen dem Visual Studio noch gedacht das es evtl. andere Möglichkeiten gibt und zur Sicherheit gefragt, aber im Grunde eigentlich auch an Dir von Dir genannte Lösung gedacht. Ich weiß sowieso nicht was Vis.Stud da soll, das ist kein Entwickler. Aber manche finden es ja toll alles mögliche auf ihrem Rechner zu haben......

Aber ich muss sagen bei dieser Ruhe hier bist Du echt fix  - Super, Danke!

Horst

Answer 3

Eine sln Datei ist eine Solution, das ist in Visual Studio ein Sammelprojekt. Genau genommen etwas, was Foxpro nicht kennt, aber da in VS selsbt kleine Anwendungen typischerweise durch N-Tier Architektur viele Assemblies haben der Normalfall für das Verwalten einer Applikation aus vielen Einzelprojekten.

Kurz ist eine sln also ein Sammelprojekt und trotzdem vergleichbar mit einem PJX.

Das hat mit VFP gar nichts zu tun. Da ist nur jemand auf die sinnleere Idee gekommen ein Projekt im Foxpro Verzeichnis anzulegen. Das sollte man genausowenig tun, wie eine sln in irgendeinem Programm Verzeichnis zu speichern. Standardverzeichnis für Projekte ist unter eigene Dokumente.

Mein Verdacht: Irgendein C5 Fehler in Deiner VFP Anwendung bot dem User an, den VS Debugger zu starten, das sollte man unterlassen, der Debugger kann höchstens auf Assembler Ebene debuggen, aber sinnvolles debuggen setzte VS debug Modus assemblies oder EXEn vorraus.

Dazu kommt nun noch, daß die VS Solution vfp9 genannt wurde. Da wird dann schnell mal VFP9 etwas in die Schuhe geschoben, nur weil eine VS Solution so heißt. Sieht mit Unterstellung ein bisschen nach Mobbing aus, oder alternativ Idiotie.

Tschüß, Olaf.

Answer 4

Super, Danke,

passt alles zusammen. Ich hab den Kunden nun gefragt was er denn nun zum Teufel mit dem VS treibt , aber antwortete mir nur das ihm dieser zum Debuggen angeboten wurde. Ich denke er weiß garnicht richtig das er VS hat und was  er damit machen kann, mal ganz davon abgesehen das er von seinem Wissenstand her damit nix tun könnte. Der Rechner wurde ihm halt eingerichtet, ich beschrieb es schon. Gestern hat er es aktzeptiert das wir das neu installieren und das werd ich schön nach einer bekannten Anleitung tun und basta. Warum aber der Installatöör als VFP-Feind überhaupt was mit VFP tut...dz dz dz. Nun ja, denken wir mal nix Böses...

frohes Entwickeln

Horst

Answer 5

Hallo Horst,

das sollte der Visual Studio Debugger sein der zuschlägt wenn ein Programmabstürzt. Visual Foxpro wurde mit c++ geschrieben.

Dementsprechend schlägt die aktuelle Version dieses Compilers zu und bietet das Debuggen an.

Der C0000005 ist die Foxpro übliche Speicherverletzung.

Das ganze funktioniert trotzdem erst wenn das Visual Studio auf deinem Kundenrechner installiert wurde.

Die SLN-Datei versucht das Studio zu schreiben da ihm nicht klar ist das hier ein Projekt ohne Sourcen daherkommt.

Fenster 1 ist dein Bereich in dem ein try catch Block Linderung verschaffen sollte die anderen beiden Fenster solltest Du ignorieren.

Grüße Alexander

Answer 6

Hallo Alexander,

doch keine einsame Stille und ein paar Unentwegte. Das ist schön! Danke Dir für Deine Erklärung. Warum hat sich denn bloss mein VS noch nicht gemeldet, aber das passiert denn wahrscheinlich auch bloss bei schwerwiegenden C...5 Fehlern. Naja sowas mache ich ja nicht :-)))).(und s. Olaf). Okay, der Fox-Fehler interessiert mich auch nur am Rande - ich bau da (auf Auftrag) ständig neue Sachen in das Projekt und das läuft halt nicht immer sofort rund. Da wird sich irgendwas finden und beheben lassen. Nur bei diesem neuartigem Fehler ist das Geschrei halt gleich groß. Nun gut, ich treff ihn demnächst persönlich (den Kunden , nicht den Fehler) und dann werd ich mir mal anhören warum denn nun VS bei ihm installiert wurde. Bin neugierig was ich alles sehe und höre.

Grüsse aus dem sonnigen WBL

Horst

Answer 7

Ja, war ja auch u.a. ein Verdacht, mit dem Debugger. Ich frage mich nur, warum der nun wiederum versucht eine solution (.sln) anzulegen, aber gut.

Was mir gestern noch einfiel ist, daß eine Verknüpfung zum Foxpro Ordner durchaus berechtigt ist, wenn man ein FLL Projekt aufsetzt und dafür die Dateien aus Samples/API benötigt. Aber das würde wiederum die .sln nicht erklären. Da würde man nur ein paar Verweise auf pro_ext.h und winapims.lib haben, im VS Projekt.

Vermutlich benötigt der Debugger eine Solution und legt sie einfach im Verzeichnis der abgestürzten Komponente an, aber das ist auch wieder nur geraten.

Nee, ist schon ok, daß man sich da nicht gleich Böses denkt. Das mit der Idiotie ziehe ich mal aus Höflichkeit Deinem Kunden gegenüber zurück. Die Neugier siegt zumindest einmal. Oder auch der Reflex. Man weiß ja nicht, was man anstartet, wenn man mal arglos zustimmt, einen Fehler zu debuggen.

Tschüß, Olaf.

Answer 8

Hallo Horst,

da ich grad bei Tests häufig die C..5-Fehler habe, sehe ich dauernd die Frage nach dem VS-Debugger. Werfe ich den tatsächlich an, sehe ich Assembler-Code. In meinem Projekt-Verzeichnis entsteht eine .SLN und eine .SUO-Datei.

C..5-Fehler lassen sich übrigens sicher reproduzierbar auslösen, indem man in einer Grid-Column-Controlsource per UDF irgendwas nicht korrektes macht.

Übrigens lassen sich C..5-Fehler, so meine Versuche, nicht per TRY..CATCH vermeiden (außer natürlich die, die durch Folgefehler entstehen).

Gruß,

Winfried

Answer 9

Kein Problem mit der Idiotie! Zumindest bleiben ja ein paar Fragezeichen. Das größte ist für mich nach wie vor warum er denn überhaupt VS drauf (eingerichtet bekommen) hat. Der arbeitet im browse-Modus, kann mit browse for arbeiten und kleinere Progrämmchen stricken und fertig. Aber VS? Sinnlos. Mein Projekt dadrauf brauch nix davon.Warum ich nicht gleich Böses denken will ist einfach das dort manchmal Dinge drauflos gemacht werden ohne das man groß nachdenkt. Aber bei der Abneigung die mancherorts gegen den Fuchs besteht könnte man schon auf faule Gedanken kommen.

schöne Pfingsten Dir

Horst

Answer 10

Hallo Winfried,

nett Deine Hinweise! ich hab den C..5 Fehler eigentlich nie (Vielleicht arbeite ich nicht intensiv genug :-) ) .,trotzdem wer weiß, manchmal ändern sich ja die Zeiten. In diesem speziellen Fall ist das ein Programm für einen einzigen Menschen. Ich als Entwickler habe da keinen Fehler , der Kunde ja. Aber wir kommen bald zusammen und dann schaun mer mal was denn alles drauf  ist und dran ist. So dramatisch sieht der Code an der Stelle nicht aus :-))

Das sich sowas nicht mit try...catch lösen lässt ist ja eigentlich irgendwie logisch oder ? Ich denke das bei sowas die Kiste einen richtigen Sprung ins Nirwana macht und demzufolge auch nicht mehr zum catch zurückkommen kann. Ist etwas unbeholfen ausgedrückt aber....

Aber danke Dir erstmal

Horst

Answer 11

Moin, moin

C0005 habe ich bei Programmfehlern eigentlich nie, die trten m.E. nach auf bei defekter Foxuser.dbf/dbt (Resource off in der config.fpw wirk da wunder) oder bei defekten CDX Dateien (z.B. durch Programmabbrüche bei Zugriff durch Fremdprogramme :-))

HTH

Grüße

tom