Seite 129 von 252

Re: Jammer-Thread

Verfasst: 02.06.2014, 23:12
von antisteo
Meine Windows-VM startet sich aus irgendwelchen mystischen Gründen regelmäßig alle paar Tage neu. Und das ohne zu fragen, ob ich speichern will. Außerdem dauert das Hoch- und Runterfahren ewig wegen so komischen Updates. Das ist gruselig.

Re: Jammer-Thread

Verfasst: 03.06.2014, 07:50
von Artificial Mind
antisteo hat geschrieben:Meine Windows-VM startet sich aus irgendwelchen mystischen Gründen regelmäßig alle paar Tage neu. Und das ohne zu fragen, ob ich speichern will. Außerdem dauert das Hoch- und Runterfahren ewig wegen so komischen Updates. Das ist gruselig.
Und du bist sicher, dass das nicht einfach nur Windows Update ist, was einen Neustart erzwingt?
Also quasi sowas: http://answers.microsoft.com/en-us/wind ... e427756ccc

Re: Jammer-Thread

Verfasst: 03.06.2014, 15:14
von antisteo
Artificial Mind hat geschrieben:
antisteo hat geschrieben:Meine Windows-VM startet sich aus irgendwelchen mystischen Gründen regelmäßig alle paar Tage neu. Und das ohne zu fragen, ob ich speichern will. Außerdem dauert das Hoch- und Runterfahren ewig wegen so komischen Updates. Das ist gruselig.
Und du bist sicher, dass das nicht einfach nur Windows Update ist, was einen Neustart erzwingt?
Also quasi sowas: http://answers.microsoft.com/en-us/wind ... e427756ccc
Mir ist Wurscht, ob das am Update, an der Zeitumstellung oder am Feiertag liegt - der Rechner soll nicht neu starten, wenn ich ihn gerade benutze!

Re: Jammer-Thread

Verfasst: 04.06.2014, 15:37
von Krishty
Ich habe nie verstanden, warum C nicht das Definieren einer Funktion auf Basis eines typedefs bietet. A la

  typedef LRESULT (WINAPI WndProc)(HWND hWnd, ULONG msg, WPARAM wParam, LPARAM lParam);

  WndProc myWndProc {
    return DefWndProc(hWnd, msg, wParam, lParam);
  }

  registerCallback(…, &myWndProc, …);


Irgendwo ändert man einen Parameter von ULONG auf DWORD und schon hören 100 Callbacks auf zu funktionieren und ich muss 100 identische Deklarationen austauschen. IGITT IGITT IGITT

Ich benutze zwar #defines für die Köpfe meiner Callbacks, aber dann sind es immernoch mindestens zwei Stellen. Bah!

Re: Jammer-Thread

Verfasst: 04.06.2014, 15:38
von dot
Gibt doch eh #define :mrgreen:

Re: Jammer-Thread

Verfasst: 04.06.2014, 15:39
von Krishty
Ups; da war ich mit dem Nachtragen zu langsam :P

Re: Jammer-Thread

Verfasst: 13.06.2014, 14:07
von Schrompf
Ich verachte PHP. Es vereint die kleinkarierte Mühsamkeit von C++ mit all den Laufzeitunsicherheiten einer dynamisch typisierten Sprache, und läuft dazu auch noch auf einem fernen Rechner, womit man wieder im Keller der Softwareentwicklung mit printf-Debugging anfangen darf.

Re: Jammer-Thread

Verfasst: 13.06.2014, 14:36
von Tiles
Drei S-Ata Geräte zum Einbauen zu haben und nur 2 S-Ata Kabel mitgeliefert zu bekommen ist übrigens fies!

Re: Jammer-Thread

Verfasst: 13.06.2014, 21:23
von waigie
Schrompf hat geschrieben:[...] womit man wieder im Keller der Softwareentwicklung mit printf-Debugging anfangen darf.
Wenn xdebug installiert ist und die du Zugriff auf die php.ini hast, kannst du die Vorteile eines Debuggers nutzen.

Re: Jammer-Thread

Verfasst: 17.06.2014, 13:20
von Krishty
Können wir uns jetzt bitte darauf einigen, dass Blogs auf die alten Beiträge nach RECHTS verweisen?

Danke

Re: Jammer-Thread

Verfasst: 20.06.2014, 13:35
von Krishty
Ich habe es verpasst, meinen 2^12ten Beitrag mit beißendem Zynismus, ironischen Wendungen, nostalgischen Rückbezügen, GIFs, Schachtelsätzen, und Auslassungspunkten auszuschmücken.

