whizzle

Hallo Ihrs, welche Möglichkeiten gibt es, einen hängengebliebenen Job (dbms_job, Oracle 10g) zu 'untersuchen', d.h. die Ursache zu ermitteln und eine Lösung des Problems zu finden (diese Lösung, z.B. Session killen, soll in meinem konkreten Fall automatisiert stattfinden). Kann mir jemand Tips geben, die Sache anzugehen - abgesehen von ALTER SYSTEM KILL SESSION?? Aber selbst in diesem Fall müsste ich immer noch _in jedem Fall_ feststellen können, welche Session der Übeltäter ist... :confused: Besten Dank im voraus.. Christian

Hallo zusammen, ich benötige umfassende Infos dazu, welche Einschränkungen es bei der Namensvergabe beim Erstellen eines Datenbank-Users (Oracle8i) gibt. Ich denke da an Länge, Sonderzeichen etc. Thx

Hab des Rätsel's Lösung selbst gefunden: man MUSS (!!!!!) der Funktion, die asynchron aufgerufen werden soll, irgendeinen DWORD im Parameter dwContext mit auf den Weg geben, der dann an die Callback-Funktion weitergegeben wird. Tut man dies nicht (z.B., weil man gar keine weiteren Infos in der Callback-Funktion braucht), macht good old Windows aus der asynchronen Funktion eine synchrone. Danke, Billy...

Leider kann ich nicht direkt über Ftp rausgehen, da unser CERN-Proxy das unterbindet. Die entsprechenden Funktionen schlagen somit alle fehl. Ich muss also das HTTP-Protokoll benutzen (InternetOpenUrl(..)), dann klappt der Funktionsaufruf, nur - wie oben beschrieben - die Callback-Funktion macht ärger!

Hallo zusammen, da Ihr die Fortsetzung meines Thread weiter unten ja erfolgreich ignoriert habt, versuche ich es hier jetzt nochmal Ich habe mein Problem mal gänzlich in eine eigene Mini-App isoliert, den Code seht Ihr unten. Mein Problem ist weiterhin, dass alle Funktionen erfolgreich aufgerufen werden, d.h. der Zugriff auf die Url sollte eingeleitet sein. Im synchronen Modus klappt's auch. Allerdings kommt im asynchronen Modus meine Callback-Funktion (AsyncFunc(...), siehe unten) nie zum Aufruf. VOID CALLBACK AsyncFunc( IN HINTERNET hInternet, IN DWORD dwContext, IN DWORD dwInternetStatus, IN LPVOID lpvStatusInformation, IN DWORD dwStatusInformationLength ) { MessageBox(NULL, "Callback-Funktion wurde aufgerufen", "", 0); } int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) { HANDLE hSession = NULL, hResource = NULL; hSession = InternetOpen("TestApp", INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, INTERNET_FLAG_ASYNC); InternetSetStatusCallback(hSession, (INTERNET_STATUS_CALLBACK)AsyncFunc); hResource = InternetOpenUrl(hSession, "ftp://ftp.microsoft.com/developr/readme.txt", NULL, 0, 0, 0); DWORD dw = GetLastError(); if( !hResource && (dw == ERROR_IO_PENDING)) MessageBox(NULL, "Anfrage läuft", "", 0); // Warten, und warten, und weiter warten....schnarch // Schleife, Dialog o.ä. if(hResource) InternetCloseHandle(hResource); if(hSession) InternetCloseHandle(hSession); return 0; } Hat jemand eine Idee?? Nochmal Danke und Gruß

