danke, ihr seit mal wieder die besten ^^
yo das mitm try-catch block habe ich kurz bevor ich hier nochmal vorbeigeschaut habe herausgefunden^^
und nun kann ich endlich beruhigt schlafen gehen
Ein Vorher/Nachher-Vergleich des Codes ergibt, dass der Typ Haarfarbe jetzt aus der Klasse Mensch herausgenommen wurde, so sind Haarfarbe und Mensch nun auf gleicher Zugriffsebene, innerhalb des Namespace Zweibeiner. Vorher war das ja nicht der Fall.
namespace Zweibeiner
{
public enum Haarfarbe { Braun, Blond, Rot, Schwarz }
public class Mensch
{
private Haarfarbe haar;
public Haarfarbe Haar
{
get { return this.haar; }
set { value = haar; }
}
}
public static void Main(string[] args)
{
Mensch Ich = new Mensch();
Ich.Haar = Haarfarbe.Rot;
if (Ich.Haar == Haarfarbe.Rot)
Console.Writeln("Meine Haarfarbe ist rot.");
else
Console.Writeln("Meine Haarfarbe ist alles ausser rot.");
}
}
Ich favorisiere die Loesung von Th69. Zwei getrennte Form-Klassen werden so instantiiert, dass sie genau das machen was Du moechtest.
In Visual Studio z.B. eine Konsolenanwendung erstellen, dann hast Du die statische Main methode. Du fuegst eine Windows-Forms-Referenz hinzu und danach zwei Windows-Forms-Klassen, Passwortabfrage und Hauptfenster, zu Deinem Konsolenprojekt. Alles weitere siehe oben.
Ich kenne nur Tools die das können, die sich irgendwie ins System einhängen. Sysinternals File-Monitor und sowas. Sind aber soweit ich weiss keine offiziellen APIs die da Verwendung finden.
Klar, möglich ist ja auch immer jede Culture, kann man ja schlecht (und will man ja auch nicht) verbieten.
Aber als einfaches Beispiel:
Wenn ich zum Beispiel ein Control erstelle, das ja nach eingestellter Culture im GUI Thread eine Landesflagge anzeigen soll. Dann wäre es doch hilfreich wenn ich mitbekomme dass sich die Culture geändert hat und ich eine andere Flagge anzeigen muss. Natürlich geht die Welt nicht unter, wenn ich es an einer solchen Stelle nicht mitbekomme, und es ist ja trotzdem jede andere Culture erlaubt.
Mein Problem ist (bzw. war, hat sich fast komplett selbst gelöst):
Ich greife über Platform Invokes auf C++ klassen zu, die eine eigene Lokalisierung mitbrignen. Wenn ich jetzt beispielsweise einen "Double-String" von der C++ Klasse bekomme, die gerade eine Englische Kultur verwendet, und ich würde im managed Code mit Deutscher Kultur daraus wieder ein Double machen, hätte das ziemlich fatale Folgen...
Da die Lokalisierung der C++ Klasse aber über Umwege (gut versteckt) doch überschrieben werden kann, habe ich sie einfach über Callbacks auf die Thread.CurrentCulture.XXX (z.B DecimalPoint) umgeleitet. So wird jetzt automatisch immer, egal in welchem Thread, die gleiche Kultur wie im Managed Code verwendet.
PRIEST schrieb:
Ist dieses Magazin gut? Gibts da pdfs in die man sich mal rein lesen kann?
Wenn Du Themen haben möchtest die nur an der Spitze des Eisberges behandelt werden, dann ja.
Für Grafiker waren aber schon mehrere interessante Berichte dabei, die dann auch nicht nur in einem, sondern in mehreren Ausgaben durchgenommen wurden - wobei man die genau wie alles andere im Magazin auch im Internet finden kann.
Am interessantesten finde ich da noch die Praktikumsbörse sowie einen Bericht über Produktivitätssteigerung, der allerdings schon etwas zurückliegt.
Hmm.. ich nehme an das es bischen schneller sein müsste, das die ganzen Daten schieberei nur im speicher passiert.. und nicht zwischen HD und RAM..
ich teste es bei gelegenheit, und gib ein rêsume
Student83 schrieb:
Jetzt kann man allerdings dieses TabItem auch schließen und soll es später auch wieder aufrufen können. Wie würde ich das denn jetzt realisieren, wenn ich den TabItem-Code nicht wie bisher in den Window.Resources speicher?
Spontan würden mir hier "CustomControls" einfallen welches von TabItem erbt, hier definierst Du genau dein TabControl so wie du es haben möchtest, und kannst es jederzeit wiederverwenden.
Zu der Toolbar würde mir ein Singleton-Objekt einfallen, welches du via Interface durch alle Klassen "durchreichen" und manipulieren könntest.
Alternativ könntest du unter Projekteigenschaften -> Erstellen bei DEBUG-Konstante definieren den Haken setzen. Halte ich bei Release-Kompilierung aber nicht für sinnvoll, wollte das nur der Vollständigkeit halber erwähnen.
Das geht schon, wenn du eine Klasse hast die du Speicherst und dessen Property veränderst.
Du machst aber eine Zuweisung auf dem Objekt selber, dadurch setzt du die Referenz neu.
public class Item
{
public string Val;
}
var item = new Item();
var newItem = item;
newItem.Val = "demo"
// "item" ist nun verändert.
newItem = new Item();
// "newItem" ist jetzt ein neues objekt, "item" bleibt unverändert.
ReturnString = _ReturnString; //Referenz merken
// OK
ReturnString=txtFilter.Text;
// ReturnString ist nun eine Referenz auf txtFilter.Text, _ReturnString bleibt unangetastet.
Hi Leute,
wie kann ich den AutoWert einer in einem DataGrid beschriebenen Access Tabellenzeile auslesen?
ich bin dabei ein Programm schreiben, das Daten aus einer Access Datenbank Tabelle anzeigen und ändern kann. Mit dem Beispielcode siehe unten funktioniert das auch schon ganz gut, die Tabelle wird in ein DataGrid eingebunden.
die Tabelle sieht folgendermaßen aus:
Nr Vorn Name
-- ------- -----
1 Anton Huber
2 Josef Meier
Den Felddatatyp der Spalte "Nr" habe ich auf AutoWert gesetzt. Wenn jetzt ein neuer Name hizugefügt wird, wird im DataGrid bei Nr automatisch eine "-1" eingetragen, erst nach Neustart der Anwendung steht dort eine "3". Wie bekomme ich das gleich upgedatet, ohne das Programm neuzustarten?
public CustomerDataProvider()
{
NorthwindDataSet dataset = new NorthwindDataSet();
adapter = new CustomersTableAdapter();
adapter.Fill(dataset.Customers);
dataset.Customers.CustomersRowChanged +=
new NorthwindDataSet.CustomersRowChangeEventHandler(CustomersRowModified);
dataset.Customers.CustomersRowDeleted +=
new NorthwindDataSet.CustomersRowChangeEventHandler(CustomersRowModified);
}
void CustomersRowModified(object sender, NorthwindDataSet.CustomersRowChangeEvent e)
{
adapter.Update(dataset.Customers);
}
