Ich vermute mal, das die unterscheidung im Taskmanager vom MainWindowHandle des Prozesses abhängt.
Wenn du einen falschen Tabellennamen übergibst, dann kommt ein Laufzeitfehler....
Zugegeben, meine letzten Tests beruhten noch auf .net 2.0.
Auf meinem aktuellen Rechner konnte ich immerhin 33 Millionen Objekte in die LinkedList einfügen. Da die linked List das hinzugefügte Objekt in ein eigenes Objekt wrapped, macht das also in etwa 66 Millionen Objekte im Speicher.
code:
static void Main(string[] args)
{
LinkedList<SmallClass> ll = new LinkedList<SmallClass>();
long l = 0;
try
{
for (; l < long.MaxValue; l++)
{
ll.AddLast(new SmallClass());
}
}
catch (Exception e)
{
Console.WriteLine(l);
Console.WriteLine(e.ToString());
}
Console.WriteLine("fertig");
Console.ReadLine();
}
public class SmallClass
{
private static long l = 0;
private long field = l++;
}
Wenn man jede Woche eine neue Seite dazu packt, wirds recht aufwendig das per Bit zu machen, oder versteh ich etwas falsch ?
wieso??? anstatt Rolle: 10 nimmst du halt Bit1
wenn du natürlich jede woche eine neue rolle hinzufügst musst du zwangsläufig in die datenbank auswandern.
Anstatt für jede Seite eine Spalte in der DB zu brauchen
und das sowieso nicht..... mach das relational und normalisiert. dann brauchst du nciht für jede seite eine spalte...
je nachdem und unabhängig vom speicher geht .net bei 8-16 millionen objekten in einer appdomain der saft aus.
Es gibt 2 möglichkeiten für eine Lösung:
Such mal. Es gibt viel stoff zu diesem Thema.
Sowas löst man eher mit Flags.
Also wenn bit 1 gesetzt ist, dann darf man auf Seite 1. Bei Bit 2 Darf man auf Seite 10 usw...
Wenn das nicht ausreicht, dann muss ohnehin eine Datenbank mit userverwaltung her.
Der Vorteil bei einer Bit-Version ist hier, das der Administrator einfach nur alle bits gesetzt hat und kann daher überall hin.
Falls du das so umsetzen möchtest, dann such mal nach dem stichwort "Flag enum"
Warum hängst du so sehr an der PictureBox fest? Die PictureBox ist ein relativ einfaches control. nimm ein Panel. Das ist auch einfach...
@Arithmetika: Bei der pictureBox gibt es soweit ich weiß kein AutoScroll...
richtig, das habe ich übersehen. Man bruacht ein Control, das von ScrollableControl erbt. Picturebox erbt aber direkt von Control.
Wenn dein Zeichenbereich die komplette Form ausfüllt, zeichne am besten direkt in der Form
Das würde ich persönlich nciht machen, da die wiederverwendbarkeit schlechter ist, als bei einem einfachen Control.
Vielleicht gibt es eine andere Möglichkeiten Bildlaufleisten bzw. Autoscroll in einer PictureBox zu ermöglichen?
Sicher gibt es die aber die sind deutlich komplizierter als der Vorschlag mit dem Panel.
schau dir alle autoscroll properties an, die machen exakt das, was du suchst.
Die validierende Logik muss sowieso gekapselt sein. Die zugreifende Logik (also wirklich nur Datei auslesen und speichern) ist so simpel und sollte in dem DAL ohne weitere Validierung zu finden sein.
Den reinen Zugriff auf die Datei testet man nicht (1-3 Zeilen Code). Die validierende Logik allerdings schon. Je nach erforderlichen Daten verwendet man eine art Mocking.
WinDbg ist eine alternative, die du mal ausprobieren kannst. Das Handling allerdings ist nicht gerade optimal.
Threading hilft nicht, mehrere Forms gleichzeitig laufen zu lassen. Threading hilft, wenn man operationen parallel abarbeiten möchte/kann. Forms jedoch müssen alle im selben Thread (Gui-Thread) laufen.
Ich würde das ganze trennen.
Architektur würde ich mit Enterprise Architect machen
Projektfortschritt mit Ms Project
User- und Installationguide mit irgendeinem Tool das CHM rausspuckt.
Bugtracking würde ich garnicht von einem Doku-tool abhängig machen.
Siehe [FAQ] Warum blockiert mein GUI? punkt: Achtung: Die Falle
Du pumpst die GUI voll mit Anweisungen, das sie überfordert ist und blockiert.
Welche Art von Doku? Architektur/Hilfe/Projektfortschritt/Feature/Design
siehe: ToolTip.Show-Methode (String, IWin32Window)
in kurz: einfach ein control.
dgw.CurrentRow.Cells[dgw.Columns["column1"].Index].Value = ... ;
in VS Menu -> Resharper -> Options -> Languages -> Codestylesharing
dll´s müssen immer im selben Ordner oder in einem Unterordner des ausführenden Programmes sein.
wenn du das nicht willst, weil es mehrere Programme nutzen (bei einem SDK ist das meist so), dann muss die dll in den GAC (inkl. aller Abhängigkeiten)