Da bin ich wieder...und habe inzwischen eine einwandfreie Verbindung zu beliebigen Ftp-Servern hergestellt, Dateien runtergezogen etc. Allerdings muss ich mich immer wieder ärgern, wenn der Server überlastet ist oder der Verbindungsaufbau aus sonstigen Gründen seeeehr lange dauert (beim IE scheint dann der blaue Fortschrittsbalken stehenzubleiben). Die einzige Möglichkeit, den Vorgang abzubrechen, ist, den Thread gewaltsam zu beenden ( TerminateThread(...) ). Daher muss ich das ganze jetzt asyncron auf die Kette bekommen. Das sieht dann folgendermaßen aus: ////////////////////////////////////////////////////////////// // WinINet-API initialisieren // static HINTERNET hInternet, hResource; hInternet = InternetOpen(szModuleFileName, INTERNET_OPEN_TYPE_PRECONFIG, NULL, 0, INTERNET_FLAG_ASYNC); ///////////////////////////////////////////////////// // Callback-Funktion für asyncronen Download // anmelden // InternetSetStatusCallback(hInternet, AsyncLoadFunc)); ////////////////////////////////////////////////// // // HTTP-Anfrage an URL absetzen // hResource = InternetOpenUrl(hInternet, pUrl, NULL, 0, INTERNET_FLAG_RELOAD | INTERNET_FLAG_DONT_CACHE | INTERNET_FLAG_PRAGMA_NOCACHE, 0); if(!hResource && (GetLastError() == ERROR_IO_PENDING)) { ////////////////////////////////////// // // Anfrage erfolgreich abgesetzt // } Soweit klappt's auch, alle Funktionen melden "Erfolg". Bloß: meine Callback-Funktion kommt nie zum Aufruf! Und nu? Hier noch ein wertvoller Link, der mich an dieser Stelle aber auch nicht weiterbringt. http://www.codeproject.com/useritems/asyncwininet.asp#xx84726xx Gruß

Jo, super, das sieht gut aus. Hab's zwar noch nicht ausprobiert, aber es ist genau mein Problem. Wenn ich nicht weiterkomme, werde ich mich nochmal hier melden, bis dahin vielen Dank !! Gruß und Kniefall

Ja schon, aber dies ist ja die Authentifizierung für den Ftp-Server. Ich muss mich - bevor ich überhaupt an ihn rankomme - gegenüber dem Proxy-Server ausweisen. Und da liegt das Problem...

Maaahlzeit! Ich versuche mich gerade erfolgelos an folgendem: hInternet = InternetOpen(szAppName, INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, INTERNET_FLAG_ASYNC); hFtpConnect = InternetConnect(hInternet, _("Ftp://Ftp.Beispiel.com/"), INTERNET_INVALID_PORT_NUMBER, NULL, NULL, INTERNET_SERVICE_FTP, 0, 0); Leider schlägt letztere Funktion immer fehl, was wohl an unserem Firmen-Proxy liegt. Er verlangt nämlich eine Authentifizierung des Users. Ich weiss, dass ich der Funktion Benutzer u. Passwort mit auf den Weg geben kann, allerdings nur für einen Http-Zugriff. Das funktioniert auch wunderbar. In der Plattform-SDK habe ich einen Artikel gefunden, der die Lösung meines Problems beschreibt, allerdings auch nur für das Http-Protokoll. Dort wird auch erwähnt, dass es zur Zeit keine Möglichkeit gibt, die Lösung auf's Ftp-Protokoll zu übertragen. Nur: Handelsübliche Browser können's doch auch?!? Ich benutze übrigens das Visual Studio 6.0 und die Win32-API, keine MFC. Weis jemand Rat? Danke und Gruß

KRITIK AN MEINER MEINUNG?? WO GIBT'S DENN SO WAS?!? MIR PLATZT DER AR... Nö, ist schon Ok, ich habe ja drauf hingewiesen, das es kein Buch zum "erlernen" im eigentlichen Sinne ist, schon gar nicht für Anfänger. Aber es enthält ebenfalls viele Code-Beispiele und Übungsaufgaben, sein "Problem" ist nur - wie Du schon sagst - dass es so umfangreich ist, das man es gerne mal als reine Sprachreferenz ansieht. Aber jetzt möchte ich Dich mal "nicht kritisieren"... Von Tutorials halte ich nicht so viel, weil sie meistens so halbherzig geschrieben und unvollständig sind. Gibt bestimmt auch Ausnahmen, aber mir ist bisher noch keine untergekommen. Daher würde ich letzteres eher Hobby-Programmierern ans Herz legen. Also nix für ungut, Gruß

Hallöle, für den Anfang empfehle ich "Das C++-Grundlagenbuch". Ich selbst hatte noch "Das C-Grundlagenbuch", aber das war wirklich seine ca. 90-100 DM wert (ca. 1000 Seiten). Wenn Du Dich dann eingearbeitet hast und sicher bist, Dich an die "Denkweise in C++" gewöhnt zu haben, nimm Dir "Die C++ Programmiersprache" von B. Stroustrup zur Hand. Dieses Buch ist schon eine ganze Ecke anspruchsvoller, aber auch sehr vollständig und (meiner Meinung nach) unabdingbar für jemanden, der sich von Berufswegen mit C++ beschäftigt. Gruß

