Klotzkopp

Hallo Gateway_man, eine Anmerkung am Rande: "hoi hoi" ist kein guter Threadtitel C++ hat keine Versionen. Vermutlich redest du von der Version deiner Entwicklungsumgebung, aber das hat mit der Sprache selbst nichts zu tun. Wie heißt denn deine Entwicklungsumgebung genau? Was genau meinst du mit "testen"? Meinst du den Debugger? Zu Dev-C++ sollte man noch sagen, dass es relativ viele Bugs hat und seit drei Jahren nicht mehr weiterentwickelt wird. Ich weiß nicht, warum das immer wieder empfohlen wird. Ich kann nur vermuten, dass das zum überwiegenden Teil Leute sind, die nicht wirklich ernsthaft damit arbeiten.

Ohne mir das jetzt genauer angesehen zu haben: Solange du mit uninitialiserten Zeigern hantierst, darf dich das nicht wundern. Es wäre also gut, wenn pmyRichEditCtrl und pMyPrinterDC auch tatsächlich auf etwas zeigen würden, und nicht nur irgendwo in den Speicher.

Was du bisher nicht erklären konntest, ist dann wohl, dass du nicht möchtest, dass dein Programm bei mehreren markierten Objekte mehrfach gestartet wird? Dann musst du einen Context Menu Handler erstellen. Eine Dokumentation dazu findest du hier: Creating Context Menu Handlers Beachte aber, dass du dazu einigermaßen fit in COM sein solltest.

Es ist in der Tat sehr merkwürdig, dass das bei dir funktioniert. Folgenden Code lassen weder MSVC2008 noch der Comeau-Compiler durchgehen: int main() { typedef double fftw_complex[2]; fftw_complex fft[256][129]; fft[0][0]=0; }[/code]Morgen kann ich das auch noch mit dem GCC testen. Welchen Compiler benutzt du denn? Und kannst du ein vollständiges Minimalbeispiel zeigen, das das beschriebene Verhalten reproduziert?

Wenn du prüfen willst, ob und wie die Namen der ausgewählten Dateien im Programm aufschlagen, solltest du ein Programm benutzen, bei dem du genau das kontrollieren kannst. Schreib dir ein Programm, das seine Startargumente auf der Konsole ausgibt, und häng das in das Kontextmenü.

Meine Güte, lass dir doch nicht alles einzeln aus der Nase ziehen. Allmählich verliere ich die Lust. Was genau hast du in der Registry eingetragen, und was genau landet in deinem Programm in argc und argv? Wird dein Programm überhaupt aufgerufen? Wenn du keine detaillierten Informationen zur Verfügung stellst, kann man dir nicht helfen.

Setz ein Programm in den Autostart, das den Dienst benachrichtigt. Hier habe ich auch ein paar Tips gefunden: C# Windows Service, Detect Login

Wie hast du denn dein Programm ins Kontextmenü eingehängt? Hast du das überhaupt schon gemacht?

Die du wo anklickst? Im Windows-Explorer? Einzel- oder Doppelklick? Ich verstehe immer noch nicht, was du vorhast. Es bringt überhaupt nichts, wenn du dich wiederholst. Beschreib doch bitte mal genau und im Detail, was passieren soll.

Die MFC werden durchaus noch weiterentwickelt. Ein Beispiel: Visual C++ Team Blog : MFC Updates for Vista Common Controls Es ist richtig, dass die MFC aufgrund ihres Alters einige nicht so schöne Altlasten mit sich herumschleppen. Aber ihnen deswegen gleich die Zukunftssicherheit abzusprechen, halte ich für übertrieben. Nur als Anmerkung: .NET-Programme sind (potenziell) portabler als "native"-Programme.

Schau dir meinen Beispielcode an. Genau das, was du suchst, passiert da, nur dass das Schlüsselwort "Computername" heißt, nicht "Alter". Die Anzahl der Leerzeichen zwischen den Wörtern ist dabei völlig egal, die überspringt der >>Operator sowieso.

Nicht auf dem ganzen Laufwerk. Im Wurzelverzeichnis. Es wäre schlecht, wenn ein Benutzer nicht seine Eigenen Dateien verändern könnte

Damit wirst du zumindest unter Vista Probleme bekommen, denn da hast du, soweit ich weiß, als normaler Benutzer keine Schreibrechte auf C:\. Der Code zum Einlesen und Filtern ist doch in meinem Beispiel schon drin. :confused:

