Hi, hast du mal versucht ihm explizit das Layout anzugeben?

//edit ansi statt unicode in deinem fall
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)] 
 public struct DHCPPacket
    {
        public byte op;
        public byte htype;
        .
        .
        .
    } 

Charset sollte für ihn ziemlich interessant sein! Davon hängt die Größe von sname bzw. file ab...

Offenbar soll es einen Bug in
PrivateFontCollection.AddMemoryFont geben, ob das stimmt, weiß ich nicht. Scheint so, weil der explizite externe Call irgendwie überflüßig erscheint.

Don't use AddMemoryFont, but extract the font to the temp directory and load it from there using AddFontFile

Scheint ein akzeptabler Work-around zu sein, wenn man die Ressource entpacken möchte statt sie im Speicher zu haben.

Das leidige Thema hatte ich leider auch schon:

private PrivateFontCollection pfc = new PrivateFontCollection();

 [DllImport("gdi32.dll")] 
        private static extern IntPtr AddFontMemResourceEx(IntPtr pbFont, uint cbFont, IntPtr pdv, [In] ref uint pcFonts); 

 private void LoadIt()
        {

            Stream resStream = this.GetType().Assembly.GetManifestResourceStream ("WindowsFormsApplication7.Resources.FONTNAME.TTF");
            IntPtr fontptr = Marshal.AllocCoTaskMem (Convert.ToInt32(resStream.Length));
            byte[] theFont = new byte[resStream.Length];
            resStream.Read(theFont, 0, Convert.ToInt32(resStream.Length));
            Marshal.Copy(theFont, 0, fontptr, Convert.ToInt32(resStream.Length));
            uint ret = 0;
            AddFontMemResourceEx(fontptr, (uint)theFont.Length, IntPtr.Zero, ref ret);
            pfc.AddMemoryFont(fontptr, Convert.ToInt32(resStream.Length));

            resStream.Close();
            Marshal.FreeCoTaskMem(fontptr);

            this.label1.Font = new Font(this.pfc.Families[0],12,FontStyle.Bold);
                     
        }

Ohne den externen Call geht es nicht, frag mich nicht warum. Try catch vielleicht noch und Resourcen Name anpassen - steht noch auf meinem, hier klappt es so...

Tut mir leid, ich sehe modale Fenster eben nicht aus den Gründe, die du gennant hast, als veraltet an.
Und mit "sich auf alles andere" beziehen, meinte ich eigentlich die Herleitung der Argumentation deinerseits. Nach dieser Argumentation kann man COM als veraltet ansehen (was viele auch tun) und dennoch gleiche Bauchscmerzen bei mir auslöst, weil man es eben in vielen Fällen nicht so einfach abtuen kann.

Also wenn ich dich richtig verstehe, wehrst du dich gegen den Gedanken, dass die Parent-Form in irgendeinerweise duch das Einbleden einer zweiten Form, nicht mehr zugreifbar ist? Und das eben dieses Verhalten veraltet ist, weil man es auch anderes lösen könnte?
Usability/Ergonomie-Grüde also?

Tut mir leid aber nach diesem Standpunkt könnte man dann ja so ziemlich alles als veraltet bezeichnen.
Aber ich muss meinem Vorposter zustimmen, Grundsatzdiskussionen führen ja meistens zu nix 😉

und genau das wird von den einschlägigen Software-Ergonomie-Vorschriften und -Normen gefordert. Es soll eben dem Benutzer überlassen sein, wie er die Software benutzen möchte (Steuerbarkeit). Er soll sich nicht an die Abläufe halten müssen, die dem Programmierer vorgeschwebt haben.
herbivore

Undwie genau soll das dann ausehen? Ich stell mir gerade unsere Applikation vor, die der Kunde komplett selber steuert - mit 50 mode-less Fenstern auf, die der Kunde dann schön in beliebiger Reihenfolge abarbeitet und bei spätestens 5 vergessen hat, was er machen wollte. Die Software kann natürlich so designt werden und die Informationen könnten dem Kunden auch in übersichtlichen kleinen Tasks dargestellt werden aber eine allgemeine Aussage wie "Modal ist veraltet" sollte da diferenzierter gesehen werden. Nach meiner Erfahrung ist der simple Anwender oft froh, wenn er modal irgendwo durchgeführt wird.
Ich gebe dir recht, dass es sicher besserer Lösungen gibt ein quasi-modales Fenster mode-less zu integrieren für eben diese Tasks. Aber modale Fenster als nicht mehr zeitgemäß zu beschreiben, nur weils der Ergonomie-Experte so sieht, ist mir etwas dünn.

Wenn ich dich richtig verstanden habe, dann willst du eine MDI-Anwendung schreiben.

Schau dir mal direkt den MSDN eintrag dazu an:

MDI-Applikationen

Nice, den kannte ich auch nocht nicht 😃

Das sehe ich nicht so.
Es gibt eben Situationen in denen ich genau diese Funktionalität wünsche. Natürlich kann ich dieses Verhalten auch in mode-less Fenstern (bzw. im Parent) implemetieren, aber die Frage steht doch da ganz klar im Nutzen/Aufwand.
Ich habe natürlich mehr Flexibilität in mode-less Fenstern und muss mich "als Anwender" nicht mit der Entscheidung des Programmieres rumschlagen, diesen Dialog jetzt und genau jetzt durchzuführen bevor ich auch nur irgendwie was anderes mache, aber deshalb sehe ich ShowDialog() nicht als nicht mehr Zeitgemäß an.

Naja, ShowDialog() ist schon eine optimale Lösung, es kommt eben drauf an, ob die Kontrolle an die Form2 übergeben werden soll, bzw. Form1 während dieser Zeit nicht weiterbenutzt werden soll.

Falls Form1 weiter aktiv bleiben soll und auch weiter auf Benutzereingaben reagieren soll, dann ist ShowDialog natürlich murks, ansonsten würde ich schon ShowDialog() benutzen.

Das nicht Verschieben/Minimieren hat ja auch einen Grund, So ist immer ersichtlich, wer der Vater des Dialogs ist.