Klotzkopp

Mift [tm]! Aber mindestens zwei sind neu

Na dann, Fähnrich Fischbrötchen, raus damit

Hast Du diese Vorgehensweise mit CArchive aus einem Bespiel oder so? Ich glaube nämlich nicht, dass das so geht. Und was ist m_List, ein CListCtrl? Ich würde empfehlen, statt CFile CStdioFile zu verwenden, die einzelnen Zeilen in einer Schleife mit ReadString auszulesen, und dann der Liste mit AddString bzw. InsertItem hinzuzufügen.

42 = A auf die F nach dem L, dem U und dem ganzen R

An welcher Stelle hakt es denn? Beim Dialog, beim Einlesen der Datei oder beim Hinzufügen der Daten zum Listenfeld? MS oder Borland? MFC oder WinAPI?

Ich bin diese Woche irgendwie in Rätsellaune 26 = B im A 7 = WW 12 = SZ 9 = P im SS 19 = GR im GG 0 = GC ist der GP von W 18 = L auf dem GP 90 = G im RW 4 = Q in einem KJ 24 = S hat der T 384400 = ME zwischen E und M 2 = R hat ein F 11 = S in einer FM 29 = T hat der F in einem SJ 32 = K in einem SB 64 = F auf dem SB 5 = F an einer H 16 = BL hat D 60 = S hat eine M 3 = W aus dem ML 8 = B hat ein B 45549 = P von SH

Aber die kann man leicht ausrechnen. Die größte darstellbare Zahl in diesem abgewandelten Dreiersystem ist (3 hoch Stellenzahl - 1) / 2. Das ergibt sich eigentlich automatisch: Jede Stelle kann 0, 1 oder -1 sein, bedeutet: Gewicht nicht benutzt, linke oder rechte Waagschale. Andere Stellenwerte können ja gar nicht vorkommen.

Naja, man könnte so argumentieren: Ausgehend von einer fünfstelligen Zahl im Dreiersystem, die ja die Werte 0 bis 242 darstellen kann, definiert man nun die möglichen Stellenwerte um: Eine zwei an einer beliebigen Stelle der Zahl ist in dieser Aufgabe nicht darstellbar, weil wir jedes Gewicht nur einmal haben. Allerdings haben wir dafür sozusagen einen zusätzlichen Stellenwert -1, wenn das Gewicht in der anderen Waagschale liegt. Wir haben jetzt also: n = k1 * 81 + k2 * 27 + k3 * 9 + k4 * 3 + k5, mit kx aus { -1; 0; 1 } Dadurch ändert sich nur der darstellbare Zahlenbereich (auf -121 bis +121), wobei die negativen Zahlen hier nicht weiter relevant sind. Jetzt müsste man nur noch beweisen, dass diese Gleichung für jedes n aus [1,100] eindeutig lösbar ist.

Richtig Da jedes Gewicht drei verschiedene "Zustände" annehmen kann (linke Waagschale/rechte Waagschale/gar nicht verwendet), liegt die nächste Größenordnung für den Wertebereich immer um den Faktor 3 höher. Daher entsprechen die gesuchten Gewichte den Potenzen von drei.

Kein Problem Also, 5 ist richtig (Tusch!) Nächste Frage (logisch): Welche Gewichte? Nur zur Info: Es gibt mehrere Lösungen, aber eine ist besonders, sagen wir, schön @StefanK: Steckt bei Deinen Zahlen ein System dahinter, oder probierst Du nur?

Natürlich kann man mit diesen 6 alle Gewichte abwiegen. Aber das ist nicht die Frage. Das kann ich auch mit hundert Gewichten Die Frage ist, wie viele brauche ich? Und ich behaupte jetzt einfach mal, es geht mit weniger als 6

Wie schon gesagt, 6 ist auch nicht die Lösung...

Da muss ich Dich enttäuschen 1. Ja, genau so ein Ding. Zwei Waagschalen, die beiden Arme sind gleich lang. 2. Sicher

Also bisher war alles - zumindest was die Anzahl angeht - falsch.

Was genau ist "die falsche Richtung"? Es gibt ja ziemlich viele falsche Richtungen. Sucht der Lügner sich irgendeine Richtung aus, oder nimmt er die genau entgegengesetzte?

Irgendwo in die Initialisierung der WNDCLASSEX-Struktur muss noch rein: wndClass.cbSize = sizeof( WNDCLASSEX ); Aber weil das nichts mehr mit Standard-C oder C++ zu tun hat: ~~~ verschoben nach: C++: Compiler, IDEs, APIs ~~~

Wir hatten ja schon seit zwei Tagen kein Rätsel mehr! Also: Wie viele Gewichte brauche ich, um mit einer Balkenwaage jedes ganzzahlige Gewicht von 1 bis 100 g abwiegen zu können? Viel Spaß

Was meinst Du mit "funktioniert nicht"? Compiler-Fehler? Runtime-Fehler? Übrigens: rename_namespace macht nur dann Sinn, wenn Du den Namespace wirklich änderst. Soweit ich weiß, heißt der Namespace der msado15.dll bereits ADODB. Und wenn Du den Namespace gar nicht änderst, dann brauchst Du auch EOF nicht umzubenennen, weil dann gar keine Namenskonflikte auftreten.

@Woodstock Kleine Anmerkung: Die Klammern bei return sind überflüssig.

So weit ich weiß, ist die interne Struktur der dargestellten Objekte bei Sequenzdiagrammen nicht von Belang, sondern nur die Nachrichten, die die Objekte untereinander austauschen. Daher wird nicht dargestellt, aus welcher Methode des Objekts ein Nachrichtenaufruf erfolgt. Wenn Dir so viel daran liegt, dieses Detail darzustellen, dann lagere diese Methode einfach in eine eigene Klasse aus, die kannst Du dann mit einer eigenen "Lifeline" versehen.

(Ohne Fehlerprüfung oder Erzeugung der Instanz) ADODB::_RecordsetPtr r; long state; r->get_State( &state ); if( state != ADODB::adStateClosed ) { // ... } [/CODE]

Sowohl Recordset als auch Connection habe ein State-Property.

Hier gibt es ein recht simples Beispielprogramm für eine IE-Toolbar für Visual C++.

So, nun kommt aber wieder zum Thema zurück. Die Diskussion, ob void main (Jehova!) OnT ist oder nicht, hat nichts mit verketteten Listen zu tun. Noch zwei Hinweise zu verketteten Listen aus eigener Erfahrung: - Es ist allgemein einfacher, neue Elemente vorn anzuhängen. - beim Zugriff aus mehreren Prozessen/Threads muss man bei vL besondere Vorsicht walten lassen.

Was denn nun? DOS oder Windows? Oder meinst Du ein Kommandozeilenprogramm? Dann geht das hier: #include <windows.h> #include <mmsystem.h> #pragma comment( lib, "winmm.lib" ) int main(int argc, char* argv[]) { PlaySound( "ding.wav", NULL, SND_FILENAME ); return 0; } [/CODE]