Re: Jammer-Thread

Verfasst: 20.06.2014, 13:54
von Schrompf
Und speziell der Mangel an GIFs ist betrüblich.

Re: Jammer-Thread

Verfasst: 20.06.2014, 14:41
von Krishty
Ja; die liegen dummerweise auf meiner /b/-Festplatte am anderen System. Meine Familie gestattet mir auch nicht mehr, die vor Einbruch der Dunkelheit anzuschließen.

Besagte Platte ist übrigens ein WD MyBook, und ich habe – um beim Jammern zu bleiben – gerade festgestellt, dass die Hardware-verschlüsselt sind. Aua.

Re: Jammer-Thread

Verfasst: 21.06.2014, 00:19
von Krishty
ARGH die QuickInfo von Visual Studio (2012) ist so scheiße. Ich habe ein riesen Array, und sobald ich mit dem Cursor versehentlich über den Namen der Variable streife, hängt die Maschine geschlagene 2 min und spuckt ein Monster aus wie das hier (zu Beispielzwecken verkleinert):
quickinfo.png
  • Warum hängt der vor jeden Wert einen C-Cast?! Der steht NICHT in meinem Quelltext
  • Ist da niemand auf die Idee gekommen, dass 100 Buchstaben QuickInfo schon genug sind?!
Wenn mir das auf meinem Netbook passiert, kann ich entweder die Änderungen wegschmeißen und Visual Studio beenden, oder 15(!) Minuten warten bis es wieder reagiert. OMG WER MACHT SO EINE SCHEIßE

Re: Jammer-Thread

Verfasst: 22.06.2014, 20:14
von Aramis
Man injiziere hier eine Factory, die als Webservice verfuegbar ist und via SOAP dazu gezwungen wird, ein riesiges, persistentes, verteiltes, zustandsbehaftetes, aufgeblasenes Jammern auf den gesamten Enterprise-Java-Kram loszuwerden und sich dabei auch noch dauerhaft als Eclipse-Plugin (mit einem aus einem Metamodell abgeleiteten grafischen Designer) einnistet. Selbiges Jammern natuerlich in XML.

Re: Jammer-Thread

Verfasst: 27.06.2014, 10:57
von Krishty
Jahrelang die Dialoge falsch gezeichnet. Statt SetWindowPos() aufzurufen wenn sich die Dialoggröße ändert, muss man DeferWindowPos() benutzen. Dann wird einmal atomar neu gezeichnet statt bei n Controls n Mal zu zeichnen (flacker flimmer flacker flacker):

Code: Alles auswählen

  struct ChildWindowArea {
    SignedInt4B   x; // relative to the left edge of the parent's client area
    SignedInt4B   y; // relative to the upper edge of the parent's client area
    UnsignedInt4B widthInPixels;
    UnsignedInt4B heightInPixels;
  };

  // Positions one or more windows sharing a common parent. Causes one redraw instead of n.
  bool layOutChildWindows(
    HWND const *            toChilds,
    HWND const * const      toEndOfChilds,
    ChildWindowArea const * toNewPositions
  ) {
    MUST(toEndOfChilds > toChilds && 0x7FFFFFFF >= toEndOfChilds - toChilds); // WinAPI limit
#   if _DEBUG
      auto const commonParent = GetParent(toChilds[0]);
#   endif

    // "By specifying the maximum size needed, an application can detect and process failure early in the process."
    auto state = WINAPI_SHOULD_SUCCEED(BeginDeferWindowPos(int(toEndOfChilds - toChilds)));
    if(nullptr == state) {
      return no;
    }

    do {
#     if _DEBUG
        MUST(commonParent == GetParent(*toChilds));
#     endif
      MUST(65536 >= toNewPositions->widthInPixels); // Reasonable?
      MUST(65536 >= toNewPositions->heightInPixels); // Reasonable?

      // Since all resources have been allocated upfront, this call cannot fail. Note: "The handle returned by this function
      //  may differ from the handle passed to the function."
      state = WINAPI_SHOULD_SUCCEED(DeferWindowPos(state,
        *toChilds,
        nullptr, // ignored due to 'SWP_NOZORDER'
        toNewPositions->x, toNewPositions->y, int(toNewPositions->widthInPixels), int(toNewPositions->heightInPixels),
        SWP_NOZORDER | SWP_NOOWNERZORDER | SWP_NOACTIVATE
      ));

    } while(++toNewPositions, ++toChilds < toEndOfChilds);

    WINAPI_SHOULD_SUCCEED(EndDeferWindowPos(state));
    return yes;
  }

