SebastianB

Hallo,

Fehler gefunden.

ExecInfo.lpDirectory = NULL; fehlt. Ohne es zu spezifizieren verwendet lpDirectory das Arbeitsverzeichniss der Applikation. Dort hatte es keinen Zugriff, folglich die Access-Denied Exception.

Gruß,

Sebastian

Hi,

also ich registriere auch einige meiner Libaries für Com. Diese kann ich auch im Visual Studio unter Com referenzieren. Versuch das ganze mal via CMD, welches du als Admin ausführst. Welche regasm.exe verwendest du? Die aus dem .Net Framework 2.0 oder die aus dem 4.0 Verzeichnis?

Gruß,

Sebastian

Hallo lieber Foren-Gemeinde,

ich habe vor etwas längerer Zeit eine Borland Turbo C++ Applikation geschrieben. Dabei werden verschiedene Setups via ShellExecuteEx ausgeführt. IDE: Borland Developer Studio 2006. Dies stellte bis Gestern kein Problem da. Nachdem ich jedoch an anderer Stelle eine definierte Funktion aufrufe, bekomme ich besagte Fehlermeldung.

Hier der Code zur Funktion:

    

               SHELLEXECUTEINFO ExecInfo;


		ExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);

		ExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS;

		ExecInfo.hwnd = GetActiveWindow();

		ExecInfo.lpVerb = "open";

		ExecInfo.lpFile = InstallPath.c_str();

		ExecInfo.lpParameters = NULL;

		ExecInfo.nShow = SW_SHOW;

		ExecInfo.hInstApp = NULL;

		ShellExecuteEx(&ExecInfo);    // Prozess starten


		while(WaitForSingleObject(ExecInfo.hProcess, 100) == WAIT_TIMEOUT)

		{

			Application->ProcessMessages(); // Nachrichtenwarteschlage verarbeiten

		}

Merkwürdig ist, dass wenn ich vor ShellExecuteEx(&ExecInfo); ein ShowMessage() aufrufe, erscheint die Exception nicht und das Setup wird erfolgreich gestartet. Ein reguläres ShellExecute funktioniert einwandfrei.

Ich würde mich über ein paar Tipps freuen.

Gruß,

Sebastian

Gude,

ist dein Array auch groß genug? Spontan würd mir sonst nur noch ein Fehler des uC einfallen.

Die SerialPort-Klasse ist nicht dafür bekannt Daten zu schlucken.

Gruß

Hi,

Mir fällt hier auf Anhieb auch nicht viel dazu ein. Jedoch kenne ich eine Lösung, die jedoch nicht besonders schön ist.

Versuche die Sleeptime herrunter zu setzen. Vielleicht reicht ja sogar eine sehr geringe Zeitspanne.

Dies allein ist natürlich immer noch unpraktikabel. Frag doch einfach ab, welche Endung die Dateien haben. Wenn es dieser spezielle Fall ist, dann aktiviere die Sleep.

LG

Ich habe alle offen liegenden Maßnahmen schon ergriffen, vom Strom, formatieren etc. Und nein, nur bei dieser Platte. Das seltsame ist, die Platte fliegt beliebig herraus, nicht direkt nach start einer Aktion, sondern immer an verschiedenen Stadien der Übertragung. Habe es auch an mehreren PC versucht.

LG

Hi,

ich hab mir vor einigen Wochen das WD Elements Play zugelegt. Es lief alles super, bis auf letzte Woche. Ich konnte nur noch kleine Dateien ( im KB-Bereicht) auf die Platte ziehen oder löschen. Jedesmal wenn ich also größere Dateien lösche, speicher, etc... wollte, flog die Festplatte raus und wurde nicht mehr angezeigt.

Die Festplatte:

NTFS

1TB

via USB verbunden.

Kennt jemand das Problem und hat evt. sogar eine Lösung?

LG,

Sebastian

Hi,

du hast meine Idee nicht ganz verstanden. Dadurch, das du eine Zeile in deinem GridView mehrfach klickst, kommt es zu diesem Fehler. Wenn du jetzt aber einfach vor dem Starten des BeginEdit() oder EndEdit() abfragst, ob sich überhaupt ein Wert geändert hat, kannst verhindern das das Modified falsch gesetzt wird. Vergleich hierzu den Text der Box und den deines Eintrags der Grid-Column. Ich denke das stört kein Softwaredesign. Ansonsten stimmt deine Fehlerbeschreibung nicht, bzw. ist Sie im wichtigen Bereich nicht genau genug.

LG

Zu deinem ersten Problem: Ich denke das liegt daran das du bei jedem Verlassen der TextBox ein EndEdit() aufrufst. Dadurch wird dann der der Modified-Eintrag gesetzt. Versuch doch einfach mal eine Abfrage einzubauen. In dieser stellst du einfach fest ob sich der Text in der Textbox überhaupt geändert hat.

