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.

Hi,

prizipiell ist die Frage, ob man Attribute zu Elementen hinzufügen oder neue Elemente benutzen sollte, deine eigene Entscheidung. Ich ziehe Elemete Attributen vor, solange der Sachverhalt auch durch diese zu handeln ist. Element Values sind besser mit DTD zu handeln, du kannst einfacher Hierarchien abbilden, etc.

In deinem Fall würde ich aber sagen, Element-Attribut als Value des eigentlichen Elements zu benutzen ist unschön.

Nur dass Value.ToString() knallt, wenn Value null ist.

  
//Leider gibt mir filtered 0 TestClasses zurück. - Was mache ich falsch?  
List<TestClass> filtered = myList.FindAll(n => n.TestType == (TestType.Test4 | TestType.Test5));  
  

Vielen Dank für Eure Antworten.

Grüsse, pro

Wie Zommi sagte,
(n => n.TestType == (TestType.Test4 | TestType.Test5));
würde
tc.TestType = TestType.Test4 | TestType.Test5;
und
tc.TestType = TestType.Test5 | TestType.Test4;
finden.

Was du willst, ist (n=> ( n.TestTypeTest.Type4 || n.TestTypeTest.Type5));
also falsche Syntax/Semantik...

Hoffentlich definierst du den Enum-Typ nicht in jeder TestClass 😃

Wenn TestClass.TestType so gesetzt wird:

TestClass tc = new TestClass();
tc.TestType = TestType.None | TestType.Test1;

dann wirst du über FindAll(n=> n.TestType == (TestType.None | TestType.Test1));
dieses Element auch finden. Dabei spielt es keine Rolle, in welcher Reihenfolge die Types verknüpft werden. FindAll(n=> n.TestType == (TestType.Test1| TestType.None)); findet das Element auch

FindAll(n=> n.TestType == (TestType.None)); wird dir das Element nicht wiederliefern, weil "tc.TestType = TestType.None ->|<- TestType.Test1;" kein oder ist, sondern ein "und". Somit wird es nicht gefunden.

Hi,
versuchmal KeyPreview auf true zu setzen und dann PreviewKeyDown zu handeln.

Grundsätzlich ist ja erstmal die Frage wie "groß" dein Bingofeld ist. 3x3, 4x4, etc.
Das muss natürlich vorher festgelegt werden. Und dann kannst du die Bingos definieren. Also (0|0 0|1 0|2), (1|0,1|1,1|2), etc. (für die Folgetests)

Dann noch etwas Hirnschmalz rein, also nur die erste Reihe horizontal und vertikal testen, wenns da kein Match gibt, aufhören -> kein Bingo
Ansonsten die Laufrichtungen runter.
Wenn Ecke alle 3, ansonsten runter bzw. nur längs, und weiter gucken ob im angenzenden Feld Match (erhöhen der der ersten Zahl bzw, der zweiten oder beide).

Ob du das mit ner StoredProcedure machst oder die die Daten einmalig in einen 2-dimensionales Array ausliest (bei einem Spiel) oder sogar 3-dimensional (für alle Spiele) hängt nur bedingt an der Performance (die Statements werden dadurch auch nicht kleiner).

Kommt eben drauf an, wie groß die Tabelle ist, ob es eine Live-Überwachung sein soll, etc...

Hi,

Microsoft.ApplicationBlocks.Data.SqlHelper.cs

zumindest wars mal so. War damal in DAAB drin. Keine Ahnung, ob das Teil noch weiterentwickelt wird...

Da gibt's kein besser oder schlechter. Das kann man mit XPath genau so gut erledigen, wie mit LINQ.

Ich persönlich bevorzuge LINQ (to XML), weil's einfacher zu schreiben/lesen/warten ist.

PredicateBuilder, zu finden im LINQKit.

