Klotzkopp

Das lässt sich leider nicht mit unseren Boardregeln vereinbaren -> Thread geschlossen.

Die Unterschiede dürften hier minimal sein. Mein Vorschlag: Du schreibst das Programm in C++, und wir schreiben es dir hier nach C um. Wie klingt das?

Ganz nebenbei: Der letzte else-Block in initDLL wird sowieso nie ausgeführt, weil du schon vorher aus der Funktion rausspringst, wenn hinstLib NULL ist. Das zugehörige if ist danach immer wahr, kann also auch wegfallen.

Ist dir klar, dass du die DLL in deiner initDLL-Funktion zweimal entlädst? Wenn du nur einen der beiden FreeLibrary-Aufrufe entfernst und den anderen drinlässt, ist klar, dass du die DLL neu laden musst. Ansonsten zeig doch bitte mal den Code, der nicht funktioniert.

Das heißt, GetProcAddress schlägt fehl? Was sagt denn GetLastError dazu?

Was heißt denn "du musst"? Was passiert denn, wenn du es nicht tust? Und antworte bitte nicht mit "dann funktioniert es nicht" , denn...

Nein. Wäre auch sinnlos. Virtual bedeutet, dass über den dynamischen Typ des zugehörigen Objekts zur Laufzeit ausgewählt wird, welche Überschreibung verwendet wird. Statische Methoden sind aber gar nicht an ein Objekt gebunden. Wenn du passend zum dynamischen Typ eines Objekts eine statische Methode aufrufen willst, dann schreib einen nichtstatischen Wrapper drumherum. Den kannst du dann virtual machen.

Ja, das hat mich auch verwirrt. Das scheint aber ein Standardpolynom zu sein:

Ich kenne das so, dass die Zählung der Bits bei 0 anfängt. Das Polynom wäre also 1 1000 0000 0000 0101 (0x18005).

Ein Cast ist eine explizite Typumwandlung. Dabei schreibt man den Typ, in den umgewandelt werden soll, in Klammern vor den umzuwandelnden Ausdruck. In deinem Fall wandelst du den Ausdruck malloc(65536*sizeof(int)) explizit in int* um. Das ist hier aber gar nicht notwendig. malloc liefert einen void* zurück, der in C implizit in jeden anderen Zeigertyp konvertierbar ist, also auch in int*. Das (int*) ist also überflüssig.

Das kann ich nicht ganz glauben. Selbst wenn es sich um eine sehr, sehr alte Version des Builders handelt, sind da ein paar dicke Fehler drin. conio.h und die Funktionen darin gehören nicht zum Standard. Es kann dir also passieren, dass das mit einem anderen Compiler nicht funktioniert. Die Methoden hole_grunddaten und zeige_grunddaten rufst du mit holeGrunddaten und zeigeGrunddaten auf, das kann nicht funktionieren. Fahrzeug::hole_grunddaten erwartet 3 Parameter, du rufst es mit 4 auf. Oder soll 2,5 der float-Wert sein? Das Dezimaltrennzeichen ist ein Punkt, kein Komma. auto ist ein Schlüsselwort in C++, kann also nicht als Variablenname benutzt werden.