Nö, so ähnlich schaut's auch bei mir aus. Aber wenigstens bekommst Du realistische Werte. Vielleicht bleiben die ja bei Dir konstant, weil die Änderung der Schriftgröße fehlschlägt?? Sicher das letzteres funktioniert?

Na ja, halt folgendes: Wenn die Angaben in der SIZE-Struktur die Größe des Strings in logischen Einheiten wiedergeben (der Mapping-Mode ist - wie gesagt - MM_TEXT, demnach sind die Einheiten "Pixel"), dann ist mein String (in diesem Fall ein einfaches 'H') 78 mal 120 Pixel groß. Und das finde ich sehr, sehr groß, schließlich ist die Schriftgröße 12 Pt... Wenn man's mal andersherum rechnet: 12 Pt sind 12/72 Zoll, also 1/6 Zoll. Bei der Windows-Einstellung "Kleine Schriftarten" entsprechen 96 Pixel einem Zoll, also müsste eine 12 Pt-Schrift 16 Pixel groß sein (und nicht 120). Natürlich stimmt diese Rechnung für Monitore nur begrenzt, aber eine Abweichung von immerhin 650% würden mir schon die Tränen in die Augen treiben... Oder rechne ich die ganze Geschicht einfach falsch? Gruß

Hallo zusammen, ich habe folgendes Problem: Ich möchte mittels der Funktion GetTextExtentPoint32() die Größe eines Strings ermitteln, eigentlich ganz simpel. Unter W9x hat dass immer doll geklappt, aber nu versuch ich's zum erstenmal unter W2k und bekomme sehr merkwürdige Werte zurück, obwohl diese doch die Größe in logischen Einheiten angeben sollten, oder? Hier mal ein konkretes Beispiel: Schrift: Arial Schriftgröße: 12 Pt (Wert 120 in der LOGFONT-Struktur) Mapping-Mode: MM_TEXT Ergebnis der Funktion GetTextExtentPoint32() beim String "H" SIZE.cx == 78 SIZE.cy == 120 Kann mir das einer erklären? Inflation? Euro-Umstellung??

Hi Tachyoon, nimm Dir am besten den "Petzold" zur Hand (dicker Wälzer zur Windowsprogrammierung von Charles Petzold, Titel: "Windowsprogrammierung - Das Entwicklerhandbuch zur Win32-API"). Das ist einer sehr ordentliche Grundlage. Willst Du Dich mit den "Microsoft Foundation Classes" (MFC) vertraut machen, empfehle ich Dir "Windowsprogrammierung mit MFC". Author weiß ich leider gerade nicht. Habe beide gelesen (allerdings in umgekehrter Reihenfolge), sind wirklich doll (auch bzgl. der Preise ). Zu deiner zweiten Frage: ließ gerade die ersten Kapitel recht aufmerksam durch. Später, wenn die fortgeschrittenen Themen angesprochen werden, wirst Du wohl immer mehr Stoff vorfinden, den Du eher seltener anwenden kannst/musst. Überfliege ihn einfach stellenweise und vetiefe ihn, wenn Du ihn in einem konkreten Projekt einsetzen möchtest. Das sollte gut funktionuckeln. Gruß

Hat sich erledigt. Hatte in einem anderen Thread vergessen, einen Handle freizugeben... Gruß

