pp_coder

Hallo zusammen, ich suche FI APs (bevorzugt für AE). Optimalerweise mit Lösungen. Bitte an evm.nsb(at)online.de Danke!

Hallo zusammen, auch ich bin auf der Suche nach Abschlussprüfungen mit Lösungen (FIAE) der letzten Jahre. Wäre echt super, wenn mir jemand weiterhelfen könnte. Mail: evm.nsb[at]online.de Danke :-)

Ich habs. Ein Kollege hat die richtige Funktion gefunden :upps: : SHGetFileInfo

Da steht bei mir auch nur der "allgemeine" Pfad "c:\Program Files" drin. Anscheinend gibt Windows die Info, wie der im Windows-Explorer angezeigte Name bei den verschiedenen OS-Sprachen ist, nicht nach außen. Ich dachte ich könnte mir da was in den Quellen vom Verzeichnis-Browse-Dialog von QT abschauen; der listet nämlich "Program Files" auch mit "Programme" auf. Nur leider hat debuggen gezeigt, dass QT default-mäßig einfach über die WinAPI den File-Dialog öffnet.

Ich entwickle auf/nutze Win7 X64. HRESULT hat den Hex-Wert: 0x80070002. Den Text hab ich aus dem watch-Fenster meines Developers (VS 2008). Frag mich jetzt nicht wo der die Info her zieht, im winerror.h finde ich zu dem Wert nämlich auch nix. Den oben genannten Wert liefert die Funktion nur, wenn ich sie in meinem 32-Bit Programm verwende. Ich habe den Call testweise mal in einer 64-Bit Bitanwendung ausgeführt, da kommt S_OK zurück und ich erhalte auch nen Pfad. Mein eigentliches Problem ist halt einfach, dass ich den lokalisierten Namen zu "Program Files" bräuchte, nämlich z.B. bei deutschem OS -> Programme. Aber ich finde einfach keine WinApi Funktion die das könnte.

Danke für die schnelle Antwort. Das Programm muss ab XP SP3 aufwärts laufen. Leider liefert bei mir: HRESULT res = SHGetKnownFolderPath(FOLDERID_ProgramFilesX64, 0, NULL, myString); als result: "Das System kann die angegebene Datei nicht finden". Ich vermute mal, das liegt daran, dass mein Programm 32 Bit ist???

Hallo zusammen, ich habe folgendes Problem. Ich muss in meinem Programm (wenn es auf einem 64 Bit OS ausgeführt wird) erkennen, ob es sich bei dem durch den Benutzer eingegebenen Verzeichnis um die "Program Files" handelt. Sprich um den Ordner, in dem auf einem 64-Bit OS i.d.R. die 64 Bit Programme installiert werden. Ich kann nicht fest auf Stringebene auf "Programme" bzw. "Program Files" abprüfen, da der Code natürlich auch auf z.B. einem russischen System laufen muss. Ich kann in meinem Programm die WinAPI und QT4 nutzen.

Also zum Inhalt kann ich nicht viel sagen, da die Präsi ja erst zusammen mit deinem Vortrag ein Gesamtbild ergibt. Generell finde ich den Aufbau gut. Miir fehlt nur etwas der dezente Hinweis auf die Entscheidungsfindungen die während der Umsetzung stattgefunden haben. Zum Aussehen: Aufgrund der relativ groß geratenen Gliederungsansicht links wirkt der Platz für die eigentlichen Punkte rechts relativ knapp. Dadurch wirken die beiden letzten Punkte auf Folie 13 schon sehr lang. Allgemein macht sich eigentlich auch das aktuelle Tagesdatum auf den Folien gut. PS: Beim ersten Punkt auf Seite 13 hat sich ein kleiner Fehler eingeschlichen: "enorme" nicht "enormes"