Alle Klassen und Funktionen der C++-Standardbibliothek liegen nun mal im namespace std. Was immer du "bisher" benutzt hast, wenn du es damit nicht gebraucht hast, war es nicht standardkonform. Die main-Funktion muss den Rückgabetyp int haben: int main(... Das Weglassen des Rückgabetyps (und damit implizit int) war nur bei C erlaubt.

Tja, weder die Information, dass es "sehr viele" Fehlermeldungen waren, noch die, dass "ein Kollege" es auch nicht schafft, helfen hier weiter. Du musst schon die Fehlermeldungen selbst posten, wenn du Hilfe willst. Aber bitte nicht alle. Warum bittest du nicht einfach deinen Admin, dir ein passendes Programm zu installieren?

So, wie du sie deklariert hast, erwartet deine load-Funktion keinen Zeiger auf ein Array, sondern ein Array von Zeigern. Eine Funktion, die einen Zeiger auf ein Array als Parameter hat, sieht so aus: void foo( int(* bar)[2] ); Du musst die Größe des Arrays in diesem Fall angeben. Das Ganze ist aber für dein Problem sowieso egal, weil Arrays ohnehin nicht "by value" übergeben werden. Array-Parameter werden nicht kopiert, sondern sind (auch in C) immer "by reference". Genauer gesagt zerfallen Array-Parameter immer zu Zeigern. Das bedeutet unter anderem auch, dass die Größeninformation beim Aufruf verloren geht.

GetComputerNameEx funktioniert ab Windows 2000. Für ältere Versionen kannst du NetWkstaGetInfo verwenden. Für 95/98/ME gibt es diese Funktion allerdings nur als 16-Bit-Variante, da musst du ein wenig tricksen, wenn du sie aus 32-Bit-Code aufrufen willst. Näheres dazu findest du hier: How To Call 16-bit Code from 32-bit Code Under Windows 95, Windows 98, and Windows Me

FindFirstFile erwartet als ersten Parameter einen const char*, und kann mit std::string nichts anfangen. Die Stringklasse bietet allerdings eine Methode an, die einen solchen Zeiger bereitstellen kann, und diese Methode heißt c_str.

Ja. Benutz ein virtuelles List Control. Virtual List Controls Die Auswahl eines List Controls wird vom Focus gar nicht beeinflusst. Allerdings zeigt das List Control seine Auswahl normalerweise nicht mehr an, wenn es den Focus verliert - es sei denn, du benutzt LVS_SHOWSELALWAYS.

Nein. Die eckigen Klammern brauchst du nur bei der Deklaration/Definition des Arrays. Später benutzt du die Klammern dann nur noch, wenn du auf einzelne Elemente des Arrays zugreifen willst. Nein. Aber ich kann deinen Code mal eben passend umstricken: #include <string> using namespace std; int main() { HANDLE fHandle; WIN32_FIND_DATA FindFileData; string path; cout<<"Geben Sie das Verzeichnis an: "; cin>>path; fHandle=FindFirstFile(path.c_str(),&FindFileData); ... FindNextFile(fHandle,&FindFileData); while (FindNextFile(fHandle,&FindFileData)) { if (FindFileData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { cout<<"\n'Ein Verzeichnis'\n\n"; // Datei ist keine, sondern ein Verzeichnis... } else { //cout<<"Folgende Datei gefunden: "<<FindFileData.cFileName<<"\n"; string list; list=FindFileData.cFileName; cout<<"Folgende Datei gefunden: "<< list <<"\n"; } } FindClose(fHandle); _getch(); return 0; }[/code]

In eine char-Variable passt genau ein einzelnes Zeichen. Wenn du mit Zeichenketten arbeiten willst, musst du schon char-Arrays benutzen, oder, da du C++ benutzt, am besten gleich std::string. Diese Klasse kümmert sich für dich um die Speicherverwaltung.

Using Run-Time Dynamic Linking (Windows)

In Prog.cs muss du Main schreiben, nicht MAIN. Das darfst du dir nicht aussuchen. Und die Counter.cs sieht komplett anders aus als in deinem ersten Beitrag. Da ist auf einmal ein Namespace, die Klasse heißt anders, und auch sonst sind da jede Menge Fehler drin. Nimm doch die erste Version, pack das fehlende Semikolon rein und gut ist.

Du hast die Fehlermeldung falsch oder unvollständig abgeschrieben. Deine Schlussfolgerung ist auch falsch. Zeig mal den Code. Auch hier ist die Fehlermeldung wieder falsch/unvollständig. Bitte benutz Copy&Paste. Und auch hier musst du den Code zeigen. Ohne den Code kann man nur sagen, dass du etwas falsch machst.

Ich kann das Problem nicht reproduzieren. Mit dem zusätzlichen Semikolon kann ich den Code erfolgreich kompilieren und ausführen. Du solltest den Code nicht abtippen, sondern mit Copy&Paste hier reinstellen. Wie du siehst, besteht sonst die Gefahr, dass du beim Abtippen Fehler machst.

Bitte beim nächsten Mal die genaue Fehlermeldung angeben. Mit "er mosert an einigen Stellen" kann niemand etwas anfangen. Am Ende der WriteLine-Anweisung fehlt übrigens tatsächlich ein Semikolon.

Das kommt ein wenig darauf an, was für eine DLL das ist. Welche Symbole exportiert sie denn? Normalerweise nimmt man LoadLibrary/GetProcAddress. Wenn es sich um eine COM-DLL handelt, muss man natürlich anders vorgehen. Und wenn sie C++-Symbole eines anderen Compilers exportiert, hast du ein Problem.