Klotzkopp

Das Webserverprogrammierungsforum wäre wohl besser In webbbs_text.pl, Zeile 119, wird dieser Text als $text{'0500'} festgelegt. In webbbs_index.pl, Zeile 215, wird der Textbaustein dem Forumtitel hinzugefügt. Du solltest aber letzteres ändern, weil der Baustein auch noch an einer anderen Stelle verwendet wird.

Es ist definitiv der Smartsurfer. Ich habe web.de angemailt, und die haben das Problem (das nur unter XP auftritt) bestätigt. Die aktuell zum Download angebotene Version soll den Bug nicht mehr haben (hab ich selbst noch nicht getestet), aber eine einfache Deinstallation der alten Version reicht wohl nicht. Ich zititiere mal die Mail von web.de:

Ach ja, in der Implementierung der Funktion GetActiveDlg (in der cpp-Datei) darf nicht static stehen, nur in der h-Datei, sonst kommt dieser C2724-Fehler.

Die Deklarationen sind richtig. Hast Du die statische Variable am Anfang der cpp-Datei initialisiert? Wenn nicht, würde das nämlich den Linker-Fehler erklären. Irgendwo in der Quellcodedatei für CExcelProper (außerhalb der Funktionsimplementierungen) muss stehen: #include "ExcelProper.h" ... CExcelProper* CExcelProper::m_pActiveDlg = NULL; // <-- WICHTIG, Initialisierung der statischen Variablen ... CEcxelProper::CExcelProper() { ... // Ctor } ...

Eigentlich reicht es doch, wenn Du for( int i=0; i<m_idx_listbox.GetItemCount();i++) m_idx_listbox.SetItemData( i, i ); vor den SortItems-Aufruf einfügst.

Also da fallen mir zwei Sachen auf: Erstens wird finr nirgend initialisert, zweitens kommt das ParamByName wohl vor das Open, zumindest hast Du es hier so gemacht.

"static" hat nichts mit dem Typ zu tun, sondern bedeutet nur, dass sich alle Instanzen der Klasse eine Variable teilen. Die beiden Angaben schließen sich nicht gegenseitig aus. Wie genau lautet bei Dir die Deklaration sowohl der statischen Funktion als auch der statischen Variablen?

Die Funktion ist static, der Typ ist CDlg1*, also Zeiger auf die Dialogklasse.

Bei der Sortierfunktion stehen in lParam1 und lParam2 die Werte, die im ListControl mit SetItemData eingetragen wurden, nicht(!) die Indizes der zu vergleichenden Elemente. Per Default ist dieser Wert bei allen Einträgen Null.

Also, ich nehme mal an: - Du hast zwei Dialoge, wobei wahrscheinlich der eine den anderen erzeugt. - Du musst zwischen den beiden Dialogen Daten austauschen oder synchronisieren Dann würde ich folgendes vorschlagen: Verpass jeder der beiden Klassen eine statische Funktion, die einen Zeiger auf eine Instanz der Dialogklasse zurückgibt. Dazu braucht jede Klasse zusätzlich noch einen statischen Member-Zeiger auf die eigene Klasse: class CDlg1 : public CDialog { public: static CDlg1* GetActiveDlg(); ... protected: static CDlg1* m_pActiveDlg; ... } Die statische Variable m_pActiveDlg gibt es genau einmal, egal wieviele Instanzen von CDlg1 Du erzeugst. Es gibt sie auch, wenn noch gar keine Instanz erzeugt ist. Du musst die Variable in der Quellcodedatei der Dialogklasse initialisieren, am besten gleich nach den #includes CDlg* CDlg::m_pActiveDlg = NULL; Jetzt musst Du nur noch dafür sorgen, dass die statische Variable mit Werten versorgt wird, wenn ein Dialog erzeugt wird. In der OnInitDialog: m_pActiveDlg = this; Du musst natürlich auch sicherstellen, dass nach dem Beenden des Dialogs der statische Zeiger wieder zurückgesetzt wird, damit kein Zeiger auf eine nicht mehr existierende Instanz zurückgegeben wird. Dazu könntest Du OnClose überladen, oder den Destruktor verwenden (unsicher): In OnClose oder im Destruktor m_pActiveDlg = NULL; Die statische Funktion GetActiveDlg sieht so aus: CDlg1* CDlg1::GetActiveDlg() { return m_pActiveDlg; } Das gleiche machst Du für die andere Klasse. Dann kannst Du jederzeit prüfen, ob der andere Dialog gerade aktiv ist, und auf die Member zugreifen: CDlg2::DoSomething() { CDlg1* pOtherDlg = CDlg1::GetActiveDlg(); if( !pOtherDlg ) return; // kein anderer Dialog da! pOtherDlg->m_strEditField = "foo"; pOtherDlg->m_ctlPushButton.EnableWindow( FALSE ); } Das ganze ist zwar immer noch nicht ganz sicher, aber für den Anfang sollte es reichen.