Mache ich ja auch, allerdings nur im Hintergrund. Der Benutzer kann über meine Setup.exe die einzelnen Produkte zum Installieren/Deinstallieren auswählen. Das eigentliche Installieren bzw. Deinstallieren erfolgt dann schon über MSI-Pakete. Meine Exe startet diese mittels msiexec. Allerdings prüfen die Pakete selbst keine Abhängigkeiten und keine OS-Versionen, das muss alles meine Exe leisten

Stimmt, aber ich kann dem User eine konkrete Fehlermeldung bieten. Wäre ja blöd, wenn ich dem Benutzer mitteilen würde, dass er das falsche OS hat, aber in Wirklichkeit einen zu alten Prozessor, oder umgekehrt. Nein, wenn der User ein aktuelles OS hat, aber trotzdem die Anwendungen im Win95-Kompatibilitätsmodus ausführt, ist er ja selbst schuld. Aber installieren darf ich halt nur, wenn das verwendete OS >= dem Minimum-OS ist. Ja, ich befürchte so muss ich es machen. Aber echt komisch, dass man nicht einfach an die Echte OS-Version kommt.

Ich implementiere zur Zeit eine Installation. Ich brauche eine genaue Versionsbestimmung, da ich mittels IsProcessorFeaturePresent(PF_XMMI64_INSTRUCTIONS_AVAILABLE) prüfe, ob der SSE2 Befehlssatz vom Prozessor unterstützt wird, und diese Abfrage unter W2k immer false liefert. Die Software, die meine Installation installiert, braucht aber dieses Prozessorfeature, deshalb darf ich nicht installieren, wenn das Feature nicht verfügbar ist. Somit muss ich definitiv wissen, ob meine Exe unter W2k ausgeführt wird. die Software die meine Installation installieren soll, nur für bestimmte OS-Versionen qualitätsgesichert ist, und ich deshalb eine Meldung bringen muss, wenn versucht wird, die Installation unter einem nicht unterstützten OS anzuwerfen. ich für den Fall, dass bei der Installation auf Fehler auftritt, ein Log-File erzeuge. Es ist zwar nicht "überlebenswichtig", die richtige OS-Version ins Log zu schreiben, aber es wäre dennoch nicht schlecht für die eigene QS. (Da ich auch die C-Runtime-Dlls mit kopiere + modifiziertes Manifest kann unter verschiedenen OS durchaus mal was schief laufen)

@Ripper: Danke für den interessanten Link, aber leider hilft mir das nicht wirklich weiter. Ich muss einfach definitiv wissen, unter welchem OS die Anwendung gerade läuft.

Hallo zusammen, ich muss die Windows-Version in meinem Programm ermitteln. Das Problem an den üblichen Verdächtigen wie GetVersionEx() oder dem Auslesen des Registry-Eintrages "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" ist, dass dabei für den Fall, dass die Anwendung im Kompatibilitätsmodus gestartet wurde, als Ergebnis die Version geliefert wird, indem das Programm gerade ausgeführt wird. Beispiel: OS ist W7 64Bit Prof. in oben genannten Registry-Key steht: 6.1 (was ja auch Win7 entspricht) -> Lese ich diesen Key allerdings in meinem Program aus, das im Kompatibilitätsmodus gestartet wurden, bekomme ich entsprechend andere Werte. Die Ergebnisse von GetVersionEx verhalten sich genau so. Kennt einer eine Möglichkeit, die "echte" Windows-Version sicher zu bestimmen? Oder. was mir auch weiterhelfen würde: Gibt es eine Möglichkeit festzustellen, ob die Anwendung im Kompatibilitätsmodus gestartet wurde? Ich kann in meinem Programm die WinAPI und QT 4 nutzen.

