Um deinen Query mit Datumsangaben zu füllen, musst du folgendes machen:
Cultureinfo("en/us") Objekt instanzieren.
Im Query :
"datum = #" + item.tostring(cultinf)+"#"
Hintergrund ist, dass Access das Datum in folgendem Format haben möchte:
#YYYY/MM/DD#
Das bekommst Du am besten durch Cultureinfo als INformation an tostring()
Hoffe, ich konnte mich verständlich ausdrücken, ist spät und hatte einen anstrengenden Tag
Besser wäre es, du zeichnest im Paint-Ereignis den Text selber (mittels e.Graphics.DrawString). Dann kannst du auch pixelgenau zeichnen.
Einfach im Timer eine Membervariable (z.b. 'pos_x' erhöhen) und dann Invalidate() aufrufen. Im Paint-Ereignis dann 'pos_x' als Parameter für DrawString angeben.
Und für die Endposition kannst du dann ja pos_x wieder zurücksetzen:
if(pos_x >= ClientSize.Width) pos_x = 0;
Alternativ kannst du auch einfach die Location für das Label neu setzen:
Location = new Point(pos_x, Location.Y);
Dann brauchst du nicht selber zu zeichnen.
Beider Lösungen sind m.E. aber besser als die Leerzeichen-Variante.
Hallo zusammen,
ich habe den Vorschlag aufgenommen und merge jetzt die beiden Dateien in eine dritte Datei.
Dabei bin ich auf ein neues Problem gestoßen.
Ich nutze einen FileStream und einen StreamReader, um die Quelldatei einzulesen.
Nun musste ich aber feststellen, dass die Funktion ReadLine des StreamReaders nicht die Position im FileStream updatet.
Dies scheint mir doch sehr komisch zu sein. Was mache ich hier falsch.
Anbei ein wenig Pseudocode, um den Sachverhalt zu erläutern:
while(!EOF)
{
merke position via StreamReader.BaseStream.Position
ReadLine();
if (toInsert.compareTo(line)<1)
StreamReader.BaseStream.Position = gemerkte Position
FunktionWriteText();
}
Also mein Problem ist eigentlich, dass ich immer eine Zeile im Voraus lesen muss, aber beim Einfügen vor der zuletzt gelesenen Zeile einfügen möchte.
Gruß
Um die Frage was hier nun wirklich passieren könnte genau beantworten zu können, müsste ich mir erst nochmal das Speichermodell von .NET durchlesen, was das für Garantien abgibt.
Ohne volatile ist aber schonmal ganz sicher ein Problem.
Mit volatile aber ohne Locks könnte gehen, je nachdem was .NET eben garantiert oder nicht.
Die Variante die ich dir gezeigt habe ist auf jeden Fall OK.
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.