Wenn die Member-Variable des Edit-Felds ein CString ist, dann kannst Du dem schon vor DoModal/ShowWindow einen Wert zuweisen. Wenn es ein CEdit ist, dann geht das nicht, weil das Fenster des Edit-Felds noch nicht erzeugt wurde. Wenn Du z.B. die Sichtbarkeit oder das Read-Only-Flag setzen willst, dann musst Du der Dialogklasse mit dem Steuerelement jeweils einen BOOL-Member verpassen, den Du nach dem Erzeugen des Dialogs setzen kannst, und in der OnInitDialog abfragst: CMyDlg dlg; dlg.m_fShowEditField = TRUE; dlg.m_fAllowInput = TRUE; dlg.DoModal(); ... BOOL CMyDlg::OnInitDialog() { ... GetDlgItem( IDC_EDIT )->ShowWindow( m_fShowEdit ? SW_SHOW : SW_HIDE ); GetDlgItem( IDC_EDIT )->EnableWindow( m_fAllowInput ); ... } Aber was anderes: Das ist ja nun nicht Deine erste Zwei-Dialoge-Frage Kann es sein, dass da ein grundsätzliches Problem besteht?

Du kannst auf die Member einer Dialogklasse wie bei jeder anderen zugreifen, auch ohne dass DoModal oder ShowWindow aufgerufen wurde. Beispiel: CMyDlg mydlg; mydlg.m_nCounter = 0; if( IDOK == mydlg.DoModal() ) ... Besondere Member wie zum Beispiel m_hWnd oder Steuerelement-Variablen können allerdings Probleme bereiten, weil sie auf Objekte verweisen, die erst mit DoModal erzeugt werden. Was genau versuchst Du denn?

Mich wundert, dass XP keinen Treiber dafür mitbringt. Hast Du schon den W2K-Treiber ausprobiert? ftp://ftp.elsa.de/pub/FILES/DATACOMM/MICROLNK/56KPCI/56KPCIHSFW2000.EXE

Wenn j als Antwort am Ende 'Wiederholung' bedeutet, dann muss die Schleifenbedingung natürlich while ('j' == getchar()); lauten

Hi, Die Anzahl der benötigten Festplattenumdrehungen ist eine Folge des Interleave. Interleave bedeutet, dass die Sektoren einer Spur nicht direkt aufeinanderfolgend angeordnet werden, sondern mit anderen Sektoren dazwischen. Der Interleave-Wert gibt an, wieviele Sektoren zwischen zwei logisch aufeinanderfolgenden liegen. Die Reihenfolge der Sektoren auf der Spur wäre z.B. bei Interleave 1:1 - 1 2 3 4 5 6 7 8 bei Interleave 2:1 - 1 5 2 6 3 7 4 8 bei Interleave 3:1 - 1 4 7 2 5 8 3 6 Der Grund dafür war, wie Terran Marine schon sagte, dass die Daten nicht schnell genug verarbeitet werden konnten. Die Folge davon ist dann, dass man zwei oder drei Plattenumdrehungen braucht, bis man alle Sektoren gelesen hat. Ohne Interleave würde es aber noch viel länger dauern, weil man dann für jeden Sektor fast eine volle Umdrehung hätte warten müssen.

