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.