Meinst du mit 2 Einträgen, wirklich zwei Items, oder verwechselst du das mit 2 Spalten. QTreeWidgetItem *cities = new QTreeWidgetItem(treeWidget); cities->setText(0, namenanzeigen); cities->setText(1, phoneanzeigen); cities->setText(2, emailanzeigen); Dieser Code erzeugt nämlich nur 1 Item über drei Spalten. Ich behaupte mal, dass er deinen Slot mehrfach aufruft, weil obwohl nur ein Item da ist, für jede Spalte des Items der Slot einmal aufgerufen wird. Dies kannst du leicht nachprüfen, indem du den Parameter "col" in deinem Slot mal auswertest.

Hallo zusammen, ich habe folgendes Problem: Ich starte eine Setup.exe mit ShellExecuteEx() und warte dann mit WaitForSingleObject() auf das Ende: bool exec( DWORD &ExitCode, QString &program, QString &arguments ) { SHELLEXECUTEINFO se; ZeroMemory( &se, sizeof(se) ); se.cbSize = sizeof(se); se.fMask = SEE_MASK_NOCLOSEPROCESS; se.lpVerb = L"open"; QStdWString prog(program.toStdWString()); QStdWString args(arguments.toStdWString()); se.lpFile = prog.c_str(); se.lpParameters = args.c_str(); se.nShow = SW_SHOW; if ( !ShellExecuteEx( &se ) ) return false; while( WaitForSingleObject( se.hProcess, 1000 ) == WAIT_TIMEOUT ) qApp->processEvents(QEventLoop::AllEvents, 100); GetExitCodeProcess( se.hProcess, &ExitCode ); // Close process and thread handles. CloseHandle( se.hProcess ); return true; } Aber die Setup.exe die ich starte, kopiert sich selbst ins %TEMP% und startet sich von da. Sobald die ursprüngliche Instanz beendet wurde, wird die while-Schleife verlassen. Ich müsste aber solange warten, bis auch die zweite aus %temp% gestartete Instanz samt eventuell weiterer Kindprozesse beendet wurde. Hat da jemand vielleicht eine Idee? Danke im Voraus.

Hallo Myschkin, also zu deiner Therapie: Da du es schon in den Bewerbungsunterlagen erwähnt hast, würde ich es an deiner Stelle auch kurz im Gespräch erwähnen. Du solltest dir aber überlegen, wie du auf Fragen diesbezüglich reagierst bzw. antwortest. Ich würde auch stets betonen, dass die Therapie ein Erfolg war. Du solltest auch darlegen, dass keine weitere Therapie erforderlich sein wird. (Lange Fehlzeiten während der Ausbildung oder auch später nach der Übernahme kommen nicht gut an). Nun zu deinen Stichpunkten: Insgesamt lesen sich diese Punkte ehrlich gesagt wie wenn sie aus einem Ratgeber für Vorstellungsgespräche wären, sprich sie sind sehr präzise und gut durchdacht. (Was ja kein Nachteil ist, da es zeigt, dass du dir Gedanken gemacht hast). Mir fallen auf den ersten Blick auch keine Widersprüche bei den Punkten auf. Ich persönlich würde das Unternehmen auch noch fragen, wie es mit externen Fortbildungen/Zertifizierungen aussieht. Dieser Punkt ist nämlich nicht zu vernachlässigen, da man ja immer auf dem neuesten Stand bleiben sollte. Gruß Manuel

Super, genau das habe ich gesucht. (Leider habe ich die ganze Zeit in der Doku unter "Windows Versions" gesucht) :old Vielen Dank

Hallo zusammen, ich bin auf der Suche nach einer Möglichkeit um festzustellen, ob das Windows-System auf dem mein Programm gerade läuft (ne Installation) ein Terminalserver ist. Ich kann die WinAPI und das Framework Qt4 in meinem Programm nutzen. Hab schon beide Dokus durchgeschaut, aber leider ohne Erfolg. :confused: Vielleicht hat ja einer von euch eine Idee. Danke im Voraus.

Also wenn ich das richtig interpretiere, was du willst, führt die Lösung deines Problems über ein eigenes Signal. Du connectest das Signal itemClicked(..) des ListWidgets mit einem neuen Slot. In diesem Slot schickst du dann dein eigenes Signal mit den Maps als Parametern. Dieses Signal connectest du dann zu deinem eigentlichen Slot uebersetzung_unten.

Solche Fehler macht man nur einmal, dann merkt man sichs. Hab mir übrigens devC++ mal angeschaut, ich kann da auch kein Ouputfenster finden. Meiner Meinung nach ist devC++ eine recht pragmatische Umsetzung einer IDE. Wenn du ohne große Integrationsarbeiten Qt-Applikationen entwickeln bzw. debuggen willst, empfehle ich dir lieber das auch kostenlose Code::Blocks Das hat standardmäßig Qt integriert.

Heute abend schaue ich mir den Dev mal an, kann mir echt nicht vorstellen, dass du da kein Output-Fenster hast. Mir ist noch was aufgefallen: bei der connect-Anweisung braucht du keine Variablennamen anzugeben. Also statt: connect(listWidget, SIGNAL(itemClicked(QListWidgetItem * item)), this, SLOT(lol(QListWidgetItem * item))); lieber: connect(listWidget, SIGNAL(itemClicked(QListWidgetItem*)), this, SLOT(lol(QListWidgetItem*))); Ich glaube zwar nicht, dass das die Ursache für dein Problem ist, denn ich schreibe nie Bezeichner zu den Variablen dazu, das ist einfach bei connects weder notwendig, noch üblich. Probiers bitte mal ohne "item" vielleicht geht es dann.

Der Menüpunkt heißt wahrscheinlich irgendwas in der Richtung -An Prozess anhängen, oder halt Englisch attach to process, oder so... wo (in welcher Funktion) steht denn deine connect-Anweisung?

Poste mal die connect-Anweisung, wie du sie mit dem Parameter hattest. Der Teufel steckt bei connects im Detail. Was machst du denn in deinem Slot? Bist du dir sicher, dass der Slot nicht aufgerufen wurde, als du beim connect den Parameter angegeben hast? Wenn du deine Exe startest, startest du sie dann über devC++? Falls nicht, kannst du dich dann nicht im nachhinein an die Exe attachen? Der Debug-Output wäre nämlich wirklich hilfreich.

Wie entwickelst du? Du nutzt doch sicher eine IDE, oder? Debug starten, irgendwo sollstest du dann ein Fenster mit Debugouput sehen, oder als Option anschalten können. Leider oft ignoriert, obwohl da sehr nützliche Details ablesbar sind, z. B. kann man daraus auch ablesen, welche DLL von wo geladenw wurde. Naja.. Auf jeden Fall taucht in diesem Output meist bei falschen connects eine Meldunge wie: QObject::connect(): No such signal .... / NO such slot.... auf. Wenn ich mir deine connect-Anweisung so ansehen, tippte ich auf: QObject::connect(): No such signal: itemClicked() Ohne jetzt einen Blick in die Doku zu werfen behaupte ich mal, dass das Signal, einen Parameter besitzt, wahrscheinlich QListWidgetItem*. Denn die Info, dass ein Item angeklickt wurde, ohne die Zusatzinfo welches Item, macht nicht viel Sinn. Also Blick in die Doku, und connect-Anweisung korrigieren.

Das ist richtig, allerdings lohnt sich bei nicht funktionierenden connects immer ein Blick in den Debug-Output. Da kommt nämlich durchaus eine Meldung, wenn was mit deinem connect nicht stimmt. Mit welchem Slot willst du connecten? Ist der Slot von einer anderen Qt-Klasse, oder von deiner eigenen Klassen? Wenn eigene Klassen, dann sicherstellen, dass in deiner Klasse das Q_OBJECT Macro enthalten ist und der Header durch den moc läuft. Wenn du es nicht hinbekommst, poste mal deine Klassendefinition und deine connect-Anweisung, dann kann ich dir mehr sagen.