Sollen wir hier die Glaskugel rausholen oder was? - nichtssagender Betreff - völlig unzureichende Fehlerbeschreibung - multiple Satzzeichen und sich dann noch beschweren, dass man nicht verstanden wird. Woran könnte es liegen?

Nach http://www.eeng.brad.ac.uk/help/.faq/.unix/.pronun.html: crosshatch, pound, pound sign, number, number sign, sharp, octothorpe, hash, (garden) fence, crunch, mesh, hex, flash, grid, pig-pen, tictactoe, scratch (mark), (garden) gate, hak, oof, rake .. Mir sind pound und hash am geläufigsten.

Ich gehe mal davon aus (und die Borland-Experten mögen mich ggf. korrigieren), dass AnsiString einen überladenen Vergleichsoperator hat. Der Vergleich wäre damit kein Problem. Aber die SQL-Abfrage liefert dir eine Row pro name_1, und Du vergleichst nur mit der ersten. Entweder musst Du mit allen Rows vergleichen (QrSelect bietet dafür wahrscheinlich einen Mechanismus, der MoveNext oder so heißt), oder Du könntest die Abfrage mit zeile.Name_1 parametrieren.

Bei Name_1 wollte ich auch den Datentyp wissen, sorry, falls das falsch rüberkam. Kann ja sein, dass der Vergleichsoperater nicht das macht, was Du erwartest. Ist mir grad aufgefallen: Das rot markierte if-Statement ist komplett sinnfrei. Wenn die Bedingung erfüllt ist, gibst Du false zurück, wenn nicht, gibst Du auch false zurück. :confused: Vielleicht stimmt hier die Reihenfolge nicht?

Was heißt 'funzt nicht'? Laufzeitfehler, Compile-Fehler oder tut es nicht, was es soll? Was für ein Datentyp ist Text, und was ist Name_1? Brauchst Du vielleicht einen Copy-Constructor für die struct?

Ich empfehle Regmon. Ist Freeware und erhältlich bei sysinternals.com: http://www.sysinternals.com/ntw2k/source/regmon.shtml

Versuchs mal hier: http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html Ansonsten auch immer hilfreich http://www.google.com/search?sourceid=navclient&q=md5+lib

Hallo zusammen, ich hab hier ein recht seltsames Phänomen: Ich hab einen COM-Server mit Dual-Threading-Modell, und da ich das Ding in einem Thread hochziehe, und in einem anderen das Interface benutzen muss, packe ich es, wie es sich gehört, im ersten Thread mit CoMarshalInterThreadInterfaceInStream in einen Stream, um es dann im anderen Thread wieder auszupacken. Das Dumme ist nur, wenn ich dann auf die Interface-Methoden zugreifen will, erhalte ich RPC_E_WRONG_THREAD. Was jetzt aber wirklich seltsam ist: Wenn ich nicht marshalle, dann funktioniert es! :confused: Hat irgend jemand schon mal von so was gehört?

So eine Fehlerbeschreibung wünscht sich der Programmierer ;-) Im Ernst, was genau passiert denn? Access Violation? Debug Assertion? Tip: Wenn Du die MFC-Sourcen installierst, dann kannst Du CDialog::DoModal debuggen und genau sehen, wo er wegknallt. Klotzkopp

Es scheint mir, als ob Du eine parametrierte Datenbankabfrage machst. Das logische oder, das Du brauchst, ist aber auf der Ebene der Abfrage notwendig, nicht auf Ebene der Programmiersprache. Was ist denn das für eine Klasse, von der QrLand eine Instanz ist? Vielleicht unterstützt diese Klasse Abfragen mit mehrfachen Parametern. Wenn nicht, dann könntest Du, wenn die erste Abfrage nichts gebracht hat (also in deinem else-Zweig), eine zweite Abfrage (also wieder mit ParamByName, Open usw.) starten, aber diesmal cland als Parameter setzen.