LG,

Sebastian

Jeff: Hast eine PM.

Ersteinmal danke für die Antwort.

meine Liste hat leider keine Dispose()-Methode...

starte aus VS, habe jedoch gerade die Exe aus dem Debug Order gestartet....braucht ebenfalls nicht die Anfangszeit :-(

C# - Dispose implementieren

Ersteinmal danke für die Antwort.

starte aus VS, habe jedoch gerade die Exe aus dem Debug Order gestartet....braucht ebenfalls nicht die Anfangszeit :-(

Erstell mal das Release-Build und versuche es damit.

LG,

Sebastian

Hi,

startest du das Programm über VS? Oder aus der erstellten .exe?

Hinweis: Liste1.Dispose();

LG,

Sebastian

Du kannst auch einfach in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders einen neuen Schlüssel anlegen, der Standard Wert dieses Schlüssels ist dann der Pfad zu einem beliebigem Verzeichnis.

Wenn die .Net Runtime jetzt nach Assemblys sucht dann schaut sich auch in allen Verzeichnissen die so angegeben wurden. Du musst die DLLs dann nur noch in das Verzeichnis auschecken und fertig.

Hi,

Wäre das nicht das was ich vorgeschlagen hatte, nur per Hand? Wenn eine DLL einmal registriert ist ruft er immer diese auf. Zumindest war es bei meinen Verwendungszwecken so.

Hi,

versuch doch ersteinmal ein Verzeichniss zu erstellen in das du alle nötigen DLLs legst. Danach registrierst du diese einfach, so das bei einem Aufruf genau diese DLLs genutzt werden.

Hierzu solltest du den regsvr32 nutzen, in der Hoffnung das Windows Server 2008 diesen auch unterstützt.

LG,

Sebastian

Hi,

Hat jemand von euch eine Wrapper-Klasse des SysListView32? Oder mal einen Tipp wie ich ohne SendMessage an diese Komponente rankomme?

LG,

Sebastian

Hi,

Auf welchem OS wird der Server den laufen?

LG, Sebastian

Hallo,

@aline:

Ich bin ja bereits fertig mit der Komponente. Hier ist es jedoch besser ein TreeView oder ein ListView zur Visualisierung zu nehmen. Ein GridView ist nocht besonders gut geeignet um Dateien und Verzeichnisse anzuzeigen.

@lilith2k3

Du scheinst immer noch nicht verstanden zu haben worum es geht. Diese Komponente erleichtert dem User erstens das einlesen der Methodendateien, andererseits stellt es sicher das diese auch aktuell sind. Dein Vorschlag grenzt an Gedankenlesen, ich kann ja nicht wissen welche der über 100 Methodenfiles er laden will... Wie mharms schon sagte, stell doch bitte nicht bereits meine Frage in Frage.

Lg,

Sebastian

Hi,

Also das kann ich dem Kunden ja schlecht antun... Er klickt sich erstmal den Finger wund um dann vom Programm gesagt zu bekommen: "Noe, also so nehm ich das nicht an". Der große Sinn und Zweck dieses Dialoges ist, das der User die Arbeit abgenommen bekommt. Ebenfalls ist es so einfach sicher, dass der User nicht einfach mal eine veraltete Datei, in diesem Fall Methode verwendet.

Hi,

vielleicht hab ich mein Problem nicht gut genug geschildert. Es geht darum das der User Datein in ein Programm einlesen muss. Hierbei soll er aber nicht Dateien von irgendwoher nehmen, sondern nur welche die sich in einem bestimmten Verzeichniss befinden. Und das ist weder die Aufgabe von Windows noch von einem Dateisystem! Es geht einfach darum den OpenFileDialog in seiner Freiheit so zu beschränken, das er nur in dem Installationsordner des aufrufenden Programmes genutzt werden kann, oder eher gesagt, nur Dateien in den dort angelegten Unterverzeichnissen öffnet.

Lg

Sebastian

Danke für die Antwort. Habe gestern bereits mit genau diesen beiden Ansätzen begonnen. Macht immer wieder Spaß das Rad neu zu erfinden nur weil an wirklich nützliche Sachen nicht gedacht wird.......................

Lg,

Sebastian

Hallo,

ich benötige einen OpenFileDialog, der nicht zulässt das der User den Root-Folder verlässt. Ich habe bereits die Suche genutzt und keine Ergebnisse erhalten. Nun wollte ich mich an die vielen Quellen hier wenden. Hat jemand bereits Erfahrung in dem Bereich und kann mir weiter helfen? Ich wollte eigentlich nicht den ganzen Dialog neuschreiben müssen. Ableiten vom regulären OpenFileDialog ist nicht möglich, da dieser nicht freigegeben ist.

Lg

Sebastian