Hallo Z'sam und 'n frohes neues, bei mir will die Funktion "RemoveDirectory()" unter W2k nicht so, wie ich will! Mein Prog durchsucht erstmal eine Verzeichnisstruktur auf einem Laufwerk. Dabei werden die gefundenen Dateien zusammen mit den jeweiligen Unterverzeichnissen als Strings gespeichert. In einem zweiten Schritt starte ich (wohlgemerkt NACH dem Durchsuchen der Verzeichnisse!) einen Thread, der die Verzeichnisse mit "SetCurrentDirectory("blabla")" betritt, überprüft, ob noch Dateien vorhanden sind, und - falls nein - zurückgeht (SetCurrentDirectory("..")) und das Verzeichnis löscht: RemoveDirectory("blabla"). Leider schlägt die Funktion immer fehl, und zwar bei anscheinend allen Verzeichnissen. "GetLastError()" meldet Fehler #32, d.h. ein andere Prozess hat noch Zugriff auf das jeweilige Verzeichnis. Allerdings habe ich alle Programme geschlossen (außer VC 6.0 und mein Prog). Mein Progrämmchen speichert aber doch nur die Verzeichnisnamen als Strings, hat also nix mehr mit denen am Hut. Gibt es eine Möglichkeit herauszufinden, wer noch Zugriff hat bzw. diesen zu unterbrechen und die Verzeichnisse zu entfernen? Gruß und besten Dank

Super, Schanke Döhn. Gibt es vielleicht irgentwo eine zusammenhängende Doku über die Shell-Funktionen /-objekte, um die Zusammenhänge zu begreifen? Bücher, Links? Nochmals Danke im voraus... Gruß

Hallöle zusammen, im MSDN steht, nach einem Aufruf der Funktion "SHBrowseForFolder" liege es in der Veranwortlichkeit der aufrufenden Anwendung, das ITEMIDLIST-Objekt freizugeben, und zwar unter Verwendung des "Shell's Task Allocator". Meine Frage: Was ist dieser Task Allocator und wie verwende ich ihn?? Gruß und so

Schanke döhn! Ich glaub dat isset... Gruß

Sorry, hatte vergessen zu erwähnen, dass ich direkt auf der Win32 API aufsetzte. Das Programm soll auf W2k laufen. Gruß

Hallo z'sam, weiß jemand, wie ich an das Standard-Dialogfeld "Verzeichnis wählen" herankomme (erscheint meistens nach einem Klick auf den Button "Durchsuchen..."). Oder gibt es eine Möglichkeit, das Datei-öffnen-Dialogfeld zweckzuentfremden? Gruß

Hi Crush, danke für die Mühen, aber ich denke das Problem lag woanders (an der Nachrichtenweiterleitung zum Client-Fenster). Scheint jetzt zu funktionieren. Gruß

Hallo Z'sam, hab folgendes Problem: meine MDI-Anwendung (keine MFC, nur API) soll in der Fensterprozedur des Rahmenfensters als Reaktion auf die Nachricht WM_SETFOCUS ein Dokumentfenster erstellen. Ich bekomme zwar ein Handle, aber es wird kein Fenster angezeigt und auch nicht dem Menupunkt Fenster hinzugefügt. Aber: wenn ich einen Menupunkt zum erstellen des Fensters hinzufüge (mit dem gleichen Code, der vorher bei WM_SETFOCUS stand) und bei WM_SETFOCUS anstelle des Codes ein "PostMessage(hWnd, WM_COMMAND, ID_CREATE_DOCWINDOW, 0)" einfüge, funktioniert es! Verwende ich statt "PostMessage()" "SendMessage()", funktioniert es wiederum nicht. Hat jemand eine Ahnung warum?? Danke und Gruß

Moijen! So sollte es funktionieren (ohne Gewähr, hab's nicht probiert...): Zuerst eine Variable deklarieren, die die "alte" Fensterprozedur aufnimmt, und diese mit Hilfe des Fensterhandles des Hauptfensters initialisieren: HWND hWndMain = AfxGetMainWnd()->GetSaveHwnd(); WNDPROC OldProc = GetWindowLong(hWndMain, GWL_WNDPROC); Dann eine eigene Fenster-Funktion deklarieren/definieren, die die Nachrichten (zuerst) behandeln soll: LRESULT CALLBACK MyMsgHandler(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam) { switch(nMsg){ case WM_CREATE: ... break; // auch "return 0;" ist möglich, dann dürfte die // Nachricht allerdings von Windows nicht weiter // bearbeitet werden case... case... }; return CallWindowProc(OldProc, hWnd, nMsg, wParam, lParam); } Diese eigene Fenster-Prozedur dem Hauptfenster zuordnen: SetWindowLong(hWndMain, GWL_WNDPROC, MyMsgHandler); Wie gesagt, in MFC-Programmen hab ich's noch nicht probiert. Bis denn