Ohne FQN wird das nichts.
Du könntest aber einfach durch die Assemblies deiner AppDomain iterieren und dir daraus den Fullname ziehen.

 
string controlString = "System.Windows.Forms.TextBox";

 foreach(Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
 {
    Type t = assembly.GetType(controlString);

     if(  t != null )
     {
        object handle = Activator.CreateInstance(assembly.FullName, controlString );
                  //...
      }
}

ein einfaches "ALTER INDEX Indexname" für eine Reorganisation aus?
dN!3L

ALTER INDEX name ON table/schema REORGANIZE

Soweit ich weiß, sind Indexnamen nur im Objekt unique. Wär ein Wunder, wenn er den richtigen Index so reorganisieren würde...

Versuchs mal mit SingleOrDefault()
Dann solltest du auch deinen null Check machen dürfen.

Lol, den Gedanken hatte ich auch - und diesmal war ich schneller 😉
Und da sieht man mal wieder, dass viele Wege nach Rom führen...

var query = from article in articles  //loop über alle artikel
                  from lieferant in articles.GetLieferanten //(also die Property für die Liste der Lieferanten  - loop über alle Lieferant)
                  where lieferant.Name == "Foo" // (Property für name) where bedingung
                  select article; //den artikel selecten

oder eben direkt Lambda, ist kürzer aber weniger lesbar

var query = articles.Where(a=> a.Lieferanten.Any(l=>l.Name == "Foo"));

Kann ich mir auch nicht vorstellen, dass SuspendLayout nicht gehen soll.
Versuch doch mal:

1. SuspendLayout()
2. DataSource dran
3. Filtern
4. ResumeLayout()

Ternäre Beziehungen müssen aufgelöst werden. Sonst kannst du sie nicht abbilden.
Hier ist ein kleines Beispiel.

Ansonsten google dochmal "replace ternary Relation sql" oder so.

Hallo,
Deshalb wird so eine Funktion niemals ins IEnumerable<T> Interface wandern, weils semantisch nicht zu Linq passt.

Naja, IEnumerable ist vielleicht das Herz-Stück Linqs, aber dennoch nicht exklusiv an Linq gebunden.

IEnumerable implementiert eine Iterationsmöglichkeit über Elemente. Nicht mehr, nicht weniger. Einen Action-Delegaten einzufügen mag Sinn machen oder auch nicht.
Dennoch man kann relativ leicht nachvollziehen, dass das Interface IEnumerable einen anderen Scope bekommen, falls es mehr als ein Iterieren (nämlich besagten Action-Delegat, wie in List<T>.ForEach()) implementieren würde. Das ist vermutlich der Grund, warum es nicht implemtiert ist und auch nie werden wird. Das Verhalten ist dann einfach nicht mehr das, was ich mit IEnumerable ausdrücken will. Und daher würde ich sagen:

Deshalb wird so eine Funktion niemals ins IEnumerable<T> Interface wandern, weils semantisch nicht zu "IEnumerable<T>" passt

Ja, das mit der Performance bzgl. ToList() ist ja klar, aber die Funktionsweise ist bei beiden Varianten gleich. Warum MS ForEach aber nur für List<T> und nicht IEnumerable<T> spendiert hat, bleibt mir aber ein Rätsel?!

Weil die Funktionsweisen eben nicht gleich sind. List<T>.ForEach() arbeitet intern nicht mit einem Enumerator (kein Nutzen von MoveNext()/GetEnumerator()) sondern mit einem for-loop über die Size der Liste - was bei einem IEnumerable absolut keinen Sinn macht.

Performance-technisch ist die "optimierte forEach (bzw. der for-loop)" also etwas Fixer als die Enumerator foreach Version.

Geh mal Schritt für Schreitt durch:
Entweder mal iwo einen Breakpoint setzen und frm zur Watch hinzufügen und mal reinschauen oder einfach mal:

MessageBox.Show(String.Format("Control Count = {0}",frm.Controls.Count));

foreach (Control con in frm.Controls)
{

    MessageBox.Show(String.Format("ItemName = {0}, Type = {1}",con.Name, con.GetType().ToString()));

     if (con is MenuStrip)
     {
        foreach (ToolStripMenuItem item in (con as MenuStrip).Items)
        {
           key = item.Name;
           value = item.Text;
           if (!pSection.Entrys.ContainsKey(key))
                 pSection.Entrys.Add(key, value);

           RecursiveHelper.RecursiveCreateLanguagePattern(item.DropDownItems, pSection);
         }
     }
} 

Generic Error in GDI+ kann einiges sein. Wohin speicherst du das Bild? Hast du Berechtigungen, das Bild zu speichern?

BTW: Path.Combine

Versuch mal:

Application.StartupPath

Hab mal kurz in den Quellcode geguckt. Beim Hinzufügen der einzelnen Contents zum Panel werden WindowsHooks gesetzt, die aber erst beim Disposen des DockPanels wieder aufgehoben werden. (Falls ich das alles richtig gesehen habe), Das würde die "unsichtbaren Referenzen" erklären.

Du kannst ja mal den Auszug posten, wo du die Contents erzeugsts und wie du sie an das Panel übergibts, sollten ja nur 2-3 Zeilen sein.
Und bitte auch das Dispose.

Naja, die Referenz in Controls geht zum DockPanel, der verweist auf DockContents, vermutlich über eine Art ChildCollection.

Wenn er die Referenz rausschmeißt, dann ist alles weg. Wenn ich ihn richtig verstanden habe, dann gehts ihm um die DockContents, die disposed werden sollen.

Nichts destotrotz, beim Close() der MainForm sollte alles weg sein.

Weil Properties keine Felder sondern nur Funktionspointer sind und keinen internen Speicherplatz haben?

if (con is MenuStrip)

Wenn du Form.Dispose() aufrufst, werden alle in der Form erzeugten Objekte/Resourcen freigegeben. Damit ist alle bereit zum Abholen durch den GC.

Wo/Wie werden denn die DockContents erzeugt? Wie kommen sie in Form?
Vermutlich haben sie noch irgendwo eine root reference.

Also ich rate dir auch zu nem Breakpoint, zumal der Code-Auszug da oben nicht richtig ist. Entweder Typo oder :

1. du checkst ob "comp.GetType()==typeof(MenuStrip)"
2. iterierst aber über (foreach Control "CON")

Falls du irgendwo ein comp hast, was kein MenuStrip referenziert, dann wirst du auch nichts finden.

Kommen die nicht von ToolStrip und implementieren IComponet, erben aber von Control?

Edit hab mal fix ein StatusStrip hinzugefügt und:
this.Controls[0].GetType()
{Name = "StatusStrip" FullName = "System.Windows.Forms.StatusStrip"}

Hast du mal versucht an die AutoScrollPosition (Falls AutoScroll == true) einen neuen Point zu binden?

//schiebt den hScroll 30 Pixel nach rechts und vScroll 50 Pixel nach unten
 this.panel1.AutoScrollPosition = new Point(30, 50);

Ah ok! Ich sehe das Problem 😃
Danke für die Erklärung.

Dann sollte ja

List<FileSystemInfo> list = new List<FileSystemInfo>();
list.Add(new DirectoryInfo(@"C:\");
list.Add(new FileInfo(@"C:\test");

den selben Fehler werfen, was es nicht tut. Oder irre ich mich da.
Vielleicht kannst du mal ein Auszug aus der Manager Klasse posten.

Die exe ist in die Resourcen eingebettet, oder? Also du hast Add->Existing Item... gemacht? Die wirst du mit Process.Start nicht starten können.
Ist das eine .NET exe? Oder eine x-beliebige Datei?

Falls es eine .NET exe ist, dann könntest du noch versuchen, sie als byte[] aus den Resourcen direkt in den Speicher zu laden und auszuführen. Bin mir nicht sicher, ob das auch mit anderen exe-Files geht.

using System.Reflection;
using System.IO;

Assembly currentAssembly= Assembly.GetExecutingAssembly();
string assemblyRoot = currentAssembly.GetName().Name;

using(Stream res = currentAssembly.GetManifestResourceStream(assemblyRoot + ".NameOf.exe")){

if(res != null && res.Length > 0)
{
   byte[] resBuffer = new byte[res.Length];
  res.Read(resBuffer, 0, resBuffer.Length);

try{
   Assembly exe = Assembly.Load(resBuffer);
   exe.EntryPoint.Invoke(null, null);
}catch{}

}
}

Ungefähr so, bin mir nicht mehr 100%ig sicher. Ich glaube aber nicht, dass das mit ner x-beliebigen exe gehen wird, kanns jetzt nicht testen, muss los 😁

Google mal, zu dem Thema gibt's einiges. Schau dir mal satellite.dlls und den RessourceManager an.

@herbivore

Genmau das meine ich. Das gilt für Value-Typen. Bei Referenz-Typen braucht man das nicht. Das klingt so, als ob ich, falls ich kein ref reingeben und eine Zuweisung an t mache, die Änderungen nicht "durchschlagen", das ist im Fall von Referenztypen falsch. Die schlagen sehr wohl durch. Das einizige was nicht durchschlägt, ist das manipulieren des Parameters, der ist bei CBV eine kopierte Referenz und bei ref die "wahre" Referenz. Also falls ich t null setzte oder auf ein anderes Objekt umbiege.

public void init(ref MyClass t)  

bringt gar nichts, wenn t nicht innerhalb von init geändert wird.

Das musst du mir mal genauer erklären.

Du mußt dir mit sn.exe (Strong Name Tool) ein Key-File erzeugen und das dann an die Assemby (dll) binden.

using System.Reflection;

[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("key-file.snk")]

Ja, es sollte gehen. Prinzipiell hat der HKCU Vorrang zu HKLM. Soll heißen, falls ein Schlüssel in beiden Sections definiert ist, hat HKCU Vorrang. Kannst ja einfach mal testen.

Oh, wieder was gelernt. Scheint eine höhere Edit -> Resolution zu haben. Laut MSDN hat DateTime ca. 16ms. Wie hoch ist denn die von StopWatch?

Ich würde einfach mal testen, wie lange die einzelnen Steps dauern (Im Schnitt)

DateTime readLineStart = DateTime.Now;
- lese Zeile aus Json
DateTime readLineEnd = DateTime.Now;

//usw...

- lege Zeile an


- schreibe Zeile

Dann siehst du, wo der Bottleneck ist. Ich vermute stark beim Einlesen der Daten. 4000 Zeilen in ein DataTable zu adden sollten recht fix gehen (Flass du da keine Blobs oder sonstige großen Datenmengen reinschreibst).