Die Eingabeaufforderung hat mit MS-DOS nichts zu tun. Leite die Ausgabe in eine Datei um und lies die Datei ein. Hier ist ein Beispiel für ein deutsches Windows XP: #include <iostream> #include <fstream> #include <sstream> #include <string> #include <cstdio> using namespace std; int main() { remove( "out.txt" ); system( "cmd /C net config workstation > out.txt"); string domainKey = "Arbeitsstationsdom\x84ne"; string nameKey = "Computername"; string domain, name, dummy; { ifstream file("out.txt"); string line; while( getline( file, line ) ) { if( domain.empty() && line.find( domainKey ) != string::npos ) { istringstream( line ) >> dummy >> domain; } if( name.empty() && line.find( nameKey ) != string::npos ) { istringstream( line ) >> dummy >> name; } } } remove( "out.txt" ); cout << name << '\n' << domain << '\n'; }[/code]

Dadurch lernst du bestenfalls, wie man es nicht macht. Solche Sicherheitsabfragen sollte man dem Betriebssystem überlassen. Dann kannst du dich auch darauf verlassen, dass das zumindest halbwegs sicher ist. Wenn nur bestimmte Benutzer Zugriff auf das Programm haben sollen, dann vergib entsprechende Berechtigungen in Windows, Linux oder was auch immer. Ohne richtige Erfahrung in solchen Dingen ist alles, was du diesbezüglich selbst bastelst, nicht annähernd so sicher.

Ich weiß, das hatten wir doch alles schon. Das gilt auch für IADsADSystemInfo::DomainDNSName, es sei denn, du installierst vorher die Active Directory Client Extension. Was heißt denn "nur noch"? Dass du den Rechnernamen (genauer: den NetBIOS-Namen) mit GetComputerName ermitteln kannst, war doch klar. Klar war doch auch, dass nur der Domänenname ein Problem ist. Und was du tun kannst, um an den Domänennamen zu kommen, haben wir auch schon mehrfach durchgekaut. Warum machst du dazu immer wieder neue Threads auf? An der Situation ändert sich doch nichts.

Du meinst vermutlich das IADsADSystemInfo-Property DomainDNSName. Das ist ADSI. Meinst du WHSInfoClass.GetDomainName? Das hat nun mit normalem C++ gar nichts mehr zu tun. - GetComputerNameEx - NetWkstaGetInfo Aber das haben wir doch alles schon mal durchgekaut...

Das ist schon OK. IT Allgemein hätte auch gepasst.

Für einen Vokabeltrainer ist eine Datenbank IMHO völlig übertrieben. Da tut's auch eine einfache Textdatei. Wofür so ein Programm Benutzername und Passwort braucht, habe ich auch nicht verstanden.

tar -- format of tar archives

Ja und? Darfst du jede Funktion nur einmal pro Programm benutzen? Ich würde vermutlich GetTextExtent überschreiben. CRichEditCtrl::StreamIn.

Ich würde das gar nicht umwandeln. Was bringt dir die Information, wie groß der unformatierte Text ist? Der echte Text kann, abhängig von der eingestellten Schriftart und -größe, ganz andere Dimensionen haben. Du kannst CRichEditCtrl::FormatRange benutzen, um die tatsächlichen Maße zu ermitteln.

Das Problem liegt IMHO eher darin begründet, dass ein und dasselbe Steuerelement-Objekt benutzt wird, um alle Zellen zu rendern. Dabei überträgt sich anscheinend das Format auf Zellen, die nur unformatierten Text enthalten. Wenn man alle Zellen von Anfang an mit RTF-Inhalten füllt, tritt das Problem nämlich nicht auf. Man könnte das umgehen, indem man in diesem Fall in CGridCellRich::Draw mit SetDefaultCharFormat ein passendes Standardformat setzt.

Wie du das beheben kannst, habe ich auch schon geschrieben.

Du musst den Pfad auf ein Verzeichnis legen, auf das du auch schreibend zugreifen darfst. Das ist vermutlich eine Datei, kein Verzeichnis. Und sie existiert nicht, weil das Programm sie nicht anlegen konnte. Und das Programm konnte sie nicht anlegen, weil der normale Vista-Benutzer keine Schreibrechte auf C:\ hat. Was an und für sich nichts schlechtes ist, nur sehr ungewohnt für Windows-Nutzer.