Code: Alles auswählen

  void FooDialog::resize() {
    HWND const            controls[3] = { okButton, cancelButton, retryButton };
    ChildWindowArea const positions[3] = { ... };
    layOutChildWindows(toBeginningOf(controls), toEndOf(controls), toBeginningOf(positions));
  }

Re: Jammer-Thread

Verfasst: 27.06.2014, 11:15
von Schrompf
Die D3DPRESENT_PARAMETERS haben einen Member hDeviceWindow. Aber wenn man eins angibt, um das Device bei D3DDevice::Reset() auf ein neues Fenster umzubiegen, scheitert der Aufruf. Gut, dass es sowas gibt.

Re: Jammer-Thread

Verfasst: 27.06.2014, 12:05
von Krishty
Ich denke, dass du dafür eine neue Swap Chain anlegen musst. Reset() interessiert nur das Fenster, mit welchem Direct3D GPU-Zeit anfordern wird; nicht das Fenster, in dem letztlich angezeigt wird. Wenn du keine manuellen Swap Chains anlegst, nutzt D3D dieses Kontext-Fenster zugleich zum Anzeigen, und das stiftet dann diese Verwirrung. In deinem Fall solltest du ein unsichtbares Dummy-Fenster anlegen, das für die Laufzeit der Anwendung bestehen bleibt und als Fokus-Fenster verwenden, während du für die Ausgabefenster eigene Swap Chains anlegst. (Ich hasse das auch. Zum Glück wurde das mit D3D 10 deutlich vereinfacht.)

Viele wissen auch nicht, dass die D3DPRESENT_PARAMETERS (und DXGI_SWAP_CHAIN_DESC) Ein- und Ausgabeparameter zugleich sind: Bei Erfolg wird hineingeschrieben, welche Einstellungen Direct3D wirklich verwendet. Im Fenstermodus kann man also Breite, Höhe, Format, und Aktualisierungsrate auf 0 setzen und nach dem Aufruf bequem auslesen, wie groß das Zielfenster ist und in welchem Format der Desktop vorliegt. So spare ich mir jede Menge GetClientRect()s.

Leider hat die MSDN erst letztes Jahr angefangen, darauf hinzuweisen; darum gehen zu viele Leute den mühsamen Umweg erst die Desktop-Farbtiefe / Aktualisierungsrate / Fensterauflösung / usw festzustellen.

Re: Jammer-Thread

Verfasst: 27.06.2014, 12:31
von Schrompf
Ich wollte ja allen eigenen Fenstercode rausschmeißen und GLFW benutzen. Nun bin ich aber schon wieder fröhlich am Hacken dieses Codes. Hab erstmal reingehackt, dass der optional auch gar keinen OpenGL-Kontext anlegt, damit ich meinen getesteten und optimierten D3D-Renderer weiterverwenden kann. Und jetzt hacke ich grad rein, dass der dynamisch zwischen Vollbild und Fenstermodus wechseln kann. Laut hastigem Googlen kann SFML und SDL das, es sollte also auf den drei Plattformen Win/Mac/Linux jeweils funktionierender Code dafür existieren.

Gonna give back to the community und so... Bin nur nicht sicher, ob die das dann am Ende überhaupt haben wollen. Die Message Pump muss ich ja auch selbst machen, sonst geht mein ganzer RawInput-Code für multiple Mäuse&Tastaturen nicht mehr.

Re: Jammer-Thread

Verfasst: 27.06.2014, 13:22
von Krishty
Krishty hat geschrieben:Jahrelang die Dialoge falsch gezeichnet. Statt SetWindowPos() aufzurufen wenn sich die Dialoggröße ändert, muss man DeferWindowPos() benutzen. Dann wird einmal atomar neu gezeichnet statt bei n Controls n Mal zu zeichnen (flacker flimmer flacker flacker):
P.S. weil ich gerade eine Katze hier durchhuschen gesehen habe: Zustandslose Controls wären natürlich die mit Abstand einfachste Lösung für sowas (und viel mehr)!

Re: Jammer-Thread

Verfasst: 28.06.2014, 21:45
von Krishty
Zum ersten Mal seit zwei Jahren Internet ohne Volumenlimit.

Und König der Löwen ist abstoßend antidemokratische, antisozialistische Propaganda.

Re: Jammer-Thread

Verfasst: 01.07.2014, 18:08
von Schrompf
Ich glaube, ich habe mich vor einigen Jahren schonmal darüber beschwert, aber ich bin grad eben wieder in die Falle getappt, als ich Tutorial-Code aus dem Internet kopiert und mit MSVC2013 gebaut habe.

Code: Alles auswählen

void Funktion( const char* text, ...) { ... }
void Funktion( const char* text, va_list params) { ... }

std::vector<char> text( 1, 0); // Text nur aus dem abschließenden Nullbyte bestehend
Funktion( "%s", text.data()); // Crash
Der Visual C++-Compiler wählt aus mir bislang unbekannten Gründen dort die va_list-Überladung, nicht die Ellipse. Und das crasht natürlich tief im vsprintf() drin.

Re: Jammer-Thread

Verfasst: 02.07.2014, 14:40
von antisteo
2 Tage Arbeit im Öffentlichen Dienst hinter mir. Ich fühle mich wie ein HARTZ-IV-Empfänger, der doppelt so viel bekommt, aber nur halb so viel Formulare dafür ausfüllen muss. Ich glaube, ich gehe da nicht mehr hin und warte, bis der bürokratische Apparat mir das Gehalt entzogen hat. Genug andere Sachen gibt es ja zu tun.

Re: Jammer-Thread

Verfasst: 03.07.2014, 09:40
von Artificial Mind
Hat sich ein -Wall (statt W3) ins Visual Studio Projekt eingeschlichen. VS hängt dann natürlich bei jedem Build sofort, da es mehrere Zehntausend Fehler pro Datei gibt (die meisten direkt aus std:: ).

Re: Jammer-Thread

Verfasst: 03.07.2014, 11:00
von kimmi
Einmal einen Tag Gartenarbeit und nun fast schon 1 Woche dank gezerrter Schulter ( ja, ich mache Sport ) kaum bewegungsfähig. Man wird alt :).

Gruß Kimmi

Re: Jammer-Thread

Verfasst: 03.07.2014, 21:20
von Krishty
4000 Dateien in einem Verzeichnis anlegen, aber nicht schließen. Programm beenden um Windows die Dateien schließen zu lassen. Währenddessen ein Explorer-Fenster auf das Verzeichnis offenhalten.

Ab und zu hängt sich der Explorer mit 100 % CPU-Auslastung auf und verhindert, dass sich der Benutzer abmelden kann. Urks

Re: Jammer-Thread

Verfasst: 04.07.2014, 10:38
von kimmi
Wenn du nun noch einen dynamischen View in ClearCase ( IBM's Antwort auf Subversion ) benutzt,m kannst du dir Kaffee aus Brasilien holen :).

Kimmi

Re: Jammer-Thread

Verfasst: 05.07.2014, 17:04
von Krishty
Naja … langsam ist kein Problem. Aber Aufhängen geht nicht (habe 8 Stunden gewartet). Es gibt auch kein sichtbares Zeichen dass etwas schief lief; alles ist normal, nur zwei Instanzen von explorer.exe verbrauchen je einen ganzen Kern. Das stinkt zum Himmel.

————

Ich bastle gerade einen Hex-Editor und OMG das Scrollen bringt mich um. Nicht nur die tatsächliche Logik dahinter ist, like, REALLY haarsträubend, sondern die WinAPI hat sich wieder eine halbe Million Möglichkeiten zusammengezimmert: Tasten, Scrollbars, Maus. Relative oder absolute Offsets. Like OMG ich habe ja nichts Besseres zu tun als eure like 100 Spezialfälle zu einem scrolled(deltaInLines) zusammenzuabstrahieren, ihr Code-Schlampen …

Re: Jammer-Thread

Verfasst: 06.07.2014, 19:26
von Krishty
Krishty hat geschrieben:Zum ersten Mal seit zwei Jahren Internet ohne Volumenlimit.
Komischerweise reißt die Verbindung aber immer nach ziemlich genau 50 GiB (also 7 Stunden bei 16 mbit) ab. WTF

Im Router steht nichts Brauchbares – nur, dass ein paar Domains timeouten und dass ein paar IP-Adressen nicht vergeben werden können. Kacke

Nachtrag: Schon wieder. Nach 46.800.000.000 B.

Re: Jammer-Thread

Verfasst: 09.07.2014, 21:41
von Krishty
Fünf Tage am Hex-Editor gearbeitet. Jetzt bemerke ich im Alltag Sehbeeinträchtigung; wahrscheinlich vom ewigen aufs-Hex-Gitter-starren. Fuck fuck fuck fuck
14-07-09 0xf00f00.png